Make data scripts to durable workflows in minutes.

Docs | Examples | Support & Community

Dagu turns existing scripts, SQL jobs, containers, SSH commands, and runbooks into scheduled, observable pipelines that run where your data already lives.

Bring your existing data jobs as they are. Dagu adds the operational layer they are missing: scheduling, durable execution, logs, artifacts, queues, a Web UI, API/webhooks, distributed workers, and notifications.

Highlights:

• Local-first: Workflows are file-based: One binary, no external database or broker required. Air-gapped ready.
• No rewrite: Turn shell scripts, Python jobs, SQL, dbt, DuckDB, containers, and data-processing runbooks into pipelines without rewriting them into a framework.
• AI-agent ready: Use your favorite AI agent through MCP to create, improve, debug, and run workflows.

For a quick look at how workflows are defined, see the examples.

schedule:
  - "0 2 * * *"
overlap_policy: skip
catchup_window: "6h"

tools:
  - jqlang/jq@jq-1.7.1
  - duckdb/duckdb@v1.5.2

steps:
  - id: extract
    run: ./scripts/extract.sh > data/raw.json
    retry_policy:
      limit: 3
      interval_sec: 30

  - id: validate
    run: jq -e '.rows | length > 0' data/raw.json
    depends: extract

  - id: load
    run: duckdb warehouse.duckdb < sql/load.sql
    depends: validate

The tools block pins external CLIs for reproducible runs. Dagu resolves packages such as jqlang/jq and duckdb/duckdb through the Aqua standard registry, installs the pinned versions before the run, and exposes them on PATH so workers do not depend on whichever jq or duckdb version happens to be installed locally.

Run Details	Step Logs	Documents

Try it live: Live Demo (credentials: demouser / demouser)

  Traditional Orchestrator          Dagu
  ┌────────────────────────┐        ┌──────────────────┐
  │  Web Server            │        │                  │
  │  Scheduler             │        │  dagu start-all  │
  │  Worker(s)             │        │                  │
  │  PostgreSQL            │        └──────────────────┘
  │  Redis / RabbitMQ      │         Single binary.
  │  Python Runtime        │         Self-hosted.
  └────────────────────────┘         Adds scheduling, retries, and approvals around existing automation.
    6+ services to manage

Dagu stores state in local files. How much it can run depends on the machine and the workload. CPU, memory, disk, workflow characteristics, queue settings, and worker capacity all matter.

• Throughput: On one machine, Dagu can run thousands of workflow runs per day when the hardware and workflow shape fit the workload.
• Load control: Use queues, concurrency limits, resource limits, and optional distributed workers to decide how many runs execute at once and where they run.

macOS/Linux:

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

Homebrew:

brew install dagu

Windows (PowerShell):

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

Docker:

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

Kubernetes (Helm):

helm repo add dagu https://dagucloud.github.io/dagu
helm repo update
helm install dagu dagu/dagu --set persistence.storageClass=<your-rwx-storage-class>

Replace <your-rwx-storage-class> with a StorageClass that supports ReadWriteMany. See charts/dagu/README.md for chart configuration.

The script installers run a guided wizard that can add Dagu to your PATH, set it up as a background service, and create the initial admin account. Homebrew, npm, Docker, and Helm install without the wizard. See Installation docs for all options.

Create hello.yaml:

steps:
  - id: hello
    run: echo "hello from Dagu"

Run the workflow with:

dagu start hello.yaml

dagu start-all

Visit http://localhost:8080

Dagu exposes a built-in MCP server from the running HTTP server. Start Dagu, then configure MCP-capable chat or coding agents to use the Streamable HTTP endpoint:

http://localhost:8080/mcp

Use MCP when you want an AI agent to read Dagu state, preview or apply workflow changes, and start, enqueue, retry, or stop runs through dagu_read, dagu_change, and dagu_execute. See the MCP setup guide.

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

gh skill install dagucloud/dagu dagu

