Local-first orchestration that just works
Define workflows in declarative YAML over your existing commands and tools. One open-source binary adds schedules, retries, approvals, logs, and a Web UI, with state in local files. No database, no decorators, no framework. The same engine runs AI: coding agents as steps, LLM calls, and human approval gates.
Why Dagu exists
Most teams that land here are not looking for a workflow platform. Their scripts and containers already work. The scheduler around them is the problem: it takes more time to operate than it saves.
The same complaints come up in every conversation:
Orchestration is not your main work. A big platform brings its own database, its own worker fleet, its own upgrades and alerts. You wanted to schedule some jobs. Now you operate a second system.
A workflow is configuration, not a program. Order, retries, schedules, approvals: you declare them; there is no logic to write. Written in Python, the workflow definition itself starts having bugs and dependency conflicts.
Decorators lock the engine into your code. Once @dag and @task are on every function, the orchestrator lives inside your business logic. Removing it means a rewrite.
A script should not know its schedule. The script that moves data does not need to know when it runs or who approved it.
Dagu's answer: the workflow is one YAML file. It holds the structure: order, schedule, retries, approvals. Your scripts and containers do the work, unchanged, in whatever language they are written in. The engine is one binary writing state to local files.
The idea in one file
Your repository already has the logic:
scripts/extract.py
scripts/build-report.shAdd one file that holds only the structure:
schedule: "0 2 * * *"
steps:
- id: extract
run: python scripts/extract.py
retry_policy:
limit: 3
interval_sec: 30
- id: report
run: ./scripts/build-report.sh
depends: extractThat is the entire integration. No imports, no decorators, nothing rewritten. Delete the YAML and your scripts still run. Keep it, and every run gets a dependency graph, retries, per-step logs, history, and a Web UI.
Run your first workflow
Install Dagu on macOS or Linux:
curl -fsSL https://raw.githubusercontent.com/dagucloud/dagu/main/scripts/installer.sh | bashThe installer can add Dagu to your PATH, set up a background service, and create the first admin account. See Installation for Windows, Docker, Homebrew, npm, and manual options.
Save this as health.yaml. Two checks run in parallel, then Dagu turns their output into a Markdown artifact:
steps:
- id: system
run: uname -a
output: SYSTEM
- id: disk
run: df -h .
output: DISK
- id: report
action: template.render
with:
template: |
# System health
## System
~~~text
{{ .system }}
~~~
## Disk usage
~~~text
{{ .disk }}
~~~
data:
system: ${SYSTEM}
disk: ${DISK}
stdout:
artifact: health-report.md
depends: [system, disk]Start the scheduler and Web UI in the same directory:
dagu start-all --dags .Open http://localhost:8080 and start health from the UI. The system and disk steps run in parallel, and report waits for both. Open the run's Artifacts tab to preview or download health-report.md. The dependency graph, per-step logs, and full run history are all there. The full quickstart covers command-line runs, Docker, parameters, retries, and other fundamentals.
See the Web UI
Want to explore without installing anything? Open the live demo and sign in with demouser / demouser.
What Dagu adds
Keep your existing tools
Run shell commands, scripts, containers, SSH commands, SQL, HTTP requests, and other tools without rewriting them into a framework.
See every run
Use the Web UI to inspect live status, read step logs, review history, retry failures, and edit workflow YAML.
Keep runbooks with workflows
Write Markdown, preview Mermaid diagrams, organize nested Wiki pages, search their contents, and synchronize them through Git.
Make jobs reliable
Add dependencies, schedules, retries, timeouts, approvals, notifications, and artifacts in the workflow file.
Start on one machine
Use local file-backed state first. Add queues or distributed workers later if the workload outgrows one machine.
What Dagu is not
- Dagu is not a durable-execution SDK. If you want workflow logic as typed code with replay guarantees inside your application, use Temporal; that is what it is built for.
- It is not a Python data platform either. Teams that live inside Airflow operators and providers get real value from that ecosystem, and Dagu does not try to replace it.
- It does not manage infrastructure. Dagu runs commands wherever you put the binary, and provisioning the machines stays your job.