Dagu vs Argo Workflows
Argo Workflows lives on Kubernetes. Dagu runs on a plain machine.
Both define DAGs and run steps in order. Argo Workflows is built into Kubernetes and schedules each step as a pod. Dagu is a single binary that calls the commands you already have, with no cluster 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]Single self-contained binary, no Kubernetes cluster
Declarative YAML that runs existing commands
No external database or message broker
Executors for shell, Docker, HTTP, SSH, SQL, sub-workflows, and Agent Harness steps
At a glance
Argo Workflows vs. Dagu at a glance
Single binary on a normal machine, backed by local files.
A Kubernetes cluster with a workflow controller.
A command: shell, Docker, HTTP, SSH, SQL, sub-workflow, or Agent Harness step.
A container that runs as a pod on the cluster.
Ops jobs, scripts, and mixed pipelines on hosts you already run.
Kubernetes-native and container-heavy or ML pipelines at scale.
In depth
Where each tool fits
Orchestration without a cluster underneath
Argo Workflows assumes a running Kubernetes cluster and a controller that turns each step into a pod. Dagu has no such requirement. You drop one binary on a server, a laptop, or a VM and it runs.
- Run on a normal machine with no Kubernetes, no controller, and no etcd.
- Keep state in local files instead of a separate database or broker.
- Start local, then move to queue-based or distributed mode when load grows.
Steps are commands, not just containers
In Argo Workflows every step is a container that runs in a pod. Dagu can run a container too, but it can also call a shell script, an HTTP endpoint, an SSH command, a SQL query, a sub-workflow, or an Agent Harness step.
- Wrap scripts and binaries you already have without packaging each one as an image.
- Mix Docker steps with shell, HTTP, SSH, and Agent Harness steps in the same workflow.
- Read runs, logs, and history in a built-in Web UI.
When to choose Argo Workflows instead
Argo Workflows is the better fit when Kubernetes is already your platform. It is Kubernetes-native, it schedules each step as its own pod, and it is designed for heavy container fan-out. Dagu does none of that.
- You run on Kubernetes and want workflows defined as CRDs next to your other manifests.
- You need per-step pod scheduling, node selectors, and cluster autoscaling for each task.
- Your pipelines fan out to thousands of containers across many nodes at once.
FAQ
Practical questions before adopting Dagu
Does Dagu replace Argo Workflows?
Not for every team. If you are standardized on Kubernetes and want each step to run as a pod, Argo Workflows is the right tool. Dagu is the better fit when you want to orchestrate commands on a normal machine without running a cluster.
Can Dagu run without Kubernetes?
Yes. Dagu is one self-contained binary that runs on a server, VM, or laptop. It needs no Kubernetes cluster, no external database, and no message broker.
Can Dagu still run containers?
Yes. Dagu has a Docker executor for steps that need a container. The difference is that containers are one option among shell, HTTP, SSH, SQL, and sub-workflow steps, not the only unit of execution.
Next step
Start with one workflow.
Install Dagu, move one fragile script or agent task into YAML, and decide from a real run history.