µTask Automation Engine: Install and First Use

What µTask Automates Beyond a Single Script

µTask addresses workflows that are too stateful for a straightforward shell script. Its task template declares inputs and a graph of actions with dependencies. The engine executes eligible actions asynchronously, records intermediate states, works around transient errors, and retains an encrypted audit trail until the task completes. This makes the project relevant to infrastructure teams, DevOps engineers, and internal platform groups that need repeatable operational procedures rather than isolated command execution.

The README establishes the intended scope through several examples. A Kubernetes workflow can generate a private key, obtain a certificate, meet issuer challenges, and commit the certificate to a cluster. Employee onboarding can collect a public SSH key, create accounts across internal services, start another task for a development VM, and send a welcome message. A payments workflow can combine API calls, conditional branches, a failed score, and a human investigation form before reporting its result.

That human-input path is important because business automation is not limited to machine-to-machine steps. An operator can receive a µTask-generated form and supply information needed by a running task. The engine is therefore aimed at procedures whose participants may include applications, infrastructure systems, and people. It does not present itself as a general shell runner or as a source-code CI service.

µTask's PostgreSQL Coordination and Encryption Model

The execution architecture differs from engines that send every workload to a separate agent pool. According to the README, the scheduler and task workloads run inside one µTask runtime. Several µTask instances can coordinate through one PostgreSQL database, and each instance independently determines which tasks are available. Before working on a task, an instance claims it to prevent collisions, then releases it at the end of an execution cycle.

This design keeps the infrastructure requirement narrow: PostgreSQL is the only stated service dependency, with version 9.5 as the minimum. The repository's `docker-compose.yaml` uses `postgres:14-alpine`, initializes the database from files under `./sql`, and configures µTask through environment variables. The task service waits for `db:5432` before starting `/app/utask`.

Resumption is tied to the same database-backed claim model. If execution is interrupted before completion, the task becomes available for collection by an active µTask instance. It may therefore begin on one instance and resume on another. That behavior helps with process failure, but it also means actions must tolerate replay after an uncertain interruption. The README does not promise exactly-once execution or describe transactional rollback for completed external side effects.

Encryption is applied to stored data, while authorization controls which users can see it. The key rotation procedure uses `symmecrypt`, labels a storage key, places it in configuration, enters maintenance mode, reboots the API, calls `/key-rotate`, and then permits removal of older keys after rotation. This is an explicit administrative workflow rather than an automatic zero-downtime rotation process.

Installing µTask with Its Docker Compose Stack

The quickest local installation creates a directory, downloads the release install script, starts the generated Compose project, and exposes the dashboard on port 8081. Run the following commands in a new directory:

mkdir utask && cd utask
wget https://github.com/ovh/utask/releases/latest/download/install-utask.sh
sh install-utask.sh
docker-compose up

The install script generates local assets that the README expects to use. The repository's Compose file builds µTask from the local Dockerfile, starts PostgreSQL, and mounts `./templates`, `./scripts`, and `./functions` as read-only directories. Its checked-in credentials are development values: basic authentication includes the `admin` user with password `1234`, and group authorization maps `admin` to the administrators group. Those values must not be carried into a shared or production deployment unchanged.

After the services start, open `http://localhost:8081/ui/dashboard` and sign in as `admin` with `1234`. The README also publishes the API schema at `http://localhost:8081/unsecured/spec.json`. That endpoint is useful for discovering the request format, but the README does not include a complete API request example, so the article does not invent a task payload or command.

A First Workflow Through Templates, Tasks, and State

A real first use begins in the template library, not by writing Go. The README identifies template browsing, task creation, a task overview, and a detailed view of a running task as dashboard functions. Based on that documented interface, log in and select an available task template, supply the inputs defined by that template, and submit it as a new task. Then use the task detail view to inspect its actions, dependencies, intermediate states, and final result.

