如果你已经离开了托管式 PaaS，你的 VPS 已配置好，SSH 密钥已添加，终端光标正在安装行上闪烁。剩下的唯一问题是：你该运行 curl ... | bash 用于 Coolify，还是用于 Dokploy？
两款工具都只需一条命令即可安装。两者都为你提供 Git 推送部署、自动 SSL、Web UI，以及在 Docker 之上的反向代理。有意思的差异，是那些在生产环境中才会显现的：每款工具如何处理一个标准的 docker-compose.yml、部署期间会发生什么，以及每个项目如何应对那条在 2026 年重塑了这次对比的消息。这里有两条消息承载了大部分分量： 2026 年 1 月的 Coolify CVE 披露 和 Dokploy 许可证重组 就在同一个月。
本文将每款工具匹配到具体的使用场景，而非评出一个赢家。读完之后，希望你能知道哪一款契合你的工作流。
TL;DR
- Coolify 更为成熟，拥有更大的生态系统（约 55k 个 GitHub star，300+ 个一键服务模板），空闲时占用更重，全程采用 Apache 2.0，自托管端没有付费层级。
- Dokploy 更为年轻（约 34k 个 star），空闲时占用更轻，核心采用 Apache 2.0，外加一份单独的 Source Available License，用于限制未来的付费功能（SSO、RBAC、审计日志、白标）。
- Coolify 目前无法通过 Docker Compose 实现零停机部署；只能通过 Dockerfile、Nixpacks 或单镜像部署。Dokploy 将 Docker Swarm 作为一等模式提供；而 Coolify 的 Swarm 被标注为实验性。
- 2026 年 1 月的 Coolify CVE 已在 v4.0.0（April 27, 2026）中修复。请更新 Coolify，且不要将控制面板公开暴露到互联网。
当两款工具都不是正确答案时
对某些部署来说，Coolify 和 Dokploy 都不是合适的形态。这里简要介绍三个值得了解的替代方案：
- Kamal （来自 37signals）：适合只有一两个应用、希望完全没有 UI 的团队；只需从你的笔记本电脑
kamal deploy。比 Coolify 或 Dokploy 简单得多，当你不想要控制面板时是正确之选。 - Dokku：经典的 Git 推送、单服务器模式。更成熟，范围更小，非常稳定。是「单台 VPS 上的 Heroku」的鼻祖。
- 裸 VPS 上的 GitHub Actions + Docker Compose：尽可能精简的技术栈。没有编排 UI，但也没有编排开销。适合单个应用，其部署流程由
docker compose pull && docker compose up -d从 CI 触发。
如果你的形态是一台服务器上的一个应用，那么 Coolify 和 Dokploy 很可能都是大材小用；先试试上面的方案之一。如果你有多个应用、多个数据库，或者团队里有需要 UI 来操作的非技术成员，那么 Coolify 与 Dokploy 之间的抉择才是该做的那个抉择。想更全面地了解这一类别中的各种选项，请参阅我们的盘点 带 Web UI 的自托管云平台.
Coolify 与 Dokploy 一览
Coolify v4.0.0 稳定版 在 April 27, 2026 发布，此前经历了漫长的 beta 周期。截至 May 11, 2026，Dokploy 的版本为 v0.29.4 。两者都是开源的自托管 PaaS 项目，处于 Heroku/Render/Vercel 替代品的领域，都用 UI 封装 Docker、提供默认 HTTPS 的反向代理（Traefik）以及基于 Git 的部署。
| 功能 | Coolify | Dokploy |
|---|---|---|
| 最新稳定版 | v4.0.0 (April 27, 2026) | v0.29.4 (May 11, 2026) |
| 许可证 | Apache 2.0 | Apache 2.0 核心 + 付费功能采用 Source Available |
| 技术栈 | PHP / Laravel | TypeScript / Node.js |
| GitHub star 数 | ~55,000 | ~34,000 |
| 最低 RAM（官方） | 2 GB | 2 GB |
| 最低 CPU（官方） | 2个核心 | 未指明 |
| 空闲 RAM（社区报告） | 500 MB – 1.2 GB | 300 – 400 MB |
| Docker Compose 零停机 | 不支持（仅 Dockerfile/Nixpacks） | 标准的 Compose 处理 |
| 多服务器集群 | Docker Swarm（实验性） | Docker Swarm（原生） |
| ARM64 支持 | 支持（含 Raspberry Pi OS） | 文档中未宣传 |
| 构建系统 | Nixpacks、Dockerfile、Docker 镜像 | Nixpacks、Dockerfile、Docker 镜像、Heroku Buildpacks、Paketo、Railpack |
| 反向代理 | Traefik | Traefik |
| 自托管监控范围 | 内置指标 + 日志查看器 | 基础资源指标 + AI 日志/构建错误分析（v0.29.0+） |
我们的看法：如果你想要更低的空闲开销、原生的多服务器支持，以及无需特定平台调校的标准 Docker Compose 处理方式，就选 Dokploy。如果你想要更大的一键应用库、ARM64/Raspberry Pi 支持，或者纯粹的 Apache 2.0 而不必担心未来的付费层级，就选 Coolify。
资源占用与 VPS 选型
自托管 PaaS 可以为你省下 Heroku 的开销。但如果编排层在空闲时就吃掉了你 2 GB VPS 中的 1.5 GB，你就没剩下什么可用来部署了。所以在一台小型服务器上，第一个实际问题是：在你部署任何一个应用之前，每款工具会消耗你多少资源？
Coolify 的空闲 RAM 占用取决于启用了哪些监控，CPU 基线占用为 5–7%，并在指标抓取运行时出现峰值。Coolify 自家的文档采用了一个有代表性的生产工作负载：8 GB RAM、4 核、150 GB 存储，运行 3 个 Node.js 应用、4 个静态站点和几个数据库。如果你的技术栈与此类似，这是一个合理的选型参考。
相比之下，Dokploy 运行轻得多，没有部署任务时 CPU 占用远低于 2%。
A LogRocket 的生产环境实测文章 将两款工具并排运行后得出了方向一致的结论：在 Dokploy 应用上执行一次 docker stop && docker start 不会触发完整的重新构建，而在 Coolify 上执行相同操作则会。仅这一点就让稳态成本朝着有利于 Dokploy 的方向倾斜，尤其是在较小的 VPS 套餐上，重新构建的风暴会吞掉你的 CPU 预算。
关于选型，这是我推荐的 VPS 配置：
- Coolify，轻量工作负载： 2 vCPU / 4 GB RAM / 120 GB NVMe is the practical starting point for Coolify plus a couple of small apps.
- Coolify，生产参考工作负载： 4 vCPU / 8 GB RAM / 160 GB NVMe to match Coolify's own documented 3 Node.js + 4 static sites + databases example.
- Dokploy，轻量工作负载： 1 vCPU / 2 GB RAM / 60 GB NVMe is comfortable for a single small app.
- Dokploy，生产余量： 2 vCPU / 4 GB RAM / 120 GB NVMe gives you room for a small production stack.
专业提示：Coolify 的空闲 RAM 会随监控配置而变化。如果你内存吃紧，在配置更大的服务器之前，先调长指标抓取间隔（或者如果你已经在别处运行 Prometheus/Grafana，就完全禁用内置监控）。
部署的真实情况：Docker Compose、Dockerfile 与零停机
大多数团队带着一份现成的 docker-compose.yml 和一个预期来到这两款工具中的某一个：粘贴文件、点击部署、看着应用启动。每个平台如何处理标准 Compose，以及在下一次部署期间进行中的请求会怎样，正是实际差别显现之处。
Coolify 支持 Docker Compose、Dockerfile、Nixpacks（从项目文件自动检测）以及直接的 Docker 镜像部署。然而有一个需要明确指出的注意点：零停机部署（滚动更新、蓝/绿部署）在 Coolify 中只能通过 Dockerfile、Nixpacks 或单镜像部署实现，无法通过 Docker Compose 实现。一位 Coolify 维护者在 一场 GitHub 讨论 中确认：「对于基于 compose 的部署，所有容器会在启动新容器之前被停止，目前基于 compose 的部署没有滚动更新。」对 Compose 的滚动支持已列入 v5 的路线图；v4 不会得到它。维护者建议的变通办法是把一个 Compose 栈拆分成单独的 Coolify 服务，如果你的 Compose 文件表达了真实的服务间关系，这会是一次相当费事的迁移。
面向用户的后果出现在一个 关于 Coolify 的 Hacker News 讨论帖中，一位运维者直言不讳地说：「当你更新一个应用时，任何待处理的请求都会被直接杀掉。」对于今天的 Compose 部署来说，这是准确的。
Coolify 的 Compose 层还加入了项目所称的「魔法变量」。这意味着自动注入辅助镜像、网络重写和环境覆盖。其意图是更高效；副作用是，一份在你笔记本电脑上干净运行的 docker-compose.yml 有时需要调整才能在 Coolify 上干净运行。同一个 Hacker News 讨论帖 浮现出一个有代表性的案例：「在 docker-compose 中添加了 8 个变量，只有 7 个被识别。」如果你的 Compose 栈小而标准，你可能不会遇到这些问题。如果它庞大或不寻常，你就会遇到。
Dokploy 的姿态不同。LogRocket 的 上手实测文章 发现 Dokploy「几乎无需修改就能部署一份现成的 docker-compose.yml」，并紧贴 Docker 原生的基于标签的路由模型。同一篇文章指出，在 Dokploy 中容器的停止/启动不会触发完整的重新构建，而在 Coolify 上执行相同操作则会。这是关于运行时行为的方向性信号，而非来自 Dokploy 文档的正式「零停机保证」，但它与自托管用户在较小 VPS 实例上反馈的情况相符。
除了 Nixpacks 和 Dockerfile，Dokploy 还支持 Heroku Buildpacks、Paketo Buildpacks 和 Railpack。对于从 Heroku 迁移、使用 heroku.yml 或基于构建包的工作流的团队来说，这是阻力最小的路径。
本节要点：如果你现有的服务是一个真正的 Docker Compose 栈，Coolify 会要求你要么重构部署策略，要么接受每次推送时的短暂停机。Dokploy 则不会。
安全性：2026 年 1 月的 Coolify CVE 披露
我这样理解这个更宏观的故事：只要你保持更新且不把控制面板暴露到公网，Coolify 今天运行是安全的。这次披露并不会否定这个项目。它遵循了负责任的披露流程，补丁也已发布。它揭示的是，一个低权限的已认证用户可触及的攻击面比本应有的更宽。这对项目而言是一个设计教训，对运维者而言是一个运维教训：现在就收紧暴露模型。
专业提示：即便打了补丁，也要像对待 SSH 那样对待你的 Coolify 控制面板。把它绑定到私有网络、置于 VPN 之后，或在前面架设 Tailscale。不要仅仅因为安装脚本让这件事很容易，就把 8000 端口暴露到公网。
Dokploy 也不能免于这类问题。其 v0.29.3 版本说明 承认在 Dokploy 中发现了一个安全漏洞，并随附了一份安全补丁脚本，你需要在升级时一并运行。攻击面更小、项目历史更短，但同样的运维纪律仍然适用：补丁发布当天就更新，不要把控制面板留在公网上。
本节要点：CVE 这件事对 Coolify 的运维实践来说是一个黄牌，而非对项目本身的红牌，但它提高了对更新纪律以及如何暴露控制面板的要求。
许可证：什么是免费的，什么不是
Dokploy 的许可证已于 January 21, 2026 重组。下面是发生的变化以及它对自托管用户意味着什么。
Dokploy 现在的 核心采用标准 Apache 2.0，取代了此前那份让用户搞不清哪些是开源、哪些不是的非标准改编版 Apache 2.0。现在有一份单独的 Dokploy Source Available License 管辖位于 proprietary/ 目录中的代码：源码可见，但用于生产需付费。Dokploy 表示将置于该许可证之后的功能：
- 单点登录（SSO/SAML）和高级访问控制
- 自定义品牌和白标
- 高可用、自动扩展和灾难恢复
- 高级监控、集成和合规功能
该项目已明确承诺，绝不会把现有的开源功能挪进付费层级；未来的付费功能面向那些需要企业级粘合层的组织。如今的 2FA 已经位于 Dokploy 定价页面.
Coolify 的情况很简单明了。该项目是 GitHub 上的 Apache 2.0；自托管版本中的每一项功能都是免费的。还有一个 Coolify Cloud 产品 ，面向希望由维护者来托管的团队，但自托管版本本身就是一个完整的产品，没有功能门槛，也没有通往某个你今天还不具备的付费层级的升级路径。
我的解读：对于在自己 VPS 上自托管的个人开发者和小团队来说，Dokploy 在功能上是免费的，并且会一直如此。对于最终需要 SSO、细粒度 RBAC、审计日志或白标的组织来说，Dokploy 终究会把你推向某个付费层级。Coolify 不会，因为 Coolify 的路线图上根本没有那个层级。
一个值得做的跨来源澄清：Dokploy 的自托管版本确实包含基础资源指标（CPU、内存、存储、网络），且 v0.29.0 加入了 AI 驱动的日志和构建错误分析。对于更高级的监控功能，Dokploy 的监控系统仅在云端提供。不过，对于基础的容器前资源指标，监控在自托管安装上仍然在本地运行。
多服务器与集群：现实与营销
单台 VPS 迟早会不够用，而两个项目都在各自的落地页上大力宣传多服务器支持。落到实处的现实却并不相同。
Coolify 的 官方可扩展性文档 对此直言不讳：Docker Swarm 支持被标注为实验性。标准的多服务器模式使用经验证的、通过 SSH 连接的远程服务器，服务器之间共享一个 Docker Registry，并在每台服务器上运行 Traefik 实例。Swarm 模式要求在相同架构下（全部 ARM，或全部 AMD64）至少有三台服务器。Kubernetes 呢？「只是有规划，但还没列入路线图，所以没有预计时间。」如果你读了 Coolify 自家关于这一点的页面，简短版就是：多服务器可用，Swarm 是 beta，而 Kubernetes 是一个愿景。
Dokploy 将 Docker Swarm 作为一等模式提供，没有实验性标记。Traefik 在单服务器和 Swarm 配置中都负责路由。v0.29.0 版本加入了非 root 的多服务器支持，弥补了一个真实的缺口（不再需要仅 root 的 SSH 来添加远程节点）。
如果多节点集群是你未来六个月需要的东西，而不是「某天在幻灯片上」的东西，那么 Dokploy 是今天风险更低的选择。
本节要点：如果集群在你的近期路线图上，Swarm 的差异会让推荐倒向 Dokploy，无论其他维度如何。
构建系统与语言支持
从 Heroku 迁移过来的团队最在意的，是每款工具支持哪些构建包生态系统，因为这决定了你的项目在首次部署前需要重写多少。
Coolify 的构建路径是 Nixpacks（默认，从你的项目文件自动检测）、Dockerfile，或预构建的 Docker 镜像。Nixpacks 在常见场景（Node、Python、PHP、Go、Rust）下很可靠，但自动检测有些粗糙之处。值得为你的技术栈验证：2026 年 1 月一个影响同时具有两者的 Laravel 项目的 Nixpacks 问题 composer.json 以及 package.json 会产生重复的 Nginx location 块，使一类部署失效，直到上游修复。
Dokploy 支持 Nixpacks、Dockerfile 和 Docker 镜像，并在此之上加入了 Heroku Buildpacks、Paketo Buildpacks 和 Railpack。如果你的项目已经能用 heroku.yml 或某个构建包干净地构建，Dokploy 让你保留那个工作流。Coolify 则会要求你转换。
表面上两款工具看起来一样：来自 GitHub、GitLab、Bitbucket 的 Git 推送部署，自动 Let's Encrypt SSL，用于环境变量和数据库管理的 Web UI。构建系统的广度是 Dokploy 明显更进一步的少数几处之一。
一键应用目录
对于想要部署已知开源服务（n8n、Plausible、Supabase、Ghost、Listmonk 这些常见的自托管常客）的非技术运维者来说，一键模板库的规模是一个真实的差异化因素。对某些用户而言，这比性能或轻量等其他方面更重要。
Coolify 提供 300+ 个一键服务 ，横跨大约 40 个类别：AI、分析、自动化、数据库、安全、存储等。它是规模上遥遥领先的库，也是面向那些想要部署一个服务而又不必编写 Compose 文件的非开发者的实用答案。
Dokploy 的模板库更小。当前的 Dokploy 文档没有公布一个清晰的数字，所以我不打算给你一个数字。
实用答案：如果你的工作流是「各点两下就部署 n8n、Supabase 和 Plausible」，那么 Coolify 在这一维度上干净利落地胜出。如果你编写自己的应用，只想把它们部署上去，那么目录规模无关紧要，而其他维度才重要。
如何选择：按使用场景推荐
这里没有唯一的赢家。有的是工具与部署形态之间的匹配：
- 想要服务库的非技术团队： Coolify。300+ 个模板目录是一个实打实的优势。
- 想要轻量 + 标准 Compose 处理的 Docker 原生开发者： Dokploy。
- ARM64 硬件（Raspberry Pi、基于 ARM 的 VPS）： Coolify。Dokploy 在当前文档中并未宣传 ARM64 支持；如果你在 ARM 上，在确认之前默认选 Coolify。
- 这个季度就要用的多节点集群： Dokploy。原生 Swarm 对实验性 Swarm，是决定性的摆动因素。
- 纯 Apache 2.0，未来不可能有付费层级： Coolify。
- 从 Heroku 迁移并希望保留 Heroku Buildpacks： Dokploy。
- 担心 2026 年 1 月的 CVE： 一个已更新的 Coolify（v4.0.0+）就没问题。真正的问题在于你的暴露模型。如果你无法把控制面板绑定到私有网络或 VPN，那么 Dokploy 是压力更小的选择：攻击面更小，高危披露的历史也更短。
关于部署任一工具的说明
一旦选定，安装本身在任一项目上都只是一条命令，但有一个值得知道的捷径。Coolify 和 Dokploy 都以一键部署的形式提供在 我们的市场，预装了 Ubuntu 24.04 和 Docker，控制面板也已可访问。如果你想跳过手动设置，市场上针对这两者的相关条目 Coolify 以及 Dokploy 是最快的路径。如果你更愿意从一个干净的操作系统开始、自己运行官方安装程序，两个项目都发布了一行脚本；选择适合你配置流程的那个。
常见问题
在 2026 年许可证变更之后，Dokploy 仍然是开源的吗？
核心平台是的。自 January 21, 2026 起生效，Dokploy 的核心采用标准 Apache 2.0。现在有一份单独的 Dokploy Source Available License 管辖位于 proprietary/ 目录中的代码，目前范围限定于未来的企业级功能（SSO/SAML、细粒度 RBAC、审计日志、白标）。对于个人和小团队的自托管使用，Dokploy 在功能上是开源的。
2026 年 1 月的 Coolify 安全漏洞现在还需要担心吗？
11 个已披露的 CVE 已在 Coolify v4.0.0（于 April 27, 2026 发布）中修复。如果你运行的是 v4.0.0 或更新版本，已披露的漏洞都已得到解决。剩下的是暴露问题：保持 Coolify 更新，且不要把控制面板暴露到公网。把它绑定到私有网络，或置于 VPN 之后。
