想把 Vercel 搬回自己的 VPS？先算清 Dokploy 的运维账

Dokploy 能把 Git 部署、数据库、域名、证书、日志和多台服务器放进一个控制面板。对已经在用 Docker 的个人开发者和小团队，它确实能省掉一批重复配置。可它替代的是托管 PaaS 的操作界面，不是托管 PaaS 背后的值班、备份和基础设施责任。

迁移前要算的也不只是 VPS 月租。真正的成本包括控制面板升级、安全补丁、异地备份、恢复演练和故障响应。团队没有人愿意承担这些工作时，自托管通常不是省钱，只是把账单换成了工时。

Dokploy 省掉的是部署编排，不是服务器管理 #

官方 README 将 Dokploy 定位为自托管 PaaS，支持应用、MySQL、PostgreSQL、MongoDB、MariaDB、libSQL、Redis、Docker Compose、Traefik、监控、通知、备份和外部服务器。安装文档要求至少 2GB RAM、30GB 磁盘，并占用 80、443 和 3000 端口；安装过程会配置 Docker 与 Swarm。

它最适合已经接受容器作为交付单元的团队。应用可以从 Git 构建，也可以直接使用 Dockerfile 或 Compose；域名和 HTTPS 由 Traefik 接管；数据库与环境变量在同一面板维护。几个小项目共用一台或几台 VPS 时，这些能力能明显减少手写脚本和反向代理配置。

但要分清两种“多机器”：

• Multi Server 是从一个面板连接和管理外部服务器。
• Multi Node 是用 Docker Swarm 在多个节点上调度副本。

前者解决管理入口分散，后者引入集群状态、manager quorum、overlay network 和镜像分发。小团队通常先需要 Multi Server，不应因为界面上有副本数就直接进入多节点架构。

当前许可证已不是“找不到”，而是分区授权 #

旧资料中“默认分支没有 License”的结论已经失效。2026-07-29 的 canary 分支根目录存在 LICENSE.MD 和 LICENSE_PROPRIETARY.md。

LICENSE.MD 规定：/proprietary 目录之外的内容使用 Apache-2.0；/proprietary 下的内容使用 Dokploy Source Available License 1.0。当前仓库确实存在 proprietary 目录，涉及 audit logs、SSO、custom roles、license keys 和 whitelabeling 等功能。DSAL 文本允许在开发和测试中复制修改这些部分，但生产使用要求有效商业协议。

这意味着“Dokploy 是 Apache-2.0”只对非 proprietary 的 core 内容成立，不能覆盖整个仓库。GitHub API 当前显示 NOASSERTION，更可能是因为它无法把这套分区许可归成单一 SPDX 标识，而不是仓库没有许可证。

还要注意一处文档不一致：TERMS_AND_CONDITIONS.md 把 core 描述为可供个人和企业自行安装使用，同时禁止未经许可把 Dokploy 作为服务商业转售或再分发；文件中的 License 链接仍指向当前不存在的 LICENSE 路径。普通团队自建 core、启用 proprietary 功能、修改后分发和对外销售托管服务，是四种不同情形。准备做后两种业务，或不确定部署是否加载了 proprietary 代码时，应要求 Dokploy 给出书面说明，不能只看首页的“Open Source”标语。

控制面板扩大了便利，也扩大了攻击面 #

Dokploy 需要接触 Git Provider 凭据、SSH 私钥、数据库、环境变量、Docker/Swarm 和远程终端。它能统一管理这些资源，控制面板被攻破时的影响也会跨越多个应用和服务器。

当前最新 release 是 v0.29.13，发布于 2026-07-21。更新说明集中修复了 Git clone 和 Docker 命令注入、跨组织 IDOR、Git Provider 凭据与 SSH 私钥泄露、WebSocket 授权缺失等问题。不能仅凭一次安全修复清单断言项目不安全；更合理的结论是：这是高权限控制面板，补丁延迟的代价很高，版本升级必须进入日常运维。

官方安装文档要求首次配置后启用 HTTPS，并建议在域名验证通过后关闭 IP:3000 的直接访问。实际部署还应限制管理端来源、为 Git 与服务器使用最小权限凭据、启用双因素认证、保留审计记录，并把应用、构建和控制面板的网络边界分开。若团队做不到及时关注安全 release，继续使用有专职安全与运维团队的托管 PaaS 更合理。

