Dagu vs Windmill
Dagu vs Windmill: declarative YAML against a script and app platform.
Both run self-hosted and both are fast. Windmill turns scripts into workflows, webhooks, and low-code apps backed by PostgreSQL. Dagu is one binary that runs declarative YAML over commands you already have, with no database to operate.
name: nightly-ops
schedule: "0 2 * * *"
steps:
- id: extract
run: python scripts/extract.py
- id: transform
run: ./bin/transform
retry_policy:
limit: 3
depends: [extract]
- id: notify
run: ./scripts/slack-success.sh
depends: [transform]One self-contained binary, no PostgreSQL
Workflows are declarative YAML over existing commands
Executors for shell, Docker, HTTP, SSH, SQL, sub-workflows, and Agent Harness steps
Runs local, queue-based, or distributed
At a glance
Windmill vs. Dagu at a glance
Declarative YAML that calls your commands.
Scripts in Python, TypeScript, Go, Bash, or SQL hosted in the platform.
Single binary, file-backed state, no database.
Rust services and workers backed by a PostgreSQL queue.
Workflow orchestration with shell, Docker, HTTP, SSH, SQL, and Agent Harness steps.
Workflows plus a low-code app and UI builder with approval flows.
In depth
Where each tool fits
Two ways to define work
Windmill is a code-first platform. You write scripts in Python, TypeScript, Go, Bash, or SQL, and it wraps each one with a webhook and a generated UI. Dagu keeps the workflow in YAML and treats your scripts and binaries as the steps.
- Windmill stores and runs scripts inside the platform with auto-generated input forms.
- Dagu defines the graph in version-controlled YAML and shells out to commands.
- Both give you dependencies, retries, scheduling, and run history.
What you run to operate it
Windmill needs a PostgreSQL database for state and its job queue, and the typical setup runs server and worker containers against it. Dagu is a single binary that keeps state in files, so there is no database to provision, back up, or upgrade.
- Dagu starts as one process backed by local files.
- Add a queue and workers later without changing the workflow model.
- Windmill scales well but expects PostgreSQL to be present and managed.
When to choose Windmill instead
Windmill does more than orchestration, and that breadth is the point. If you want a place to host scripts as shareable endpoints and build internal apps and UIs around them, Windmill covers ground Dagu does not.
- You want a low-code app and UI builder, not just a runner.
- You want auto-generated forms, approval steps, and a large set of built-in integrations.
- Your team prefers writing logic as managed scripts rather than calling external commands.
FAQ
Practical questions before adopting Dagu
Does Dagu replace Windmill?
Not fully. Dagu replaces the orchestration part: scheduling, dependencies, retries, logs, and a UI for runs. It does not give you Windmill's low-code app builder, generated UIs, or its broad integration catalog. If you only need to schedule and observe commands, Dagu is the lighter option.
Does Dagu need PostgreSQL?
No. Dagu keeps state in local files and runs as a single binary, so there is no database to install or manage. Windmill relies on PostgreSQL for state and its job queue.
Can Dagu run Python and TypeScript scripts?
Yes. A step can run any command, so Python, TypeScript, Bash, or a compiled binary all work. The difference is that Dagu calls scripts on disk rather than hosting and managing them the way Windmill does.
Next step
Start with one workflow.
Install Dagu, move one fragile script or agent task into YAML, and decide from a real run history.