Rundeck alternative
Runbook automation without a JVM, a SQL database, or GUI-authored jobs.
Dagu is a Rundeck alternative for operations teams that want scheduled jobs, on-demand runbooks, and a web UI from one small binary. Job definitions live in git as YAML instead of behind a console, state lives in files instead of MySQL or Postgres, and existing servers are reached over SSH or with labeled workers. This page also covers the migration path and the places Rundeck remains the stronger choice.
# restart-app.yaml
params:
- name: host
default: app01.internal
ssh:
user: ops
host: ${params.host}
key: ~/.ssh/ops_key
steps:
- id: drain
run: /opt/app/bin/drain --wait
- id: restart
run: sudo systemctl restart app
depends: [drain]
- id: health_check
run: curl -fsS http://localhost:8080/healthz
retry_policy:
limit: 5
interval_sec: 10
depends: [restart]
handler_on:
failure:
run: ./scripts/notify-oncall.sh
Execution order
One binary with file-backed state, no JVM and no SQL database
Jobs are YAML in version control, reviewed like any other change
SSH steps and labeled workers reach existing servers
SSO, RBAC, and audit logging at a listed per-server price
At a glance
Rundeck vs. Dagu for ops automation
One binary with file-backed state; queues and workers are optional.
Java service plus MySQL or Postgres in production.
Declarative YAML reviewed in git.
Web console first; YAML export and SCM sync as a secondary path.
SSH steps, or labeled workers connecting outbound over mTLS gRPC.
Node dispatch from a resource-model inventory over SSH or WinRM.
System-wide roles, with SSO and audit logging on the licensed tier.
Fine-grained ACL policies per project and per job.
Free with unlimited servers; paid plans licensed per Dagu server with unlimited workers.
Open-source core; commercial Process Automation priced by quote.
Single scheduler instance; HA is a deployment design you own.
Commercial tier offers cluster configurations.
In depth
Where each tool fits
Keep the runbook, drop the stack
Rundeck runs as a Java service in front of a SQL database, with jobs defined per project through the web console. Dagu keeps the same operational concepts inside a single process that stores its state in files.
- Jobs become DAG files, job steps become steps, and error handlers map to handler_on.failure.
- Job options map to params: typed inputs with defaults, supplied from the UI, CLI, or API at run time.
- No MySQL or Postgres to size and back up, and no JVM heap to tune; a small VM runs it.
Jobs as code, not console clicks
Rundeck can export definitions and sync them through its SCM plugin, but the console is the primary authoring surface. Dagu inverts that: the YAML file in your repository is the definition.
- Every job is a YAML file in git, so changes arrive as reviewable diffs instead of console edits.
- dagu validate checks generated and hand-written definitions in CI before they reach the scheduler.
- The web UI stays for operating: start runs with parameters, watch logs, retry, and suspend schedules.
Reach existing servers without installing an agent
Rundeck dispatches commands to nodes from a resource-model inventory. Dagu covers the same ground with two mechanisms: SSH for agentless hosts, and workers where a persistent executor is the better fit.
- Use the SSH executor to run steps on existing Linux and UNIX hosts with no resident agent.
- Start dagu worker on machines that need local execution, and route steps to them with worker_selector labels.
- Workers connect outbound over mTLS-protected gRPC, so segmented networks need no inbound ports.
Separate the people who run jobs from the people who change them
The classic Rundeck deployment hands a safe subset of operations to a wider group. Dagu's licensed self-host tier covers that separation with roles, SSO, and audit logging.
- The operator role can start and stop runs but cannot edit definitions; viewer is read-only; developer and manager can change workflows.
- Sign in through your existing identity provider with OIDC rather than maintaining a second user directory.
- Audit logging records administrative and security-relevant activity for review.
A listed price instead of a sales call
Rundeck's commercial tier became PagerDuty Process Automation, priced by quote. Dagu's community tier is free with unlimited servers and workers, and the licensed tier has a listed per-server price.
- Community covers the full orchestration engine, web UI, cron scheduling, and the Docker, SSH, and HTTP executors.
- Licensed self-host starts at $500 per year for three server licenses and adds SSO, RBAC, audit logging, incident routing, and email support.
- Workers stay unlimited on every plan, so adding an executing host never changes the licence count.
Where Rundeck is the stronger choice
A comparison that only lists wins is not useful during an evaluation. These are the places a Rundeck shop should expect extra work or stay put.
- Rundeck's node inventory is richer: resource-model sources and node filters can fan one command out across hundreds of hosts. Dagu targets steps at SSH hosts or labeled workers and has no fleet-inventory concept.
- Rundeck's per-project and per-job ACL policies can hand exactly one parameterized job to a helpdesk group. Dagu's roles are system-wide, not per job.
- Commercial Process Automation offers cluster configurations for high availability, and the plugin ecosystem, including WinRM node executors and notification plugins, is larger.
FAQ
Practical questions before adopting Dagu
Is Dagu a drop-in replacement for Rundeck?
No. The concepts map cleanly: jobs become DAG files, job steps become steps, options become params, and error handlers become handler_on.failure. But there is no importer, and Rundeck's node-filter model has no direct equivalent. Migration means rewriting each job as a YAML file, which is mechanical for command-based jobs.
Can people still trigger jobs with parameters from a UI?
Yes. params declare typed inputs with defaults, and a run can be started from the web UI, CLI, or API with values supplied at run time. What Dagu does not have is Rundeck's per-job ACL for exposing exactly one job to a group; roles apply system-wide.
How does Dagu run commands on many servers?
Two ways. The SSH executor runs steps on agentless hosts, and distributed mode starts workers on machines that pull steps matched by worker_selector labels. There is no resource-model inventory; a fan-out across a large fleet is expressed with parallel steps or a wrapper script.
Does Dagu need a database like Rundeck does?
No. Run history, logs, and queue state are files on disk. That is also what makes closed networks straightforward: one binary, no JVM, and no external services to reach.
What replaces Rundeck's schedules and webhooks?
Cron schedules with timezone support are built in, and runs can be triggered externally through the API or a webhook with the payload available to the workflow. Concurrency is capped per workflow by default and shared limits use named queues.
Next step
Start with one workflow.
Install Dagu, move one fragile script or agent task into YAML, and decide from a real run history.