Automation & Ops workflow-orchestrationyaml-workflowscron-schedulingdurable-executionhuman-in-the-loopdistributed-workersmcp-servercontainer-automation

Dagu Workflow Orchestrator

Add scheduling, retries, approvals, and visibility to existing scripts, containers, and agent jobs with self-hosted YAML workflows.

FollowAgents review · FARS-2.1
Use with care
74/ 100 5-point scale 3.7 / 5
1 2 3 4 5 6
1Trust17 / 29 · 2.9/5

For least privilege, chart CI explicitly limits its token to read-only, while Helm supports a dedicated service account, RBAC, SSO, and existing Secrets. The product can nevertheless execute local shells, SSH commands, containers, Kubernetes jobs, and MCP operations, with no demonstrated universal runtime sandbox or per-operation permission model, so it scores 2. Human confirmation is supported through human.task, approval, and preview/apply flows, but it is not mandatory for every high-impact command, so it scores 2. Data flows through local files, HTTP/MCP, gRPC workers, third-party actions, external agents, and credential locations are described reasonably well; a complete destination or telemetry inventory is absent, so transparency scores 2. Secret providers, log masking, existing Kubernetes Secrets, and redaction guidance address sensitive data, but implementation, encryption, and default-exposure details are not shown, so this scores 2. Dependencies are versioned, GitHub Actions are commit-pinned, and tools may be hash-pinned; deductions apply for the very large dependency surface, remote-script installation, automatically moving aqua registry, and no shown vulnerability-scanning policy, yielding 2. External effects are explicit in command, SSH, issue-posting, and run-control examples, with optional approvals, but arbitrary commands and MCP execution remain broad, yielding 2. Retries, stopping, history, exit cleanup, and result reuse aid recovery, but there is no general transactional rollback or undo guarantee, so rollback scores 1. The module path, security contact, and a source copyright header provide limited attribution, but publisher identity is unverified and no complete maintainer roster is shown, so source attribution scores 1.

2Reliability9 / 14 · 3.2/5

The README, Helm CI, dependency manifest, and health-test hook give broadly consistent accounts of standalone/distributed deployment, authentication, and configuration. Stronger throughput, durable-execution, and reproducibility claims lack benchmarks or implementation evidence, so self-consistency scores 2. Tool pinning, caching, controller model failover, and several installation routes support dependency availability, but execution still depends on registries, external CLIs, cloud SDKs, and a large transitive graph; offline availability is not fully established, so it scores 2. CI emits specific errors and checks expected failures, while workflows expose retries, continue-on-failure, failure handlers, statuses, and logs. Core runtime error implementation and a user-facing error catalog are absent, so failure messages score 2.

3Adaptability16 / 18 · 4.4/5

The repository identifies its audience and supplies concrete ETL, operations, media, support, edge, container, and agent scenarios, earning 3 for audience and scenarios. It distinguishes standalone, distributed, headless, local-only build workflows, external tools, and licensed features, but does not fully delimit the security boundaries of arbitrary commands, MCP, or model-directed controllers, so capability boundaries score 2. Cron schedules, overlap policies, catch-up windows, dependencies, events, typed parameters, approvals, and explicit start commands make triggering precise, earning 3. Linux, macOS, Windows, Docker, Helm, Kubernetes, SSH, air-gapped environments, and distributed workers are all addressed, with Helm CI covering multiple configurations, so environment fit earns 3.

4Convention15 / 18 · 4.2/5

The README has a clear progression from positioning and architecture to deployment, parameters, and examples, with links to CLI, API, and focused documentation, so information architecture scores 3. Installation covers scripts, Homebrew, npm, Docker, Helm, the service wizard, and RWX storage requirements, earning 3. YAML and action names are mostly consistent and actions support versions, but examples mix id and name and third-party v1 references need not be immutable, so naming stability scores 2. Examples are extensive across common operations; despite no dedicated FAQ, examples and FAQ scores 3. Local-only build execution, environment-dependent capacity, unsupported older releases, and operator responsibilities are disclosed, but there is no systematic limitations or risk inventory, so known limitations scores 2. A full GPL-3.0 text and SPDX source header justify 3 for licensing. Chart CI requires version bumps, the security policy defines supported versions, and dependencies are versioned, but no actual changelog or repository-wide release policy is supplied, so versioning/changelog scores 2. A security email, response targets, disclosure process, and release workflow establish a maintenance path, but publisher identity remains unverified and governance or maintainer details are absent, so maintenance responsibility scores 2.

5Effectiveness12 / 13 · 4.6/5

The Web UI, per-step logs, history, statuses, structured outputs, and artifact flow make results directly inspectable and reusable, earning 3 for output usability. Adding dependencies, retries, approvals, scheduling, and observability around unchanged scripts provides clearly evidenced marginal value over cron, earning 3. A single binary and no required external database reduce deployment cost and multiple deployment options are documented; deductions apply because throughput and operating-cost claims are not execution-verified, distributed operation adds dependencies, and some RBAC/SSO capabilities are in a licensed tier, so cost-benefit scores 2.

