Dagu review: should existing scripts move beyond cron?
Dagu puts workflow structure in YAML while the work stays in your commands and containers. That makes it relevant when cron jobs need dependencies, retries, run history or an operator interface. The decision is whether that separation fits your automation and whether you can operate the server and its state.
The repository README describes a self-hostable single binary with a built-in Web UI and no external database or message broker. It lists shell commands, Docker containers, Kubernetes Jobs and SSH execution, plus schedules, parallel sub-workflows and human tasks. These are documented capabilities, not features independently exercised by our recorded run.
The existing page identifies v2.16.4. Our measurements belong to commit 55b5c71fabe82de12afbbca949615ed6835cf44e on September 11, 2026. They do not establish the installed binary's version, and this review does not present v2.16.4 as the current latest release. Current documentation and the commit-specific README are separate evidence snapshots.
What our recorded run establishes
The recorded configuration was 3 CPUs, 8 GB of memory and image golang:1.24-bookworm. The image name does not establish the actual Go runtime: the install-step tail reports downloading go1.27.0 for linux/amd64.
| Recorded step | Observation | Limit |
|---|---|---|
| Install-labelled command | Exit 0 after 116 seconds; retained tail shows a Go toolchain download | No retained installed-Dagu CLI check |
| Build-labelled command | Exit 0 after 370 seconds; retained tail is vet-exit:0 | No independent confirmation of compilation or a runnable binary |
| Go test command | Exit 124 after the 900-second cap | The suite did not complete |
The dependency metric was 1,066. It is not a verified count of packages installed by the first command. The repository metrics were 3,237 files, approximately 745,443 source lines and 39.4 MB, with 12 detected CI workflow files. These describe the recorded checkout, not runtime resource needs or test quality.
The test parser recorded 36 successful package results and 2 failed package results, with a summary total of 38, plus 5 package results marked as having no test files. These are package-level parser observations. They are not individual test counts, an exhaustive package inventory or a pass rate: unique and exhaustive counts were not verified, and no complete-log reconciliation was performed.
The retained tail explicitly marks github.com/dagucloud/dagu/v2/internal/intg/embed as failed after 21.819 seconds. It also contains successful package results, including the file-backed wiki package at 120.078 seconds and service registry at 43.105 seconds. Those durations are package execution times, not workflow throughput benchmarks. The tail does not reveal the failing assertion or identify the cause of the second parser-recorded failed package. Nearby cancellation messages do not establish causation.
No new execution was performed for this correction. The record contains no audit result, standalone installed-binary check or measured production workload. It supports a limited command-level evaluation, not a clean installation or production-readiness claim.
What to evaluate beyond cron
The commit-specific README documents cron syntax, time zones, overlap policies, catch-up windows, retries, queues and concurrency controls. For an operations team, the useful distinction is that these rules sit beside existing scripts rather than being embedded in them. That can make the orchestration boundary easier to inspect, although migration effort depends on the scripts and environment.
The README describes single-server, temporary-worker and persistent distributed-worker deployments. These have different operating requirements. Temporary workers write state to a shared volume that the server reads; distributed workers poll a coordinator over gRPC and report status, logs and artifacts. The Helm example requests a StorageClass supporting ReadWriteMany. Avoiding an external database does not remove storage, backup or recovery work.
Treat the README's throughput and fleet-scaling statements as project claims. Our run did not measure scheduling capacity, failover, backup restoration or sustained concurrent execution. A useful pilot should include a restart during execution, overlapping schedules, a failed step and restoration of saved state, with outcomes checked against your requirements.
Access and licensing need an explicit check
The README says MCP clients can inspect workflows and runs, apply changes and control executions through the authenticated server boundary. It also warns that mounting the Docker socket gives workflows control of the host daemon. These are documented execution capabilities and deployment cautions, not security findings from our run.
Before a shared deployment, decide who may edit workflows, start runs and access execution credentials. Follow the project's authentication, network and worker-transport guidance for your topology. Our record contains no security audit establishing that a deployment is safe.
The recorded repository license signal is GPL-3.0. Separately, the README says community self-hosting requires no license key and lists SSO, RBAC, audit logging and incident SaaS integration under a self-host license. Its later access-control section describes capabilities without resolving every entitlement detail. Confirm the terms and available features for the exact version and deployment you intend to use.
When to consider Airflow or Temporal
Apache Airflow describes workflows authored as code and says it works best when their structure is mostly static and slowly changing. Consider it if that authoring model fits your team. Dagu's README comparison should not be treated as proof that every Airflow task requires rewriting the underlying business logic.
Temporal describes application Workflows executed resiliently, with automatic handling of intermittent failures and retries. Its README directs developers to supported languages to implement Workflows, Activities and Workers. Consider that model when durable application execution is the requirement. Our run provides no comparative reliability or performance result for either alternative.
How to read the scores
These are editorial assessments of the evidence available for evaluation, not benchmark results. The rubric is 1 for a documented blocking limitation, 2 for a relevant area with substantial unresolved evidence, 3 for a documented evaluation path with material verification gaps, 4 for strong documentation plus direct verification of the relevant behavior, and 5 for broad verification across representative conditions. An unknown does not prove poor product quality and cannot justify a high score.
Setup receives 2 because successful command exits do not establish a working installed binary. Documentation receives 3 because the supplied material explains setup and deployment choices, but we did not verify those paths end to end. Community receives 2 because the supplied evidence does not establish support responsiveness or sustained maintenance. Maturity receives 2 because documented operational features are not backed here by recovery or workload measurements, and the recorded suite remains incomplete.
For a first evaluation, choose one noncritical job with a dependency and a recoverable failure. Verify Dagu's binary and version, run the job, inspect its logs, and check restart and retry behavior before expanding its responsibilities.