Dagu: Local-First Workflow Orchestration
/dagu
Dagu is a self-hosted workflow orchestrator that ships as a single Go binary with no database to manage, built for teams whose real job isn't running an orchestration platform. It wraps scheduling, retries, and approvals around scripts you already have instead of rewriting them as framework code. Reach for it over Airflow if you want that without a scheduler-plus-database stack; skip it if your org can't accept GPL-3.0 code.
What is Dagu?
Dagu is a workflow engine aimed at ops automation and AI-assisted operational tasks, packaged as one self-hosted executable with its own Web UI and no external database to run. Pipelines are defined as DAGs in declarative YAML instead of framework code, and each step can be a shell command, a Docker container, a Kubernetes Job, an SSH command, or an outside coding-agent CLI invoked through harness.run.
Dagu's Core Capabilities
- ✓Declarative YAML DAGs: step order, retries, schedules, and approval gates all sit in one file next to the scripts, not inside a framework's decorators.
- ✓No database to run: Dagu keeps state, logs, and its run queue in local files, so there's nothing extra to provision or patch.
- ✓Built-in MCP server: the running HTTP server exposes an MCP endpoint with dagu_read, dagu_change, and dagu_execute tools so agents can inspect and drive runs.
- ✓External coding-agent harness: a harness.run action runs CLIs such as Codex, Gemini CLI, Claude Code, or Pi as a step, with output captured to an artifact.
- ✓Human-in-the-loop steps: a run can pause for manual review before continuing, which matters for anything a bot shouldn't do unsupervised.
- ✓Tool pinning and caching: a tools block installs specific CLI versions per worker through the aqua provider, down to a package@version#sha256 pin.
- ✓Three run modes: standalone (one process for UI, scheduler, and executor), coordinator/worker (jobs dispatched over gRPC to labeled workers), and headless for CI/CD.
- ✓Secret masking: values pulled from a declared provider get redacted from logs and the Web UI automatically.
Practical Applications for Dagu
- •ETL and data pipelines: wrap extraction scripts, SQL queries, and dbt commands in a DAG so failures retry and every run leaves a log instead of a silent cron failure.
- •Replacing brittle cron chains: turn interdependent scheduled jobs into a DAG with a UI, retries, and notifications instead of a pile of bash scripts nobody wants to touch.
- •Media transcoding: run ffmpeg jobs as steps and spread conversion load across workers instead of bottlenecking one machine.
- •Server automation over SSH: keep remote command output, results, and notifications in one place instead of scattered shell history.
- •Container and Kubernetes jobs: run Docker containers or Kubernetes Jobs as workflow steps without building a custom control plane.
- •Support-team self-service: let non-engineers trigger approved diagnostic or database-query workflows without opening a ticket to engineering.
Getting Started with Dagu
Dagu installs from a curl script on macOS/Linux, via Homebrew, via npm (npm install -g --ignore-scripts=false @dagucloud/dagu), via a PowerShell script on Windows, as a Docker image, or through a Helm chart on Kubernetes. The shell/PowerShell paths walk through a setup step that can put Dagu on your PATH, turn it into a background service, and set up an admin account; the Homebrew, npm, Docker, and Helm paths skip that step. To try it, write a hello.yaml with one step (run: echo "hello from Dagu") and run dagu start hello.yaml. For the full server and UI, run dagu start-all --dags . and open localhost:8080.
Strengths
- ✓Single binary, no external dependencies: no Postgres, no Redis, no Python environment to keep patched just to run a schedule.
- ✓Scripts stay scripts. Delete the YAML and they still run exactly as before, since Dagu never gets imported into the code.
- ✓MCP support is native rather than bolted on: dagu_read, dagu_change, and dagu_execute give any MCP-capable agent real control over runs.
- ✓Approvals and secret masking ship built in, so human review steps and credential handling don't need a separate add-on.
- ✓Runs anywhere the data already lives, on-prem, air-gapped, edge, or cloud, since nothing depends on reaching a managed service.
Considerations Before Adopting Dagu
- △Dagu is GPL-3.0 licensed, a strong copyleft license worth checking against your company's policy before building internal tooling on top of it.
- △Single sign-on, role-based access control, audit trails, and the incident SaaS hook sit behind a paid self-host license; the free community edition leaves those controls to you.
- △The step-level result caching described for build workflows currently runs locally only, so that reuse doesn't yet extend across distributed workers.
- △The README states no version number or release history, and names no specific production adopters beyond the general throughput figures it gives.
- △There's no language SDK: every step calls a shell command, a container, or the CLI harness, which won't suit anyone wanting native task functions instead of YAML plus subprocess calls.
Dagu Alternatives and Comparisons
Frequently Asked Questions
Dagu's code is open source under the GPL-3.0 license, and the community self-host edition needs no license key to run. A separate paid self-host license layers on single sign-on, role-based access control, audit trails, and an incident SaaS hook.
Dagu runs self-contained, with state, logs, and its run queue kept in local files on the machine that runs it, so no external database or broker is needed.
Dagu steps can run Kubernetes Jobs, Docker containers, plain shell commands, remote SSH calls, and external coding-agent CLIs through harness.run, plus anything wrapped as a Dagu Action.
Dagu offers a built-in MCP server with dagu_read, dagu_change, and dagu_execute tools, letting any MCP-capable agent inspect, edit, and start workflow runs directly.
Dagu's README states a single machine can handle thousands of workflow runs per day, with distributed worker mode available when one node isn't enough; actual capacity still depends on your CPU, memory, and workflow shape.
Dagu includes secret management that pulls values from a declared provider and masks them from logs and the Web UI automatically, so credentials shouldn't leak into run output.
The problem it solves
Teams that just need a handful of scripts scheduled and watched end up choosing between cron, which tracks nothing past an exit code, and Airflow, which means running a scheduler, a metadata database, and a worker fleet to execute a few jobs, plus rewriting those scripts as @dag/@task framework code. You wanted a schedule, not a platform. Dagu's answer is to leave scripts as scripts and wrap scheduling, retries, and history around them in one YAML file and one process instead of adding a second system to operate.
Who should try it — and who should skip
Try Dagu if you're maintaining a pile of cron jobs, SSH scripts, or ad hoc automation and want dependencies, retries, and a Web UI without standing up Airflow's metadata database and worker fleet, especially if an AI agent needs to trigger or inspect those runs through MCP. Skip it if you need a mature ecosystem of prebuilt integrations, want durable-execution guarantees baked into a language SDK the way Temporal offers, or your organization can't accept GPL-3.0 code in its stack.
Related repositories
Still deciding about dagu?
One click hands the question to an AI along with this page — see what it says about dagu.