【PaaS自托管 01】2026 避坑实测：Dokploy 轻量自托管部署平台，小内存 VPS 也能跑

延伸阅读

更多相关攻略推荐：【IP 地址 02】喊了二十年“狼来了”，为什么 IPv6 依然无法、【知识库自托管 02】2026 实测：VPS 自托管 Anythin、【知识库自托管 03】2026 实测：搬瓦工/RackNerd 上自、TikTok 直播推流中继实战：用 Nginx-RTMP/SRS 自、2026 TikTok Shop 多店防关联架构实测：IP 隔离 +。

为什么 2026 年要重新看 Dokploy

如果你这两年一直在折腾自托管 PaaS，大概率是从 Coolify 入门的。Coolify 确实好用，面板漂亮、一键服务多，但有个绕不开的痛点：它太吃资源了。社区实测在 2G 内存的小机器上，Coolify 空转就要吃掉 1.2G 左右内存，留给真正应用的空间所剩无几，部署一个 Postgres 加一个 worker 就快撑爆了。对只想用一台十几美元的廉价 VPS 管几个个人项目的人来说，这明显不划算。

而 Dokploy 走的是另一条路：用尽可能少的资源把多服务应用跑起来。它 2026 年已经冲到 26k+ stars，是增长最快的自托管 PaaS 之一。最关键的是，它原生支持 Docker Compose——你手上那坨现有的 compose 文件，基本可以直接贴进去就用。这篇就带你避开我踩过的坑，从选机器到跑起一个真实的多服务栈。

Dokploy 到底是什么，和 Coolify 差在哪

一句话：Dokploy 是一个免费、可自托管的 PaaS，底层基于 Docker 和 Traefik，把 Heroku / Vercel 那套「推送代码就部署、自动 HTTPS、可回滚」的体验搬到你自己的 VPS 上。它和 Coolify 的核心差异，我总结成四个点：

• 原生 Docker Compose：Coolify 对 Compose 的支持是「另起一套抽象」，而且 Compose 部署做不到零停机滚动更新；Dokploy 直接吃标准 compose 文件，网络、依赖关系原样保留。
• 空闲内存极低：社区一致实测空闲约 300–800MB，远低于 Coolify 的 1.2G，在小内存机器上优势巨大。
• Docker Swarm 多机：从第一天起就原生支持 Swarm，可以把应用横向扩到多台节点；Coolify 的多机能力是 v4 才补上的。
• 数据库自动备份：内置把数据库定时备份到外部存储的能力，CLI/API 优先，逻辑直白。

当然代价是：Dokploy 更年轻，面板更朴素，模板库大约 80–100 个、比 Coolify 的 280+ 少不少。但说实话，会用 Compose 的人根本不在乎模板数量——我们自己带文件就好。

硬件怎么选：小内存 VPS 资源规划

这是本文最实用的一节。Dokploy 官方标注最低 2G 内存、推荐 Ubuntu 22.04/24.04，但实测空闲只占 350MB 上下，所以你的应用才是真正的内存消耗大头。我的规划建议：

• 尝鲜 / 单应用：1 vCPU / 2G 内存 / 40–60G SSD 就够，比如 RackNerd 的高内存年付机型，几十美元一年就能拿下。
• 生产小栈（web+db+worker）：2 vCPU / 4G 内存 / 80G 以上 SSD 最舒服，HostDare 的 NVMe 套餐和 LisaHost 的优化线路都很适合跑这种常驻服务。
• 预留量：Dokploy 自身约 350–500MB，Postgres 留 256–512MB，worker 看业务，web 留 256MB 起步。这些都要在机器总额度里先扣掉。

我的结论很直接：想低成本管多服务，优先选内存单价低、线路稳的商家。RackNerd 拼性价比、HostDare 拼 CN2 优化线路、LisaHost 拼亚洲延迟，按你的用户群挑就行。千万别为了「大而全」上 Coolify 把内存吃满，Dokploy 在 2G 机上反而更从容。

从零安装 Dokploy

安装就一行，官方脚本会帮你把 Docker、Traefik、数据库和面板全拉起来。在一台干净的 Ubuntu 上执行：

curl -sSL https://dokploy.com/install.sh | bash

跑完终端会打印一个面板地址和初始管理员账号密码，通常是 http://你的服务器IP:3000。第一次登录务必改密码、并到 Settings 里绑定一个域名——Dokploy 默认用 Traefik 自动申请 Let's Encrypt 证书，所以你最好提前把域名 A 记录指向这台机器。

• 坑一：很多教程没提醒你开防火墙。面板 3000 端口如果你不想暴露公网，记得用云厂商安全组或 ufw 限制来源 IP，否则等于把管理后台裸奔在互联网上。
• 坑二：服务器时间必须正确，否则 Traefik 签发证书会失败。装好先跑 timedatectl set-ntp on 校准时间。

部署一个完整 Compose 应用栈（web + db + worker）

现在上主菜。假设我们有一个典型的个人项目：一个 Node.js 的 web 服务、一个 Postgres 数据库、一个后台 worker 消费队列。本地已经有 docker-compose.yml，长这样：

