Dagu 评测：单二进制 YAML 工作流引擎，能否替代 cron 与 Airflow？
Self-hostable workflow orchestrator for teams whose main work isn't orchestration. Declarative YAML over your scripts, SSH commands, containers, etc; keep workflows separate from business logic. One binary, no database, runs on limited H/W resources. Alternative to Airflow / Cron / Job Scheduler.
秒懂
- 它是什么？
- Dagu 是一个本地优先的工作流引擎，用声明式 YAML 编排脚本、SSH 命令和容器。它单二进制、无数据库，适合不想维护重型平台的团队，但 GPL-3.0 许可证和文件存储方式需要仔细评估。
- 适合谁用？
- Dagu 适合那些已经有可运行的脚本、容器或 SSH 命令，只需要调度、依赖、重试和日志的团队，尤其是运维、边缘计算和数据工程场景。如果你的工作流逻辑复杂到需要编程语言动态控制，或者团队强制要求集中式数据库存储状态，Dagu 的 YAML 加文件存储模型会很快成为瓶颈。
- 能商用吗？
- 可以，但有条件。GPL-3.0 是 copyleft 许可证：如果你分发包含它的软件，就必须以同一许可证公开该软件的源代码。只在内部运行、不对外分发，则不会触发这项义务。
- 还在维护吗？
- 在维护。仓库在最近一天内有新的提交。
- 用什么语言写的？
- 主要是 Go（依据 GitHub 的语言统计）。
以上回答依据项目的 GitHub 数据（最近同步于 2026年9月15日）和我们的分析，不构成法律意见。
开源项目深度解析
编排不是你的主业，但 cron 又不够用
Dagu 的定位非常明确：它写给那些把编排当副业的团队。你已经有能跑的脚本、容器或者 SSH 命令，缺的只是调度、依赖、重试和日志。cron 能定时执行，但给不了你依赖图、失败重试和运行历史。Airflow 能编排，但你需要维护 scheduler、metadata database、worker 和一套 Python 环境，而且业务逻辑会被迫改写成 @dag 和 @task 装饰器。Dagu 的做法是把工作流结构写成 YAML 配置文件，放在脚本旁边，引擎本身是单一进程。你删除 YAML 文件，脚本照常运行，没有任何代码级别的侵入。这种设计适合那些不想让编排器长在业务代码里的团队，比如运维自动化、媒体转码或者边缘设备上的定时任务。
YAML 定义 DAG：从脚本到生产工作流的路径
Dagu 的核心机制是声明式 YAML。你在文件里定义 DAG 的节点、依赖关系和重试策略，引擎负责执行。根据 README，它原生支持 shell 命令、Docker 容器、Kubernetes Jobs 和 SSH 远程命令，这些都被称为 Dagu Actions。工作流结构是配置，不是代码，所以脚本不需要导入任何 Dagu 库。一个典型的做法是：把现有 runbook 里的命令抽成步骤，在 YAML 中声明它们的执行顺序和并行度。Dagu 会为每次运行生成依赖图、逐步日志和完整历史。这种模型的关键优势在于，编排逻辑和业务逻辑物理分离，你可以单独修改调度策略而不触碰脚本。但代价是，复杂的条件分支和循环逻辑很难在静态 YAML 中表达，你最终可能还是得把控制流写进脚本，让 Dagu 只负责调用。
单二进制部署：从安装到启动的实际命令
安装 Dagu 的方式很多，最直接的是用安装脚本。在 macOS 或 Linux 上执行 curl -fsSL https://raw.githubusercontent.com/dagucloud/dagu/main/scripts/installer.sh | bash 即可。也可以用 Homebrew 执行 brew install dagu，或者通过 npm 全局安装 @dagucloud/dagu。Windows 用户用 PowerShell 执行 irm https://raw.githubusercontent.com/dagucloud/dagu/main/scripts/installer.ps1 | iex。启动服务用 docker run --rm -v ~/.dagu:/var/lib/dagu -p 8080:8080 ghcr.io/dagucloud/dagu:latest dagu start-all，这个命令会挂载本地目录作为数据存储。注意 README 特别提醒，该命令不会暴露宿主机的 Docker daemon，所以容器内的步骤无法直接调用宿主机的 Docker。这暗示如果你要用 Dagu 编排容器，需要额外配置 Docker socket 或使用 Kubernetes 集成。核心思想是：一个命令启动全部，包括 Web UI 和调度器，没有独立数据库或消息队列需要配置。
文件存储的状态模型：简单但有限制
Dagu 不依赖外部数据库，状态存储在本地文件中。README 声称单机可以达到每天数千次工作流运行，但这取决于 CPU、内存、磁盘和工作流形状。文件存储意味着状态持久化非常直接，备份就是复制目录，但也意味着并发规模受限于单机文件系统的能力。如果你有多个 worker 节点，Dagu 支持通过队列和并发限制来控制执行分布，但跨机器的状态同步机制在 README 中没有详细说明。对于边缘或 IoT 场景，这种设计是优势，因为你不需要在设备上运行数据库。但在高吞吐、多租户的生产环境中，文件存储的扩展性和隔离性会成为问题。你需要自己处理日志轮转和磁盘清理，因为每次运行都会产生历史文件。
Web UI 与 MCP 服务器：可观测性和自动化接口
Dagu 内置 Web UI，展示运行队列、进行中、完成和失败的工作流。README 中的截图显示运行详情、步骤日志和 Wiki 页面。Wiki 功能看起来像是为团队维护操作文档设计的，可能和工作流定义放在一起。更值得注意的是内置的 MCP 服务器，它允许外部工具检查工作流和运行状态、维护 Wiki 页面、应用更改以及控制运行。MCP 是 Model Context Protocol 的缩写，这意味着你可以通过支持 MCP 的客户端（比如 AI 助手）来操作 Dagu。这为 AI 代理触发运维任务提供了通道。但这种集成也带来安全考量：MCP 服务器暴露的控制能力如果权限控制不当，可能让 AI 误操作生产工作流。README 没有提供 MCP 的认证细节，这是采用前需要查证的点。
与 cron、Airflow、Temporal 的实质差异
Dagu 的对比对象很明确。cron 没有依赖管理、重试或历史，Dagu 补齐了这些。Airflow 是重量级平台，需要独立基础设施，而且强制你用 Python 重写任务，Dagu 则允许你保留现有任何语言的脚本。Temporal 提供持久化执行，但要求业务逻辑进入它的 SDK 和编程模型，Dagu 把编排放在 YAML 中，而不是代码里。关键区别在于：Dagu 把工作流视为配置，Airflow 和 Temporal 视为程序。对于已有大量脚本的团队，Dagu 的迁移成本低，因为你不需要改脚本本身。但如果你需要复杂的状态机、 saga 模式或者动态任务生成，Temporal 的编程模型更合适。Dagu 适合那些工作流相对固定、变化主要发生在调度参数和依赖顺序上的场景。
许可证与维护成本：GPL-3.0 的含义
Dagu 采用 GPL-3.0 许可证。这意味着如果你修改了 Dagu 的源代码并分发，你必须以相同许可证开源你的修改。如果你只是作为独立服务运行 Dagu，不修改或分发，通常不需要开源你的工作流定义。但如果你计划将 Dagu 嵌入到商业产品中，或者通过 SaaS 方式提供给第三方，你需要咨询法律意见。维护成本方面，Dagu 是 Go 写的单二进制，升级就是替换文件，没有依赖地狱。但状态文件格式的兼容性需要关注，如果未来版本改变存储结构，你可能需要迁移。项目活跃度尚可，最近有频繁的版本发布，包括 v2.16.3 和 Helm chart 更新。社区支持通过 Discord 和文档站点，没有看到企业支持选项。
编辑结论
Dagu 适合那些已经有可运行的脚本、容器或 SSH 命令，只需要调度、依赖、重试和日志的团队，尤其是运维、边缘计算和数据工程场景。如果你的工作流逻辑复杂到需要编程语言动态控制，或者团队强制要求集中式数据库存储状态，Dagu 的 YAML 加文件存储模型会很快成为瓶颈。不适合需要细粒度分布式事务或跨团队共享工作流代码库的组织。在采用前，务必验证三件事：第一，检查你的工作流是否真的能用静态 YAML 表达，比如循环和条件分支是否依赖外部脚本；第二，确认 GPL-3.0 许可证与你的分发方式兼容，尤其是如果你计划将 Dagu 嵌入商业产品；第三，测试单机文件存储在高并发运行下的表现，特别是日志和状态文件是否会造成磁盘 I/O 瓶颈。Dagu 的价值在于把编排从代码中剥离，但这也意味着它永远无法替代一个真正的编程框架。
社区笔记