You have bash scripts that already work. Someone suggests Airflow. Six months later you operate Postgres, Redis, and a scheduler fleet, and every script imports framework decorators it did not need before.
Dagu (~4.6k GitHub stars, GPL-3.0, Go) takes the opposite bet: one self-contained binary with a web UI, file-backed state, no mandatory database or message broker. You describe a DAG in YAML next to your scripts; Dagu adds cron schedules, dependencies, retries, human tasks, logs, and history. Shell, Docker, Kubernetes Jobs, and SSH steps stay ordinary commands. Remove the YAML and nothing about the script changes.
What you get
- Declarative workflows — steps, parallel branches, sub-DAGs, concurrency limits, overlap and catch-up policies.
- Executors — local commands, containers, k8s jobs, remote SSH, plus actions via Dagu's plugin-style model (see current docs for the full list).
- Operations UI — run details, per-step logs, built-in wiki pages for runbooks.
- Integrations — webhooks, notifications, optional GitHub-driven triggers on private infra.
- MCP server — inspect workflows and control runs from agent tools if that fits your stack.
- Scale — single node first; workers and Helm chart when you outgrow one box; optional Dagu Console for multi-server visibility (opt-in, metadata outbound only per upstream).
How it compares (in plain terms)
Airflow is the heavy data-platform orchestrator. Cronicle and Cronmaster focus on cron-style jobs with a UI. Dagu sits in the middle: more than cron, far lighter than Airflow, with YAML instead of Python DAG code. Upstream also names Temporal as the "durable execution SDK" lane; Dagu is for teams who refuse to move business logic into an orchestration SDK.
Why self-host?
Small footprint. Marketing copy and benchmarks claim thousands of runs per day on modest hardware because state lives on disk under ~/.dagu (or your volume mount), not in a shared metadata cluster you must babysit.
Air-gapped and edge friendly. No cloud control plane required; fits shops that need automation on a factory floor VPS or a locked-down Canadian datacenter.
Credentials stay local. SSH and scripts run where you install Dagu; you are not shipping secrets to a SaaS scheduler.
GPL-3.0. Internal ops use is straightforward; understand copyleft if you redistribute Dagu as a service to customers.
Quick start
curl -fsSL https://raw.githubusercontent.com/dagucloud/dagu/main/scripts/installer.sh | bash
# hello.yaml
# steps:
# - id: hello
# run: echo "hello from Dagu"
dagu start hello.yaml
dagu start-all --dags . # UI on :8080Docker:
docker run --rm -v ~/.dagu:/var/lib/dagu -p 8080:8080 \
ghcr.io/dagucloud/dagu:latest dagu start-allPut TLS and auth in front of 8080 on anything internet-facing. If workflows run Docker steps from inside the container, read upstream's note about mounting the socket (that grants host-level container control).
Who it's for (and who should skip it)
Good fit: ops teams wrapping existing bash and SQL scripts; MSPs running SSH maintenance across client boxes; small data teams who want DAG visibility without a platform team; edge and IoT polling with a browser to debug failures.
Skip it: if you already run Airflow well and live in Python operators; if you need Temporal-grade durable function semantics across microservices; if a single crontab UI is enough.
Hosting in Canada
Dagu is a strong fit for a modest CloudBox VPS: back up the data directory, monitor disk growth from logs and history, and schedule backups of workflow YAML in git.
Talk with Swift Host for sizing a Canadian self-hosted Dagu box, TLS, and backup scope. We are in St. Albert and actually answer the phone.