“有备份按钮”离可恢复还差一整套东西 #

Dokploy 支持把数据库备份到外部存储，也支持 Docker named volume 的备份。官方 Compose 文档同时说明：自动 Volume Backups 适用于 named volume，不适用于 bind mount。把持久数据放在 ./files 一类宿主机目录时，不能默认它已经进入面板的备份范围。

应用数据之外，还要处理控制面板与集群状态。Docker 官方 Swarm 运维文档要求备份 manager 上的 /var/lib/docker/swarm，并妥善保存 auto-lock unlock key；恢复时还涉及 manager quorum 和 --force-new-cluster。环境变量、SSH 密钥、对象存储凭据、Traefik 自定义配置和 DNS 记录，也要有独立清单。

因此，备份至少要覆盖三层：

1. 数据库和应用 volume，写入与主机故障域不同的存储。
2. Dokploy 配置、必要凭据和 Swarm 状态。
3. 从一台全新服务器重建所需的 Dockerfile、Compose、域名与操作手册。

判断备份是否有效的唯一办法是恢复。新建一台空服务器，恢复数据库和一个有状态应用，再核对数据完整性、域名切换和恢复时间。没有做过演练，就只有备份文件，没有恢复能力。

与托管 PaaS 的差别是责任归属 #

从 Vercel、Netlify 或 Heroku 迁到 Dokploy，得到的是基础设施控制、固定服务器成本和标准容器工作流；失去的是托管平台代为承担的底层补丁、容量、故障恢复和部分全球网络能力。

一篇独立的 Dokploy 迁移记录给出了相同的现实取舍：作者用一台 VPS 承载多个 Docker-first 项目，获得固定成本、本地 SQLite 与内部网络，同时失去 edge、自动扩缩容和平台托管的 uptime。这是单个团队的经验，不是通用性能结论，却很适合用来校正“一键迁移”的宣传感受。

如果团队只有一两个简单服务，并且有人熟悉 docker compose、Caddy 或 Nginx，直接部署可能比再维护一个控制面板更轻。当应用数量增加，需要统一域名、数据库、通知和多台服务器时，Dokploy 才开始抵消自身的运维成本。需要强 SLA、多区域容灾、细粒度企业权限或 Kubernetes 生态时，则应按完整平台需求重新选型，不能把单节点 Swarm 当作这些能力的替代品。

用一次故障演练决定是否迁移 #

先在独立 VPS 固定一个 Dokploy 版本，部署一个普通 Web 应用和一个有真实数据的 PostgreSQL。完成 HTTPS 后关闭 3000 端口直连，配置异地备份和通知。随后主动执行四件事：恢复数据库、重启服务器、升级 Dokploy、让控制面板暂时不可用并从底层 Docker 检查服务。

试点期间记录首次部署时间、日常发布步骤、磁盘增长、备份恢复时间、升级中断、凭据范围和回退步骤。再估算每月维护工时与可接受停机时间。只有当这些数字优于现有托管方案，并且明确有人负责，迁移才有经济意义。

Dokploy 值得 Docker-first 的个人和小团队试用。它提供的是一个更有秩序的自托管入口，不是免运维的 Vercel。先把许可证分区、安全补丁和恢复演练做实，再决定是否把生产服务搬进去。

来源 #

• Dokploy 官方仓库与官方文档（功能、默认分支与部署方式，复核于 2026-07-29）。
• Dokploy：Installation（最低资源、端口、HTTPS 与关闭 IP 直连建议）。
• Dokploy：Docker Compose（Compose/Stack 与 named volume、bind mount 的备份边界）。
• Dokploy：LICENSE.MD、LICENSE_PROPRIETARY.md 与 TERMS_AND_CONDITIONS.md（core、proprietary 与商业服务边界，复核于 2026-07-29）。
• Dokploy：v0.29.13 release（安全与授权修复，发布于 2026-07-21）。
• Docker Docs：Administer and maintain a swarm（manager quorum、Swarm 状态备份与灾难恢复）。
• José Manuel Ortega：How we set up the infrastructure with Dokploy and why we left Vercel（独立迁移案例，作为场景对照，不作为普遍性能数据）。