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 AI agents
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 AI-agent step directly.
- Wrap scripts and binaries you already have without packaging each one as an image.
- Mix Docker steps with shell, HTTP, and SSH 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.
Argo Workflows vs. Dagu at a glance
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.
Start with one workflow.
Install Dagu, move one fragile script or agent task into YAML, and decide from a real run history.