Run Dagu on one machine, scale out with distributed workers, or use a managed Dagu instance operated by us. See the Deployment Models guide.

Local Single-Server	Self-Hosted
Managed Server	Hybrid

• Community self-host: No license key required. You operate the server, storage, upgrades, networking, and workers. Start with the installation guide.
• Self-host license: Adds SSO, RBAC, audit logging, and incident SaaS integration to Dagu. See self-host licensing.
• Dagu managed instance: Includes its own managed license. Private workers can run on your infrastructure.

Managed Dagu instances do not expose a Docker daemon or Docker socket. Workflows that need Docker step execution should use self-hosted Dagu or a private worker with Docker access.

Dagu can run in three configurations:

Standalone: A single dagu start-all process runs the HTTP server, scheduler, and executor. Suitable for single-machine deployments.

Coordinator/Worker: The scheduler enqueues jobs to a local file-based queue, then dispatches them to a coordinator over gRPC. Workers long-poll the coordinator for tasks, execute DAGs locally, and report status back. Workers can run on separate machines and are routed tasks based on labels.

Headless: Run without the web UI (DAGU_HEADLESS=true). Useful for CI/CD environments or when Dagu is managed through the CLI or API only.

Standalone:

  ┌─────────────────────────────────────────┐
  │  dagu start-all                         │
  │  ┌───────────┐ ┌───────────┐ ┌────────┐ │
  │  │ HTTP / UI │ │ Scheduler │ │Executor│ │
  │  └───────────┘ └───────────┘ └────────┘ │
  │  File-based storage (logs, state, queue)│
  └─────────────────────────────────────────┘

Distributed:

  ┌────────────┐                   ┌────────────┐
  │ Scheduler  │                   │ HTTP / UI  │
  │            │                   │            │
  │ ┌────────┐ │                   └─────┬──────┘
  │ │ Queue  │ │  Dispatch (gRPC)        │ Dispatch / GetWorkers
  │ │(file)  │ │─────────┐               │ (gRPC)
  │ └────────┘ │         │               │
  └────────────┘         ▼               ▼
                    ┌─────────────────────────┐
                    │      Coordinator        │
                    │  ┌───────────────────┐  │
                    │  │ Dispatch Task     │  │
                    │  │ Store (pending/   │  │
                    │  │ claimed)          │  │
                    │  └───────────────────┘  │
                    └────────▲────────────────┘
                             │
                   Worker poll / task response
                   Heartbeat / ReportStatus /
                   StreamLogs (gRPC)
                             │
               ┌─────────────┴─────────────┐
               │             │             │
          ┌────┴───┐    ┌────┴───┐    ┌────┴───┐
          │Worker 1│    │Worker 2│    │Worker N│ Sandbox execution of DAGs
          │        │    │        │    │        │
          └────────┘    └────────┘    └────────┘

steps:
  - id: extract
    run: ./extract.sh

  - id: transform_a
    run: ./transform_a.sh
    depends: extract

  - id: transform_b
    run: ./transform_b.sh
    depends: extract

  - id: load
    run: ./load.sh
    depends: [transform_a, transform_b]

%%{init: {'theme': 'base', 'themeVariables': {'background': '#18181B', 'primaryTextColor': '#fff', 'lineColor': '#888'}}}%%
graph LR
    A[extract] --> B[transform_a]
    A --> C[transform_b]
    B --> D[load]
    C --> D
    style A fill:#18181B,stroke:#22C55E,stroke-width:1.6px,color:#fff
    style B fill:#18181B,stroke:#22C55E,stroke-width:1.6px,color:#fff
    style C fill:#18181B,stroke:#22C55E,stroke-width:1.6px,color:#fff
    style D fill:#18181B,stroke:#3B82F6,stroke-width:1.6px,color:#fff

tools:
  - jqlang/jq@jq-1.7.1

