Dagu: A Workflow Engine That Doesn't Ask You to Run a Platform

You've got scripts that work. Cron jobs, shell one-liners, maybe a few Docker containers. They do their job, but the moment you need dependencies between them, retries, or any kind of visibility into what ran and what failed, you're stuck. So you look at the orchestration options, and somehow scheduling a few jobs turns into operating a second system. Dagu is a workflow engine built to avoid exactly that.

What It Does

Dagu is a local-first workflow engine for operations and internal automation. It ships as a single binary with a built-in Web UI, and it doesn't need an external database or message broker. It runs on Linux, macOS, and Windows.

You define your workflows as DAGs (directed acyclic graphs) in declarative YAML. Each step can run shell commands, Docker containers, Kubernetes Jobs, or remote commands over SSH—without rewriting them. The engine handles scheduling with cron syntax, timezones, overlap policies, and catch-up windows, plus retries, human tasks, notifications, webhook triggers, and run history. You can compose reusable Sub-DAGs and run work in parallel with concurrency controls. It's self-hostable and runs where your data and credentials live: on-prem, air-gapped, edge, or cloud, scaling from a single node to a fleet of workers. There's also a built-in MCP server for inspecting workflows and runs, maintaining Wiki pages, applying changes, and controlling runs.

Why It's Cool

The pitch here is a reaction to a real cost that's easy to overlook until you're paying it. The README lays it out plainly: cron gives you no dependencies, no retries, no history. Airflow orchestrates, but you operate a platform for it—scheduler, metadata database, workers, a Python environment—and your jobs get rewritten as framework code. Temporal gives you durable execution, but your business logic moves into its SDK and programming model. In each case, you wanted to schedule some jobs, and now the orchestrator lives inside the code it was supposed to serve.

• Workflow structure is configuration, not code. Order, dependencies, retries, schedules, and human tasks all go in one YAML file next to your scripts. The engine that runs them is a single process. That's a meaningful distinction—it means your automation doesn't get entangled with a framework's abstractions, and you can read exactly what a workflow does without tracing through code.

• No database, no broker, no platform to babysit. A single binary with a built-in Web UI is a fundamentally different operational footprint than a scheduler plus metadata store plus workers. For teams whose main work isn't orchestration, that difference is the whole point.

• Your existing commands run unmodified. Shell commands, Docker containers, Kubernetes Jobs, SSH remote commands—the README is explicit that these run as-is. You're not porting anything into a new DSL or wrapping it in decorators. The YAML describes the structure around your work, not the work itself.

• It scales without changing its shape. The same single-binary model goes from one node to a fleet of workers. You don't graduate into a different architecture when you grow.

• The MCP server is a nice touch. Being able to inspect workflows and runs, maintain Wiki pages, apply changes, and control runs through it fits the "local-first, self-hostable" theme rather than feeling bolted on.

The honest framing from the README is worth repeating: this is built for teams whose main work is not orchestration. That's a specific audience, and Dagu is designed around their constraints rather than trying to be everything to everyone.

How to Try It

The fastest way to get a feel for it is the live demo, which requires no setup:

1. Head to the live demo at https://dagu-demo-f5e33d0e.dagu.sh
2. Log in with username demouser and password demouser
3. Poke around the Cockpit view to see queued, running, completed, and failed runs side by side

If you'd rather run it yourself, grab the binary and start the engine:

dagu start-all

That single command brings up the whole thing—no database to provision, no broker to configure. From there, you write a YAML file defining your DAG and let Dagu handle the rest.

For examples of how workflows are defined, the docs have a dedicated examples section, and there's a CLI reference if you prefer driving things from the terminal. There's also an API spec if you want to integrate programmatically.

The repository is at github.com/dagucloud/dagu, and the docs live at docs.dagu.sh.

Final Thoughts

Dagu isn't trying to win a feature checklist against Airflow or Temporal—it's making a different bet about who its user is. If you're running a handful of scripts and containers and you want scheduling, dependencies, retries, and logs without standing up a platform, this is aimed squarely at you. If your workflows are deeply intertwined with application code and you need durable execution as a programming model, you're probably looking at a different tool. The single-binary, no-database design is the kind of constraint that ends up being a feature: fewer moving parts, less to operate, and a workflow engine that stays out of the way of the work it's scheduling.