6Verifiability5 / 8 · 3.1/5

Many claims are tied to concrete YAML, architecture descriptions, commands, or configuration names, but performance, security, durability, and reproducibility claims lack corresponding implementation or measurements, so claim traceability scores 2. The README is partially corroborated by Helm CI, SECURITY.md, go.mod, the health-test hook, and the license, but core execution code and the full test suite are not supplied, so cross-source corroboration scores 2. The material distinguishes conditions such as environment-dependent capacity, currently local build workflows, and a moving registry, but several marketing conclusions are not explicitly labeled as unverified, so fact/inference separation scores 2.

Evidence confidence: Low Reviewed Aug 14, 2026 Reviewed revision 585a6f008d2a
The upstream repository has new commits since this review. The score still applies to the reviewed revision shown and may not cover the latest changes.
Before you use it
  • The system can execute arbitrary local commands, SSH operations, containers, Kubernetes jobs, and MCP actions. Use low-privilege identities, network isolation, command allowlists, and mandatory approvals before enabling agent control or remote access.
  • README claims concerning secret masking, RBAC, SSO, auditing, and reproducibility are not verified by the supplied core implementation. Confirm community-edition defaults and which controls require the self-host license.
  • Installation examples pipe remote content directly into shells, while tool resolution may track the latest aqua registry. Production installations should pin revisions, verify signatures or hashes, and inspect scripts first.
  • Third-party actions, external agent CLIs, model providers, and automatically downloaded tools expand supply-chain and data-egress exposure. Pin each component and review its network destinations and credential scope.
  • No general transactional rollback mechanism is evidenced. Workflows that modify remote systems should include compensation steps, backups, idempotency, and rehearsed recovery procedures.
Review evidence [1][2][3][4][5][6][7][8]
See the full review method →

What does this agent do, and when should you use it?

Dagu is a local-first workflow engine for operations automation and AI-assisted work, aimed at teams that do not want orchestration to become a platform of its own. Declarative YAML DAGs can run shell scripts, Docker containers, Kubernetes Jobs, SSH commands, SQL, HTTP requests, sub-workflows, and external coding-agent CLIs. One binary bundles the Web UI, HTTP API, scheduler, executor, and MCP server, while run state, queues, logs, and history use local files instead of an external database or message broker. Workflows gain dependencies, schedules, retries, concurrency controls, human approvals, secret masking, notifications, artifacts, and Prometheus metrics. It runs on Linux, macOS, and Windows as a standalone process or scales through a gRPC coordinator and labeled worker fleet across on-premises, air-gapped, edge, or cloud environments. Buyers should account for licensed governance features and for the provider credentials or external CLIs required by model-controlled and coding-agent steps.

Dagu reads a YAML DAG containing parameters, steps, dependencies, schedules, retry policies, approvals, lifecycle handlers, and execution placement, then creates runs through dagu start or the scheduler. A step can execute an existing command through run: or invoke structured actions such as docker.run, kubernetes.run, ssh.run, http.request, database, S3, file, artifact, state, and dag.run operations. harness.run launches external coding-agent CLIs including Codex, Claude Code, Gemini CLI, Pi, and OpenCode; a type: controller workflow instead lets a configured model choose actions and uses tasks as completion criteria. Each run records status, history, per-step stdout and stderr, and arbitrary file artifacts that operators can inspect, retry, stop, or approve in the Web UI. The built-in /mcp endpoint exposes dagu_read, dagu_change, and dagu_execute so compatible clients can inspect state and Wiki pages, preview or apply edits, and start, enqueue, retry, or stop runs. In distributed mode, the scheduler writes to a file-backed queue, the coordinator dispatches over gRPC, and workers pull tasks by label before returning status and streamed logs.

  1. A data team with extraction scripts, SQL, dbt commands, and loaders can connect them into observable ETL pipelines with dependencies, retries, and durable run history.
  2. A platform team replacing intertwined cron and Bash jobs can add schedules, concurrency controls, logs, failure notifications, and approvals without rewriting the scripts into a framework.
  3. Operators managing private or air-gapped servers can run diagnostics, deployments, health checks, and restarts over SSH while retaining results in a self-hosted control plane.
  4. Media and infrastructure teams can execute FFmpeg jobs, Docker containers, or Kubernetes Jobs in parallel and add distributed workers when one host is insufficient.
  5. An internal-tools team can expose approved diagnostics or repair procedures to support staff through typed Web UI parameters, role controls, and human tasks.
  6. A team running scheduled code reviews or AI-assisted operations can call a coding agent with harness.run, save its report as an artifact, and require human approval before publishing or changing anything.

What are this agent's strengths and limitations?