steps:
  - id: inspect
    run: jq --version

  - id: summarize
    action: python-script@v1
    with:
      input:
        rows: [42, 8]
      script: |
        return {"total": sum(input["rows"])}

Dagu installs declared portable CLIs before the DAG run, exposes them on PATH for host command steps, and caches them on each worker. Tool provisioning uses aqua as the default provider. See the Tools documentation and Dagu Actions for more details.

steps:
  - id: notify
    action: acme/dagu-action-notify@v1.2.0
    with:
      text: "Build ${BUILD_ID} finished"

  - id: audit
    depends: notify
    run: echo "Notification result: ${notify.outputs.messageId}"

A third-party Dagu Action package contains a DAG, manifest, schemas, and helper files behind an action: reference. See the Dagu Actions and Third-Party Actions documentation for details.

steps:
  - name: build
    container:
      image: node:20-alpine
    run: npm run build

steps:
  - name: batch-job
    action: kubernetes.run
    with:
      namespace: production
      image: my-registry/batch-processor:latest
      resources:
        requests:
          cpu: "2"
          memory: "4Gi"
      command: ./process.sh

steps:
  - name: deploy
    action: ssh.run
    with:
      host: prod-server.example.com
      user: deploy
      key: ~/.ssh/id_rsa
      command: cd /var/www && git pull && systemctl restart app

steps:
  - name: extract
    action: dag.run
    with:
      dag: etl/extract
      params:
        SOURCE: s3://bucket/data.csv

  - name: transform
    action: dag.run
    with:
      dag: etl/transform
      params:
        INPUT: ${extract.outputs.result}
    depends: extract

  - name: load
    action: dag.run
    with:
      dag: etl/load
      params:
        DATA: ${transform.outputs.result}
    depends: transform

steps:
  - name: flaky-api-call
    run: curl -f https://api.example.com/data
    retry_policy:
      limit: 3
      interval_sec: 10
    continue_on:
      failure: true

schedule:
  - "0 */6 * * *"          # Every 6 hours
overlap_policy: skip       # Skip if previous run is still active
catchup_window: "5h"       # Catch up missed runs when scheduler is down for up to 5 hours
  
timeout_sec: 3600
handler_on:
  failure:
    run: notify-team.sh
  exit:
    run: cleanup.sh

steps:
  - id: review
    action: agent.run
    with:
      task: Review the README.md file and return concise Markdown findings.
      max_iterations: 10
    stdout:
      artifact: review.md

  - id: approval
    action: noop
    depends: review
    approval:
      prompt: Review the review.md artifact. Approve to post an issue with the findings, or reject to skip.

  - id: read_review
    action: artifact.read
    depends: approval
    with:
      path: review.md

  - id: post_issue
    run: gh issue create --title "Review Findings" --body-file "${read_review.stdout}"
    depends: read_review

For more examples, see the Examples documentation.

Dagu includes built-in actions that run within the Dagu process or on the selected worker. Local shell commands use the run: field; structured work uses action:.

Custom Actions are inline reusable wrappers defined with the top-level actions field. They expand to built-in actions during DAG load, so you can wrap a common shell, HTTP, SQL, or other pattern behind a typed interface with validated input.

actions:
  webhook.send:
    input_schema:
      type: object
      additionalProperties: false
      required: [url, text]
      properties:
        url:
          type: string
        text:
          type: string
    template:
      action: http.request
      with:
        method: POST
        url: {{ .input.url }}
        headers:
          Content-Type: application/json
        body: |
          {"text": {{ json .input.text }}}

steps:
  - action: webhook.send
    with:
      url: https://hooks.example.com/ops
      text: deploy complete

See Custom Actions and the YAML Specification for the exact actions, action, and run field behavior.

Dagu Actions are official action packages maintained in the dagucloud GitHub organization. They use the same action package runtime as third-party action packages, but callers use the short form action: name@version.

Versions are required. Pin production workflows to a version tag or commit SHA. See Official Dagu Actions for the current Dagu Action list and exact input/output contracts.

