dagu

Docs · Examples · Live demo (username/password: demouser) · Discord

Dagu

Dagu turns scripts and commands into reliable YAML workflows. It adds schedules, dependencies, retries, approvals, logs, and a Web UI in one open-source binary. You do not need an external database or message broker.

Quick start

1. Install

On macOS or Linux:

curl -fsSL https://raw.githubusercontent.com/dagucloud/dagu/main/scripts/installer.sh | bash

On Windows, run this in PowerShell:

irm https://raw.githubusercontent.com/dagucloud/dagu/main/scripts/installer.ps1 | iex

The installers can add Dagu to PATH, set up a background service, and create the first admin account. See the Windows installation guide for service and manual installation options.

Prefer Docker? Start the Web UI with the official image:

docker run --rm -p 8080:8080 -v dagu-data:/var/lib/dagu ghcr.io/dagucloud/dagu:latest dagu start-all

Open http://localhost:8080. The named volume keeps workflows, logs, history, and settings between runs. See the Docker guide for Docker Compose, image tags, and host workflow mounts.

The native-install quickstart continues below. For Homebrew, npm, Kubernetes, and manual options, see all installation methods.

2. Run your first workflow

Save this as hello.yaml:

steps:
  - id: hello
    run: echo "Hello from Dagu!"
  - id: done
    run: echo "Workflow finished"
    depends: hello

Run it:

dagu start hello.yaml

3. Open the Web UI

Start the Web UI in the same directory:

dagu start-all --dags .

Open http://localhost:8080 to see the run, step logs, and history. The full quickstart also covers validation, expected output, and next steps.

Running Dagu as a persistent or shared service? Review server configuration and authentication before exposing it beyond localhost.

If Dagu is useful, click Star at the top of this page. It helps other developers find the project.

What Dagu gives you

• Keep your current scripts, commands, containers, and tools.
• Store readable workflow definitions in Git.
• Add dependencies, schedules, retries, timeouts, and approvals in YAML.
• Inspect live status, logs, and previous runs in the built-in Web UI.
• Start on one machine, then add queues or distributed workers if the workload grows.

See it in action

Click the image to watch the short product walkthrough.

Run details	Step logs

You can also open the live demo and sign in with username demouser and password demouser.

Why Dagu

Cron is easy to start but gives you little visibility once jobs depend on each other. Larger orchestrators solve that problem by adding services and a framework. Dagu keeps the operating model small:

Traditional orchestrator              Dagu

Web server                            dagu start-all
Scheduler                             ├── Web UI
Workers                               ├── Scheduler
Database                              ├── Executor
Message broker                        └── Local file-backed state
Language runtime

The workflow calls the software you already use. It does not require you to move that code into a Dagu-specific framework.

A practical workflow

This example runs a nightly report, retries the data step, and keeps the order explicit:

schedule: "0 2 * * *"

steps:
  - id: extract
    run: python extract.py
    retry_policy:
      limit: 3
      interval_sec: 30

  - id: report
    run: ./build-report.sh
    depends: extract

  - id: archive
    run: tar -czf report.tgz report/
    depends: report

Dagu can also run containers, Kubernetes Jobs, SSH commands, SQL, HTTP requests, human tasks, and reusable actions. Browse the workflow examples or the YAML reference when you need them.

Nested workflows

A step can run another DAG. Sub-DAGs can live in the same file after ---, and parallel fans one sub-DAG out over a list of items. This example works as-is:

steps:
  - id: check
    action: dag.run
    with:
      dag: probe
      params:
        url: ${ITEM}
    parallel:
      items:
        - https://example.com
        - https://example.org
        - https://example.net
      max_concurrent: 2

---
name: probe
params:
  - name: url
    type: string
steps:
  - id: fetch
    run: curl -fsS -o /dev/null -w '%{http_code}\n' "${params.url}"

Each URL becomes its own child run with separate logs, status, and retries. The same mechanism composes larger systems: shared DAGs in their own files, called from many parents.

See Sub-DAGs.

LLM-directed workflows

With type: controller, steps become a catalog and tasks state the goals; an LLM decides which step runs next until the goals are met. This example triages the machine it runs on, and works as-is with an OpenRouter API key:

type: controller

secrets:
  - name: OPENROUTER_API_KEY
    provider: env
    key: OPENROUTER_API_KEY

llm:
  provider: openrouter
  model: deepseek/deepseek-v4-flash

steps:
  - name: disk
    description: Show filesystem usage.
    run: df -h
    output: DISK
  - name: load
    description: Show uptime and load average.
    run: uptime
    output: LOAD
  - name: processes
    description: List processes with CPU and memory usage.
    run: ps aux | head -20
  - name: summarize
    description: Write the health summary. Run last, after the checks.
    action: chat.completion
    with:
      prompt: |
        Summarize this machine's health in three sentences:
        ${DISK}
        ${LOAD}

tasks:
  - name: triage
    description: >
      Finished when the machine has been checked and a health summary has been
      written. Inspect processes only if disk or load looks unhealthy.

There is no fixed order: the controller picks probes, digs deeper only when something looks off, and ends by writing the summary. Put it on a schedule and it becomes a nightly check that explains itself.

The summarize step uses chat.completion: a plain LLM call that works in any workflow, shares the workflow's llm config, and supports tool use.

See Controller Workflows.

Operate Dagu from your AI tools

The direction also reverses: AI tools can run Dagu. The MCP endpoint (http://localhost:8080/mcp) lets MCP clients inspect workflows, start and control runs, and read results.

MCP Apps hosts can render run-related dagu_read and dagu_execute results in an interactive inspector with step status, scheduler and per-step logs, refresh, stop, retry, and a link to the full run page in Dagu. Other MCP clients continue to receive the same text and structured results.

For workflow-authoring help in Claude Code, Codex, Gemini CLI, and other coding tools, install the Dagu skill:

gh skill install dagucloud/dagu dagu

See the MCP guide.

Common uses

• Replace fragile cron chains while keeping the underlying scripts.
• Run ETL, reporting, backup, media, and infrastructure jobs.
• Coordinate Docker, Kubernetes, SSH, SQL, and HTTP work in one graph.
• Give operators a controlled way to run approved internal tasks.
• Keep automation close to data on servers, edge devices, or private networks.
• Distribute heavier workloads to workers selected by labels.

Ways to run Dagu

The same YAML works across these models. See deployment models for the architecture, security boundaries, and setup details.

Learn more

Development

Prerequisites: Go 1.26+, Node.js, and pnpm.

git clone https://github.com/dagucloud/dagu.git
cd dagu
make build
make test
make lint

See CONTRIBUTING.md for the development workflow and code standards.

Community

• Discord for questions and discussion
• GitHub Issues for bugs and feature requests
• Bluesky for project updates
• GitHub Sponsors to support maintenance

Thanks to /bin labs and everyone who has contributed code, documentation, testing, or feedback.

License

Dagu is licensed under GNU GPLv3. See LICENSING.md for embedded API and commercial embedding terms.