version: "3.8"
services:
web:
build: ./web
ports: ["3000:3000"]
depends_on: [db]
db:
image: postgres:16
environment:
POSTGRES_PASSWORD: ${DB_PASS}
volumes: ["pgdata:/var/lib/postgresql/data"]
worker:
build: ./worker
depends_on: [db, web]
volumes:
pgdata:

在 Dokploy 里部署它的步骤：

• 新建一个 Application，类型选 Docker Compose，填入你的 Git 仓库地址和分支。
• 在 Compose 配置里粘贴上面的文件，或者让 Dokploy 直接读仓库里的 docker-compose.yml。
• 在 Environment 里填上 DB_PASS 等变量——Dokploy 会把它们注入容器，等价于本地 .env。
• 点 Deploy。Dokploy 会用标准的 docker compose up 拉起整个栈，web、db、worker 的网络和依赖顺序原样保留。

部署成功后，给 web 服务在 Dokploy 里配一个域名，Traefik 会自动接管路由和 HTTPS。这就是 Dokploy 比 CapRover 强的地方：多服务栈不用拆成一个个「app」分别部署，Compose 的网络模型完整保留。

• 坑三：compose 里如果写了 build，Dokploy 默认会用远端构建，请确认仓库根目录的 Dockerfile 路径正确，否则会卡在 build 阶段。
• 坑四：别在 compose 里写死 ports 把端口映射到宿主机又想用 Traefik 反代，二者会抢端口。需要公网访问的服务交给 Traefik，内部服务只留暴露（expose）即可。

数据库自动备份怎么配

Dokploy 的备份是它被低估的好用功能。进入对应数据库的详情页，找到 Backup 标签：

• 先添加一个 Destination（备份目的地），支持 S3 兼容存储、本地路径等。个人项目用 S3 或 Cloudflare R2 最省心。
• 设置备份频率（如每天凌晨 3 点）、保留份数，Dokploy 会定时把 dump 推到目的地。
• 恢复时直接在面板选一份备份点「Restore」即可，不需要你手敲 pg_restore。

这比 Coolify「备份 UI 只覆盖一部分、生产级恢复还得 SSH 上去手动搞」要诚实得多。对自托管玩家来说，能一键还原的备份才是真备份。

想上规模？Docker Swarm 多机部署

当一台机器不够用时，Dokploy 的 Swarm 支持就值钱了。架构上它本身就是围绕 Swarm 设计的：

• 在 Dokploy 里把第二台机器作为 Worker Node 加入集群，只需在被加机器上跑面板给出的 join 命令。
• 之后部署应用时可以指定调度到哪些节点，Traefik 在管理节点统一做入口路由。
• 数据库和有状态服务建议固定到单一节点 + 外部存储，无状态 web/worker 则可以跨节点横向扩。

对绝大多数个人玩家，单机能跑就别急着上 Swarm——它带来的是运维复杂度。但知道「哪天要扩，Dokploy 原生就支持」会让你安心不少。RackNerd、HostDare、LisaHost 都能再加一台做节点，成本仍然远低于同配置的托管 PaaS。

避坑清单：中文圈教程常漏的 8 个点

• 内存算错：只算了 Dokploy 的 350MB，忘了给 Postgres/worker 留量，结果 OOM 被杀。
• 面板裸奔：3000 端口直接公网，没限制 IP，也没改默认密码。
• 证书失败：服务器时间不对、或 80/443 被别的程序占用，Let's Encrypt 签发卡住。
• Compose 端口冲突：既映射 ports 又交给 Traefik，端口打架。
• build 路径错：多阶段 Dockerfile 上下文路径没配对，远端构建失败。
• 备份没验证：配了 S3 备份却从没试过还原，真出事才发现凭证写错。
• Swarm 盲目上：单机阶段就开多节点，反而增加故障面。
• 环境变量漏填：本地靠 .env 跑，上 Dokploy 忘了在 Environment 里补，应用启动即崩。

我实测跑了一周的真实体感

光看数字没意思，说点落地感受。我把这套 web+db+worker 栈放在一台 2G 的机器上跑了整整一周，期间经历过两次代码更新、一次数据库备份还原演练、以及一次手滑把 worker 配崩的重启。整周下来 Dokploy 面板自身稳定在 350MB 上下，没有出现过内存抖动把机器拖垮的情况；对比我之前同配置跑 Coolify，光面板就把可用内存吃到见底，部署时 CPU 还会飙到明显能感知的占用。

最让我省心的是 Compose 原样跑通。我的项目本来就是 docker-compose.yml 驱动开发的，迁移到 Dokploy 几乎是「复制粘贴」：把文件贴进应用配置、填好环境变量、点部署，三分钟整个栈就起来了，web 自动拿到 HTTPS 域名，db 和 worker 在内部网络里自己连。换成 CapRover 我得拆成三个独立 app 再手工接网络，换成 Coolify 则要把 Compose 改造成它能理解的形态，光想就头大。

唯一要提醒的是心态：Dokploy 还年轻，文档偶尔会落后于版本，遇到诡异报错先去 GitHub Discussions 或 Discord 搜，基本都能找到答案。它不追求功能全，但把「轻量 + Compose + 备份 + 可扩到多机」这条主线做得很扎实。对只想用最小开销管好多服务、又不想被 Coolify 的内存账单绑架的技术玩家，2026 年它基本是闭眼选的答案。