For non-official packages, use Third-Party Actions such as action: owner/repo@version. They contain a dagu-action.yaml manifest and a DAG entrypoint, run as sub-DAGs, and are transferred to distributed workers as workspace bundles after the reference is resolved. See Third-Party Actions for package layout and reference formats.

Dagu supports three top-level authentication modes, configured via DAGU_AUTH_MODE:

• none — No authentication
• basic — HTTP Basic authentication
• builtin — JWT-based authentication with user management, API keys, per-DAG webhook tokens, and optional OIDC/SSO integration

When using builtin auth, five roles control access:

API keys can be created with independent role assignments. Audit logging tracks all actions.

• TLS for the HTTP server (DAGU_CERT_FILE, DAGU_KEY_FILE)
• Mutual TLS for gRPC coordinator/worker communication (DAGU_PEER_CERT_FILE, DAGU_PEER_KEY_FILE, DAGU_PEER_CLIENT_CA_FILE)
• Secret management with three providers: environment variables, files, and HashiCorp Vault

For self-hosted production deployments, treat network exposure and execution boundaries as the primary controls:

• Prefer auth.mode: builtin for any shared or network-exposed instance. Use basic only for simple private setups, and avoid none outside isolated local development.
• Keep metrics: private unless the metrics endpoint is reachable only on a trusted private network.
• Bind Dagu to loopback or a private interface when possible. If you must use 0.0.0.0, place it behind a trusted reverse proxy, TLS, and network-level access controls.
• Leave terminal.enabled: false unless the instance is admin-only and tightly scoped.
• In distributed deployments, set peer.insecure=false and configure peer TLS when coordinator and workers communicate across host or network boundaries.
• Treat Docker socket mounts, root containers, and host-level executors as privileged access to the underlying machine.

See Server Configuration, Docker deployment, and Distributed execution for the operator-focused guidance.

Dagu exposes Prometheus-compatible metrics:

• dagu_info — Build information (version, Go version)
• dagu_uptime_seconds — Server uptime
• dagu_dag_runs_total — Total DAG runs by status
• dagu_dag_runs_total_by_dag — Per-DAG run counts
• dagu_dag_run_duration_seconds — Histogram of run durations
• dagu_dag_runs_currently_running — Active DAG runs
• dagu_dag_runs_queued_total — Queued runs
• dagu_workers_registered — Registered distributed workers
• dagu_worker_info — Worker heartbeat labels as key/value metadata
• dagu_worker_heartbeat_timestamp_seconds — Last worker heartbeat timestamp
• dagu_worker_health_status — Worker health by heartbeat freshness
• dagu_worker_pollers — Worker poller capacity by state
• dagu_worker_running_tasks — Running tasks per worker
• dagu_worker_oldest_running_task_age_seconds — Age of the oldest running task per worker

JSON or text format logging (DAGU_LOG_FORMAT). Logs are stored per-run with separate stdout/stderr capture per step.

• Slack and Telegram bot integration for run monitoring and status updates
• Email notifications on DAG success, failure, or wait status via SMTP
• Per-DAG webhook endpoints with token authentication

Dagu runs can write arbitrary files into DAG_RUN_ARTIFACTS_DIR, and Dagu stores them per run as Artifacts. In the Web UI, operators can browse the file tree, preview Markdown, text, and image files inline, and download any artifact when they need the raw file.

This is useful for generated reports, screenshots, charts, exported JSON or CSV files, and other outputs that do not fit simple key/value outputs.

See the Artifacts documentation and the Web UI guide for the full artifact browser workflow and screenshots.

