Dagu: A Single-Binary Workflow Engine That Keeps Orchestration Out of Your Code

What Dagu Solves for Operations Teams

Dagu targets a specific pain: teams whose primary job is not orchestration but who still need to schedule and coordinate scripts, containers, and remote commands. The README contrasts it with cron, which runs commands but offers no dependencies or retries, and with Airflow, which forces you to operate a platform with a scheduler, metadata database, workers, and a Python environment. Dagu's pitch is that workflow structure becomes configuration in a YAML file, not code that your scripts import. Your scripts run as they always did; the YAML adds an execution graph, retries, per-step logs, and a Web UI around them. That design suits data operations, legacy script consolidation, media conversion, and infrastructure automation, as the use-case table lists. It is not built for teams that need to embed orchestration logic deep inside application code, like Temporal's SDK model. Dagu keeps the orchestrator outside your business logic, which is exactly its stated rationale.

How Dagu Works: YAML DAGs, File-Backed State, and a Single Process

Dagu's mechanism is a directed acyclic graph (DAG) defined in declarative YAML. You describe steps, their dependencies, schedules, retries, and human tasks in one file placed next to your scripts. The engine, a single binary, reads that YAML and executes steps, which can be shell commands, Docker containers, Kubernetes Jobs, or SSH commands. The README shows a diagram contrasting a traditional orchestrator's six or more services (web server, scheduler, workers, PostgreSQL, Redis or RabbitMQ, Python runtime) with Dagu's single `dagu start-all` process. State is stored in local files, not in a database or message broker. That file-based state is what allows workers to spread execution across machines, according to the performance section. The engine supports parallel execution with concurrency controls, cron scheduling with timezones and overlap policies, and catch-up windows. It also includes a built-in MCP server for inspecting workflows and runs, which is notable for teams experimenting with agentic workflows, but the core value remains the simple execution model.

Getting Dagu Running: Install and First Commands

Dagu installs through several channels. For macOS and Linux, the README gives a curl pipe to bash: `curl -fsSL https://raw.githubusercontent.com/dagucloud/dagu/main/scripts/installer.sh | bash`. Homebrew users can run `brew install dagu`. npm is also supported with `npm install -g --ignore-scripts=false @dagucloud/dagu`, and Windows has a PowerShell installer. Docker users can start Dagu with a volume mount and port mapping: `docker run --rm -v ~/.dagu:/var/lib/dagu -p 8080:8080 ghcr.io/dagucloud/dagu:latest dagu start-all`. That command runs the full server and scheduler in one container. The `-v` flag persists state to your home directory, which matters because Dagu stores run history and logs in local files. The README warns that the Docker command does not expose the host Docker daemon, so Docker steps inside workflows would need a separate configuration. After installation, you define a workflow YAML file and use the CLI or Web UI to start it. The docs site and examples are linked for the full syntax, but the core pattern is clear: write YAML, run `dagu start-all`, and manage workflows through the UI.

Where Dagu's File-Based State Becomes a Limitation

Dagu's biggest trade-off is also its selling point: no database, no broker, state in local files. The README claims a single machine can run thousands of workflow runs per day, with actual capacity depending on CPU, memory, disk, and workflow shape. But it does not discuss what happens when a machine crashes mid-run or when two workers write to the same file set. File-based state is simpler to operate, but it generally offers weaker durability and consistency guarantees than a dedicated database. For mission-critical pipelines where a lost run history or a corrupted state file is unacceptable, Dagu may be the wrong tool. The README also mentions scale-out via workers, but it does not explain how those workers coordinate state. If you need exactly-once execution or strong transactional guarantees, you should look elsewhere. Dagu is honest about its scope: it is built for operations and internal automation, not for high-stakes financial transactions. That positioning is clear, but you should test its behavior under failure before trusting it with critical jobs.

Dagu vs. Airflow and Cron: A Real Comparison

The README positions Dagu as an alternative to both cron and Airflow, and the difference is architectural. Cron gives you no dependency graph, no retries, and no run history; Dagu adds all of those in YAML. Airflow gives you a mature scheduler and rich UI, but it requires a Python environment, a metadata database, and a separate scheduler and worker processes. Dagu collapses that into one binary. The comparison is not just about operational overhead; it is about where workflow logic lives. Airflow's model often pushes you to write DAGs as Python code, which means your orchestration logic is code. Dagu keeps it as declarative YAML, so deleting the YAML leaves your scripts untouched. Temporal, mentioned in the README, takes the opposite extreme: durable execution inside your application SDK. Dagu is a middle path for teams that want orchestration as configuration, not as a programming model. If you already have a Python-based data team and complex branching, Airflow's code-as-configuration might be more flexible. But if you want to wrap existing shell scripts without rewriting them, Dagu's approach is more direct.

Maintenance, Upgrades, and License Considerations

Dagu is written in Go and distributed as a single binary, which simplifies upgrades: you replace one file. The repository shows active development with recent releases like v2.16.3 in September 2026, plus a Helm chart (helm-dagu-2.0.4) for Kubernetes deployments. The README does not describe a formal migration path between versions, so you should check the release notes before upgrading, especially because state is stored in local files whose format could change. The license is GPL-3.0, which has implications if you embed or modify Dagu in a closed-source product. For internal use, GPL-3.0 is generally acceptable, but if you plan to distribute a modified version, you must release your changes under the same license. That is a legal consideration, not advice. The project also provides a live demo with credentials `demouser`/`demouser`, which is a practical way to evaluate the UI before installing. The maintenance burden is low because there is no database to patch or broker to tune, but you still need to manage the host machine, disk space for logs, and backup the state directory.

Editorial conclusion

Adopt Dagu if you manage scripts, containers, or SSH commands that need scheduling, retries, and a visible run history, and you want to avoid operating a multi-service orchestrator. Do not adopt it if you need strict durability guarantees that a file-based state store cannot provide, or if your workflows require complex branching logic that is better expressed in code. Before committing, verify that Dagu's file-backed state and lack of a database meet your reliability expectations, and test how it handles concurrent runs and worker scaling in your environment. The project is actively maintained with recent releases, but you should review the GPL-3.0 license implications for your use case.

Official sources

1. dagucloud/dagu on GitHub
2. License: GPL-3.0
3. Project website
4. README
5. Releases