The repository places examples under `examples/templates` and custom action examples under `examples/plugins`. The README excerpt does not expose the contents of a particular template, so it provides no confirmed template name or input schema. If the generated installation does not provide a suitable local template, inspect the repository's example template directory before adding a workflow to the `./templates` mount.

For a first acceptance check, select a template whose actions can be completed with non-sensitive data. Submit one task, watch its action graph progress, and open the completed task record afterward. Confirm that the status is understandable and that the details visible to the logged-in user match the expected access policy. This exercises the engine's central promise: a declarative workflow becomes an asynchronous, inspectable execution record rather than a foreground command.

Go Actions, Resumption, and Operational Trade-offs

µTask is extensible through custom actions written in Go. That makes it possible to connect workflow steps to organization-specific infrastructure or services, but it also shifts some maintenance work to the adopting team. A plugin has to be compiled into the deployed image and kept compatible with the Go version and dependency set used by the build. The production guidance says to base an image on the official µTask image and include local templates and plugins; the generated Dockerfile is the starting point for that packaging model.

The combined scheduler and workload architecture offers a small deployment surface, yet it also creates boundaries. Long-running or resource-heavy actions run inside the application runtime rather than in a documented external worker pool. The README does not describe resource quotas, per-action isolation, worker sizing, or cancellation guarantees. It also does not document rollback. A failed workflow can retain audit state, but an earlier API call, file change, or account creation may remain committed.

The interrupted-task behavior deserves particular attention. When an instance stops mid-execution, another instance may collect the task. Because exactly-once side effects are not documented, custom actions should be written with duplicate delivery in mind. That is a design concern rather than a claim about a specific bug. The README confirms retry and collection behavior, but it does not explain whether every plugin receives an idempotency key or whether the engine compensates completed steps.

A conventional shell scheduler is a practical alternative for simple recurring jobs. It can run a command from cron or an operating-system timer without declaring a durable action graph or coordinating several µTask instances through PostgreSQL. µTask adds value when a procedure has dependent steps, conditional paths, human forms, retries, retained state, or custom business actions. A plain cron setup remains simpler when the entire procedure is one idempotent command and long-term workflow inspection is unnecessary.

Release Cadence, Upgrades, and BSD-3-Clause Obligations

The repository is not archived, and its last push was on 2026-07-29. Recent releases include `v1.34.0` on 2026-03-18, followed by `v1.33.3` and `v1.33.2` on 2025-09-02. The production guide recommends re-downloading the install script to bump µTask while keeping task templates and plugins in a separate, versioned Git repository. That separation makes local workflow changes reviewable, but it also means an upgrade can require reconciling engine behavior with custom Go actions and stored template definitions.

The module declares Go 1.24.0 in `go.mod`, while the repository's `Dockerfile` builds with `golang:1.26`. A direct `make all` build therefore needs an appropriate Go development environment, whereas Compose builds inside the Docker image. Upgrading from the generated installation should include reviewing the changed release and testing representative templates, especially any task that can be interrupted and resumed.

µTask uses the `BSD-3-Clause` license. That permits use and modification under the license's conditions, including retaining required notices and examining its redistribution obligations. This is not legal advice. Teams embedding modified µTask code or distributing a customized image should check the repository's `LICENSE` and `LICENSES/` files for the notices that must accompany the distribution.

Editorial conclusion

µTask fits technical teams that want durable, auditable workflows implemented as YAML graphs and Go plugins, especially when PostgreSQL is already an accepted service dependency. It is a poor fit for users seeking a standalone desktop tool, a lightweight batch scheduler with no shared database, or a platform that isolates workloads in external execution agents. Before adoption, verify that your actions can tolerate interruption and resumption, that PostgreSQL 9.5 or later fits your operating model, and that the dashboard at port 8081 meets your access and security requirements. The first practical acceptance check should be running one complete template through the Docker Compose deployment and confirming that its task state and encrypted history can be reviewed afterward.

Frequently asked questions

Official sources

1. Issues
2. License: BSD-3-Clause
3. ovh/utask on GitHub
4. README
5. Releases