每次推送都是同一套流程：SSH 登录、拉取仓库、重新拉起 Compose 堆栈、祈祷没出问题，然后努力回想自己到底跑没跑迁移。这种手动循环一直够用，直到你需要可重复的部署、需要清楚记录当前运行的内容，或者需要从状态漂移中恢复。
Doco CD 就是一个直截了当的答案。它是一个用 Go 写的小型服务，会监视你的 Git 仓库，并在你推送时应用 Compose 的变更：用 webhook 还是轮询，由你决定。ArgoCD 和 Flux 在 Kubernetes 上做同样的事，但 Doco CD 绕开了 Kubernetes，因为它根本不需要控制平面。
本文评测 Doco CD 能做什么、不能做什么，以及它与 Komodo、Portainer 的 GitOps 模式、Dokploy 和一段简单的 GitHub Actions + SSH 脚本相比表现如何。读完你就能判断它是否适合你的环境，以及不适合时该选什么。
TL;DR（太长不看版）
- Doco CD 是一个极小的、原生面向 Compose 的 GitOps 代理：它监视 Git 仓库（GitHub、GitLab、Gitea、Forgejo 等），一旦有变更就把你的堆栈调整到目标状态。
- 内置的外部密钥提供方支持，加上基于 SOPS 的加密，正是它相较自己写部署脚本的差异所在。
- 按照它自己的 README，它把自己定位为「Docker 上一个简单的 Portainer 或 ArgoCD 替代品」。这个说法大致准确。
- 真正的局限：只有一位代码所有者、仍是 1.0 之前的版本号、没有机群管理界面，以及只有在下一次轮询或 webhook 事件之后才会重建的调谐状态。
- 如果你只运行一台或几台 Compose 主机，并希望在没有界面的情况下把 Git 当作唯一事实来源，那就选它。机群规模选 Komodo，想要界面选 Portainer，想要 PaaS 体验选 Dokploy，真的只有一台主机上的一个服务时就用 GitHub Actions + SSH。
Doco CD 想要填补的空白
对 2026 年还在跑 Docker Compose 的人来说，存在一个尴尬的中间地带。Argo CD、Flux 这类主流 GitOps 工具面向的是 Kubernetes，而 Watchtower 轮询镜像仓库的模式只是对镜像变化做出反应，并不会应用带版本的 Compose 状态。Watchtower 的 仓库 已于 2025 年 12 月 17 日归档，现在明确说明该项目不再维护。
GitHub Actions 加一个 SSH 部署步骤是可行的。一台主机上跑一个服务时，这就是正确选择。麻烦出现在你加了第二台主机、第二个堆栈，或者想知道当前部署的是哪个提交的时候。你仍然有工作流日志，但没有 Compose 原生的调谐、没有漂移恢复，也没有一个持续可查的视图告诉你主机是否仍与仓库一致。
Doco CD 的自我定位， 直接引自 README就是「Docker 上一个简单的 Portainer 或 ArgoCD 替代品」。这个说法正是关键所在：小巧、原生面向 Compose、不需要 Kubernetes、没有界面要维护、没有中央控制平面要照看。如果你没跑 K8s、也不想跑，这就是你一直在找的那一类工具。
Doco CD 实际是怎么运作的
Doco CD 就是一个跑在 Docker 容器里的 Go 单体二进制文件，它监视 Git 仓库，并在仓库状态变化时应用 Compose 的变更。整个概念就这么简单。有意思的地方在于默认值和各种集成。
触发方式。 有两种模式：webhook 或轮询。webhook 几乎是实时的，但需要对外暴露端口，更实际的做法是在 Doco CD 前面放一个反向代理。轮询则是周期性拉取：略有延迟，但不需要任何入站端口。轮询是更简单的默认方式，而根据 官方文档 ，两者都是一等公民。请根据你的主机是否有可访问的公网入口，以及你需要多快完成部署来决定。
按仓库配置。 一个 .doco-cd.yaml 文件（或 .doco-cd.yml）放在仓库根目录，和你的 Compose 文件并列。唯一必填的字段是部署名称。最小配置长这样：
# .doco-cd.yaml
name: my-stack
# Everything below is optional. These are the defaults.
timeout: 180 # seconds
remove_orphans: true
prune_images: true
force_recreate: false这些就是文档里写明的默认值：180 秒超时、删除孤儿容器、清理镜像，且不强制重建。
自动发现。 开启自动发现后，Doco CD 会扫描子目录寻找 Compose 文件，因此一个仓库可以容纳多个堆栈。它还支持在同一个配置文件里写多份部署配置，以三个短横线分隔的 YAML 文档形式呈现。清理相关的默认值比较保守，在依赖它们之前值得先读一遍：
| 设置 | 默认 | 含义 |
|---|---|---|
delete | false | 当某个应用从工作目录中消失时，过时的部署会被原样保留。 |
remove_volumes | false | 自动发现的堆栈被删除时，数据卷会保留下来。 |
remove_images | true | 自动发现的堆栈被删除时，未使用的镜像会被清除。 |
换句话说，在你自己打开删除开关之前，不会有任何东西在你背后被拆掉；就算打开了，数据卷也是最后才被动的。
支持的 Git 平台。 支持 GitHub、GitLab、Gitea、Forgejo、Gogs 和 Azure DevOps。webhook 方面的例外是 Azure DevOps，因为它不支持 Azure Service Hooks。如果你自建代码托管平台，对 Gitea 和 Forgejo 的支持就很重要。
Docker Swarm。 支持作为部署目标。 部署设置页面 部署设置页面明确指出：在 Swarm 模式下，调谐不会检查容器重启或健康状态，而且 Swarm 中不支持镜像清理。如果你的目标是 Swarm，你能得到部署，但得不到完整的健康调谐。
状态调谐。 默认限制是 300 秒窗口内最多重启 5 次，用来防止抖动的健康检查无限循环。同一仓库、不同引用时按顺序执行；同一仓库、同一引用时并行执行。最后这点很微妙但有用：同一引用的多次部署不会互相排队。
内置的外部密钥提供方。 这是选择 Doco CD 而非普通部署脚本的更有力理由之一：它支持 AWS Secrets Manager、Bitwarden Secrets Manager、Bitwarden Vault / Vaultwarden、1Password、1Password Connect、Infisical、OpenBao 和 Webhook。此外，它还支持用 SOPS 加密敏感的部署数据。这让你有了一条干净的路子，可以摆脱把明文 env 文件放进 Git 的做法，而不必自己搭建整套密钥解析流程。
其余部分。 Doco CD 提供 Prometheus 指标、任务调度、通知、distroless 容器镜像，以及 Apache-2.0 许可。根据它的 发布历史，截至 2026 年 8 月 20 日，最新的稳定版是 v0.109.2，最新的预发布版是 v0.110.0-rc.1。
Doco CD 的职责止于「应用清单」，再往后就是普通的 Docker 了。 Compose 自带的日志命令 就是你查看运行状况的方式。
关于密钥的实用建议。如果你的私有仓库里还留着明文 env 文件，优先启用 Doco CD 的外部密钥提供方或它对 SOPS 的支持。目标很简单：把明文密钥挪出 Git，同时仍然让部署在运行时取到这些值。
在拥有 root 权限、NVMe 与 AMD EPYC 强大性能的 Linux VPS 上构建应用。
查看 Linux 套餐Doco CD 的短板在哪里
任何工具都有局限，而 Doco CD 的局限值得你在搭进去一个周末之前先弄清楚。
只有一位代码所有者。 仓库的 CODEOWNERS 文件 把所有路径都指派给了 kimdre。发布节奏依然频繁，但项目治理集中在一个人身上。
尚未到 1.0。 Doco CD 仍在使用 0.x 版本号，所以请锁定一个测试过的版本，并在上线前读一遍升级说明。已关闭的 GitHub issue #851 很好地说明了原因：Docker v29 迫使该项目放弃已弃用的 Docker Go 模块。
Doco CD 容器内没有 shell。 出于安全考虑，Doco CD 不提供 shell 环境，也不会在宿主机上执行任意脚本。部署前后的任务必须走 init 容器、边车容器或 Compose 生命周期钩子，相比那些直接执行部署脚本的工具，这意味着更多的配置工作。
重启会丢失状态。 调谐状态保存在内存里。Doco CD 重启后，这份状态要等到下一次轮询或 webhook 事件才会重建，所以空档有多长，取决于你的轮询间隔或下一个 webhook 何时到达。
没有机群管理界面。 多主机部署不再需要每台机器都装一个代理。自 v0.102.0 起，部署配置可以指向 远程 Docker 上下文，包括 SSH 上下文，而且同一个仓库可以定义多个部署目标。每台主机跑一个 Doco CD 实例的做法依然成立，但现在一个中心实例就能部署到远程 Docker 主机。Doco CD 仍然欠缺的，是 Komodo 那样的机群管理界面和集中式主机清单。
内存和 CPU 占用没有给出具体数字。 官方文档把资源需求形容为「极小」，却没有给出任何基准数字。请按将要运行的应用来选 VPS 规格，留出运维余量，并在你自己的环境里验证 Doco CD 的实际占用。
关于多主机的实用建议。为每台主机使用单独的 Docker 上下文和部署目标，收紧 SSH 访问权限，并让 webhook 或 API 密钥各不相同。如果你更喜欢彼此隔离的代理，每台主机跑一个 Doco CD 实例依然成立。
Doco CD 与其他方案对比
我会列入候选的另外四款工具，解决的都是「从 Git 自动部署 Compose」这件事，但取舍差别很大。要决定的不是做不做，这你已经定了；要决定的是哪种形态的工具适合你的环境。下面是逐项对比。
| 工具 | 触发方式 | 多主机模式 | 密钥管理 | 网页界面 | 许可 |
|---|---|---|---|---|---|
| Doco CD | webhook 或轮询 | 远程 Docker 上下文，无机群界面 | 外部提供方加 SOPS | 没有 | Apache-2.0 |
| Komodo | webhook 加定时同步 | 中央 Core 加 Periphery 代理 | 变量与密钥管理 | 是 | GPL-3.0 |
| Portainer（CE/BE） | webhook 或轮询 | Portainer 代理 | 有限，BE 版选项更多 | 是 | Zlib，BE 版为商业条款 |
| Dokploy | 由推送触发 | 多服务器或 Docker Swarm | 内置环境管理 | 是 | Apache-2.0，含专有组件 |
| GitHub Actions + SSH | 由推送触发 | 取决于你怎么写脚本 | 取决于你怎么写脚本 | 没有 | 不适用 |
逐个简单说说，因为表格给的是形态，评论给的才是原因：
Komodo。 多主机场景下的正经替代方案。一个中央 Core 服务，加上每台主机上的 Periphery 代理，一个界面看到全部，除了部署还有由 Git 驱动的构建，并支持 Docker Swarm。搭建更重，因为你要跑一个数据库和一个控制平面，但如果你有一整片机器，这才是对的形态。当集中式机群管控真正重要时，Komodo 更合适。
启用 GitOps 的 Portainer（CE 或 BE）。 在 Git 同步之上提供完整的图形界面。当团队既要点点鼠标管理容器、又要持续交付时，这是正确的选择。反正总会有人进界面看日志、重启容器，那不如让 CD 也待在同一个地方。资源占用比 Doco CD 更重。OIDC/SSO 和细粒度 RBAC 被锁在付费的 Business Edition 里。关于更广阔的 Docker 管理生态，可以看我们的 Portainer 替代方案指南 ，其中覆盖了更广的 Docker 管理版图。
Dokploy。 PaaS 风格。它有明确主张，推送即自动部署，什么都有网页界面，开箱就帮你配好 Traefik 和干净的 URL 方案。更适合想要 Heroku 那种感觉、并愿意为此让出 Compose 原始灵活度的团队。如果你对 YAML 过敏，这是通往「git push，应用就上线」的最轻路径。
GitHub Actions + SSH。 零额外基础设施。部署任务就住在你本来就有的工作流里。你能拿到工作流日志，但拿不到 Compose 原生的调谐、漂移恢复，也拿不到持续可查的主机状态视图，除非这些东西你自己造。一台主机上跑一个服务时完全够用。一旦加了第二个目标，或者你想不登录 SSH 就知道什么跑在哪儿，它就撑不住了。对需求最简单的那部分读者来说，GitHub Actions + SSH 依然是正确答案。
还有一个更新的选手叫 stackd ，它用相似的说法给自己定位：「没有 Kubernetes 税的 GitOps」。值得知道这个品类还很活跃，但今天还不值得靠抛硬币把它选在 Doco CD 前面。
什么时候该选 Doco CD（什么时候不该）
在以下情况选择 Doco CD：
- 你运行着一台或几台 Docker Compose 主机，并希望把 Git 当作唯一事实来源。
- 比起在界面上点来点去，你更愿意在编辑器里改 YAML。
- 你想要外部密钥提供方支持和基于 SOPS 的加密，但不想自己造整套流程。
- 你能接受一个只有一位维护者、尚未到 1.0、但开发活跃的项目。
Komodo。 当你管理大量主机、需要集中式机群管控，或者需要在同一处同时拥有由 Git 驱动的构建而不只是部署时，就选它。
Portainer（CE 或 BE）。 当团队在持续交付之外还想要一个日常操作容器的界面时就选它，也就是当可视化这一层才是你考虑这个工具的真正原因时。
Dokploy。 当你想要 PaaS 式的部署体验，又不需要对 Compose 的原始控制权时就选它。
GitHub Actions + SSH。 当只有一台主机上的一个服务，而你并不需要状态调谐或漂移恢复时，就继续用它。
对于卡在「Watchtower 之后、Kubernetes 之前」这段中间地带的人来说，Doco CD 是一个有分量的轻量选择。我的判断是：新搭的家庭实验室或小型 SaaS，只要 Git 优先、无界面的运作方式还合用，我会从 Doco CD 起步；等到集中式清单、权限和机群可见性成为硬需求，再转向 Komodo。
无论你选哪款工具，都请把它跑在一台按将要承载的 Compose 负载来选型的 Linux VPS 上。 Cloudzy 的 Linux VPS 就是个合适的落脚点，默认带 root 权限。如果你想跳过折腾 apt 的环节，也可以 一键部署 Docker ，就在我们的应用市场里。
我们的应用市场也提供一键镜像，比如 Gitea，Doco CD 原生就能与它集成。此外还有 Komodo ，以及 Portainer，万一你觉得其中某一个才是你想要的形态。
常见问题
Doco CD 可以上生产环境了吗？
如果 Doco CD 的风险状况与你的业务相称，它是可以上生产的。项目开发活跃，但仍是 1.0 之前的版本号，且 CODEOWNERS 文件把整个项目指派给了一个人。请锁定一个测试过的版本，升级前先做测试，若是关键基础设施则应考虑更宽的治理安排。
如何用 Doco CD 管理多台主机？
为每台主机使用单独的 Docker 上下文和部署目标。一个 Doco CD 实例就能通过 SSH 或 TCP 部署到多台远程 Docker 主机；每台主机一个实例仍是可选的隔离模式。如果你需要集中式清单、权限和机群可见性，那就选 Komodo。
webhook 模式和轮询模式有什么区别？
webhook 模式在 Git 收到推送时几乎立刻部署，但需要一个可从公网访问的端口，或者在 Doco CD 前面放一个反向代理。轮询模式按计划检查仓库，部署会稍慢一点，但不用暴露任何端口。轮询是更简单的默认方式；如果你推送频繁或需要快速反馈，webhook 才值得折腾。
Doco CD 和 Komodo 相比如何？
Doco CD 更轻、没有界面，并且能通过远程 Docker 上下文管理多台主机。Komodo 则采用中央 Core 服务加 Periphery 代理，另外提供机群界面和由 Git 驱动的构建。想要无界面的 Compose 部署就选 Doco CD；当集中式机群管控更重要时就选 Komodo。
Doco CD 能取代 Watchtower 吗？
如果说的是大多数 Watchtower 用户真正想要的场景，也就是「Git 一变就把 Git 里的东西部署上去」，那答案是能，这正是 Doco CD 在做的事。但如果说的是 Watchtower 字面上的模式，也就是轮询镜像仓库、发现新标签就拉取，那答案是不能；Doco CD 由 Git 触发，而不是由镜像仓库触发。对任何超出玩具级别的服务来说，由 Git 触发的模式更安全，也更容易审计。