• Cron scheduling with timezone support and multiple schedule entries per DAG
• Overlap policies: skip (default — skip if previous run is still active), all (queue all), latest (keep only the most recent)
• Catch-up scheduling: Automatically runs missed intervals when the scheduler was down
• Zombie detection: Identifies and handles stalled DAG runs (configurable interval, default 45s)
• Retry policies: Per-step retry with configurable limits, intervals, and exit code filtering
• Lifecycle hooks: onInit, onSuccess, onFailure, onAbort, onExit, onWait
• Preconditions: Gate DAG or step execution on shell command results
• High availability: Scheduler lock with stale detection for failover

The coordinator/worker architecture distributes DAG execution across multiple machines:

• Coordinator: gRPC server that manages task distribution, worker registry, and health monitoring
• Workers: Connect to the coordinator, pull tasks from the queue, execute DAGs locally, report results
• Worker labels: Route DAGs to specific workers based on labels (e.g., gpu=true, region=us-east-1)
• Health checks: HTTP health endpoints on coordinator and workers for load balancer integration
• Queue system: File-based persistent queue with configurable concurrency limits

# Start coordinator
dagu coordinator

# Start workers (on separate machines)
DAGU_WORKER_LABELS=gpu=true,memory=64G dagu worker

See the distributed execution documentation for setup details.

Precedence: Command-line flags > Environment variables > Configuration file (~/.config/dagu/config.yaml)

Go applications can import Dagu and start DAG runs from the host process:

import "github.com/dagucloud/dagu"

engine, err := dagu.New(ctx, dagu.Options{
	HomeDir: "/var/lib/myapp/dagu",
})
if err != nil {
	return err
}
defer engine.Close(context.Background())

run, err := engine.RunYAML(ctx, []byte(`
params:
  - MESSAGE
steps:
  - name: hello
    run: echo "${MESSAGE}"
`), dagu.WithParams(map[string]string{
	"MESSAGE": "hello from the host app",
}))
if err != nil {
	return err
}

status, err := run.Wait(ctx)
if err != nil {
	return err
}
fmt.Println(status.Status)

The embedded API is experimental and may change. See the embedded API documentation and examples/embedded.

OIDC variables: DAGU_AUTH_OIDC_CLIENT_ID, DAGU_AUTH_OIDC_CLIENT_SECRET, DAGU_AUTH_OIDC_ISSUER, DAGU_AUTH_OIDC_SCOPES, DAGU_AUTH_OIDC_WHITELIST, DAGU_AUTH_OIDC_AUTO_SIGNUP, DAGU_AUTH_OIDC_DEFAULT_ROLE, DAGU_AUTH_OIDC_ALLOWED_DOMAINS.

Full configuration reference: docs.dagu.sh/server-admin/reference

• Getting Started — Installation and first workflow
• Writing Workflows — YAML syntax, scheduling, execution control
• Workflow Schema at a Glance — Repository-level overview of the current YAML schema
• Tools — Pin external CLI packages in DAGs for reproducible host command steps
• Built-in Actions — Shell, Docker, Kubernetes, HTTP, SQL, Harness, and Agent Step
• Custom Actions — Inline actions: wrappers around built-in actions
• Dagu Actions — Official dagucloud/* action packages such as duckdb@v1, python-script@v1, and github-cli@v1
• Distributed Execution — Coordinator/worker setup
• Authentication — RBAC, OIDC, API keys
• Git Sync — Version-controlled DAG definitions
• GitHub Integration — Trigger Dagu runs from GitHub events, PR comments, releases, checks, and dispatches
• AI Agent — AI-assisted workflow authoring
• Changelog

• Discord — Questions and discussion
• GitHub Issues — Bug reports and feature requests
• Bluesky

Prerequisites: Go 1.26+, Node.js, pnpm

git clone https://github.com/dagucloud/dagu.git && cd dagu
make build    # Build frontend + Go binary
make test     # Run tests with race detection
make lint     # Run golangci-lint

See CONTRIBUTING.md for development workflow and code standards.

Premium Sponsors

Supporters

We welcome contributions of all kinds. See our Contribution Guide for details.

GNU GPLv3 - See LICENSE. See LICENSING.md for embedded API and commercial embedding notes.