Pros
  • A single cross-platform binary includes the UI, scheduler, and executor and stores state in files, avoiding PostgreSQL, Redis, a message broker, and a Python runtime for the basic standalone deployment.
  • Workflow structure stays in YAML, so existing scripts do not import a Dagu SDK and remain independently runnable if the YAML is removed.
  • The execution surface spans local commands, Docker, Kubernetes, SSH, HTTP, SQL, S3, sub-DAGs, human tasks, and several external coding-agent CLIs.
  • Web UI, CLI, HTTP API, built-in MCP, artifacts, per-step logs, and Prometheus metrics support both operator-driven and automated control.
  • The same engine can grow from one machine to label-routed coordinator/worker execution, with queues, resource limits, overlap policies, catch-up scheduling, and zombie detection.
Limitations
  • File-backed state and queues leave persistence, backups, shared storage, and host capacity planning to the operator; throughput depends on CPU, memory, disk, and workflow shape.
  • Incremental result reuse in build workflows currently runs locally and cannot directly use distributed workers.
  • SSO, RBAC, audit logging, and incident SaaS integration are licensed self-host additions, so the community deployment does not include every team-governance feature.
  • AI controllers require network access and credentials for the selected model provider, while harness.run requires the corresponding coding-agent CLI to be separately installed and authenticated.
  • Distributed operation adds coordinator, gRPC, worker routing, and peer-TLS configuration; the Helm deployment also requires a ReadWriteMany-capable StorageClass.
  • GPL-3.0 requires licensing review before embedding Dagu in another product, and the embedded Go API is explicitly experimental and may change.

How do you install or deploy this agent?

On macOS or Linux, run curl -fsSL https://raw.githubusercontent.com/dagucloud/dagu/main/scripts/installer.sh | bash. Alternatives are brew install dagu or, where npm is installed, npm install -g --ignore-scripts=false @dagucloud/dagu. On Windows PowerShell, run irm https://raw.githubusercontent.com/dagucloud/dagu/main/scripts/installer.ps1 | iex. A Docker deployment is docker run --rm -v ~/.dagu:/var/lib/dagu -p 8080:8080 ghcr.io/dagucloud/dagu:latest dagu start-all. For Helm, run helm repo add dagu https://dagucloud.github.io/dagu, helm repo update, and helm install dagu dagu/dagu --set persistence.storageClass=<your-rwx-storage-class>; the selected StorageClass must support ReadWriteMany. Script installers can configure PATH, a background service, and the initial administrator. A basic local CLI workflow needs no model credential, while controller or harness workflows require the selected provider or CLI to be installed and authenticated—for example, an Anthropic controller uses ANTHROPIC_API_KEY.

How do you use this agent?

Create hello.yaml with steps:\n - id: hello\n run: echo "hello from Dagu", then execute dagu start hello.yaml. To launch the Web UI and scheduling services, run dagu start-all --dags . and visit http://localhost:8080. The running HTTP server also exposes the Streamable HTTP MCP endpoint at http://localhost:8080/mcp for compatible chat and coding clients. Production YAML can add schedule, depends, retry_policy, approval, secrets, and handler_on; use dagu validate <dag> or dagu dry <dag> before execution. Operational commands include dagu status <dag>, dagu history <dag>, dagu retry --run-id=<run-id> <dag>, dagu stop <dag>, and dagu enqueue <dag>.

How does this agent compare with similar options?

Compared with cron, Dagu adds dependency graphs, retries, history, logs, approvals, and a Web UI. Compared with Airflow, it avoids operating a scheduler, metadata database, worker stack, and Python environment, and does not require rewriting jobs as @dag or @task framework code. Compared with Temporal, Dagu keeps order, dependencies, retries, and schedules in YAML while existing business scripts remain outside a dedicated SDK and programming model; its central abstraction is therefore orchestration around external work rather than moving application logic into a workflow SDK.

FAQ

Is a paid license required for basic self-hosting?
No license key is required for community self-hosting. SSO, RBAC, audit logging, and incident SaaS integration are additions provided by the self-host license.
Does Dagu require a cloud service or external database?
The base engine needs neither an external database nor a message broker; it can keep state, logs, and queues in local files and run in air-gapped environments. Individual steps that contact APIs, registries, Git services, MCP clients, or model providers may still require networking.
How can a team restrict who edits or runs workflows?
The builtin authentication mode defines admin, manager, developer, operator, and viewer roles, and API keys can receive independent roles. Availability of OIDC/SSO, RBAC, and auditing also depends on the licensing configuration.
What happens when a job fails or the scheduler is offline?
Per-step retries, exit-code filtering, failure handlers, and notifications are configurable. Overlap policies can skip, queue all, or retain only the latest run; a catch-up window handles missed schedules, and zombie detection identifies stalled runs.
Are AI workflows locked to one model provider?
No. Dagu documents MCP access for multiple clients, harness.run support for several coding-agent CLIs, and controller model arrays with failover. Each provider or CLI still has its own installation, credentials, and model-availability requirements.

Compare agents like this one

The same FARS review applied across the shortlist this agent qualifies for.

Related agents