VPS 上跑了三、四個 Docker 服務之後，事情就開始變得繁瑣。每多一個應用就要手寫一份 docker-compose.yml、在 Caddy 或 Nginx Proxy Manager 上多開一個子網域、在 GitHub Actions 裡多塞一段部署腳本，更新時還得記得備份資料庫。原本只想架個 n8n 或 Forgejo，最後卻花一半時間在維護膠水程式碼。
Dokploy 想解決的就是這段。它把 Docker Swarm、Traefik、PostgreSQL 包成一個 Web 介面，讓自架 VPS 的部署體驗接近 Vercel 或 Heroku，但所有資料、流量、憑證都留在自己的機器上。從 2024 年發布到 2026 年，Dokploy 的 GitHub Star 已經突破 30,000，社群採用速度比同類專案 CapRover 還快。
為什麼不直接用 Coolify
聊到自架 PaaS，多數人會先想到 Coolify。Coolify 確實是這個賽道的開創者，Star 數也更高，但它在 2GB VPS 上有一個明顯的問題：閒置時平台本身就吃掉 500MB 到 1.2GB RAM，CPU 在背景監控啟動時還會飆到 25%。對於只想騰出 RAM 跑應用程式的小型 VPS，這是不划算的開銷。
Dokploy 的閒置佔用大約 350MB RAM、CPU 在 1% 以下。同樣是 2GB 的機器，Coolify 跑完平台本身已經少掉一半可用記憶體，Dokploy 還能留 1.6GB 給 PostgreSQL 的 buffer pool 或 Node.js 的 V8 heap。這個差距在每月幾百塊的入門 VPS 上不是學術問題，而是能不能多跑一個服務的差別。
CapRover 則是另一個方向。它從 2017 年開始發展，穩定但保守——不支援 Docker Compose、UI 偏舊、多服務應用要拆成單一容器分別部署。除非已經習慣它的 one-click app 套版，否則 2026 年沒有特別的理由從 Dokploy 切過去。
底層架構：Docker Swarm 重新被翻出來用
Dokploy 跑在 Docker Swarm 上。這個選擇有點違反直覺——多數人提到容器編排時會直接想到 Kubernetes，Swarm 大概從 2018 年之後就被當成過時產物。但對自架 PaaS 來說，Swarm 的取捨剛好對：原生內建在 Docker daemon、不用額外裝 control plane、單台機器跑得起來、想擴成多節點時 docker swarm join 一行就解決。
Traefik 負責反向代理與 Let’s Encrypt 自動憑證。Dokploy 把 Traefik 的設定檔開放給使用者編輯，這代表進階使用者可以塞自訂 middleware，例如 IP 白名單、basic auth、rate limit，不會被介面綁死。後台的設定資料則寫進一個 PostgreSQL 16 容器，掛在 dokploy-postgres 這個 Docker volume 上，備份只需要備份這個 volume。
整套東西用一行指令裝完：
1 | curl -sSL https://dokploy.com/install.sh | sh |
腳本會檢查環境、裝 Docker、初始化 Swarm、建立網路、拉取映像、啟動服務。需要 root 權限、需要 80/443/3000 三個 port 是空的、不能在 Docker 容器裡面跑（Proxmox LXC 有特別處理）。Ubuntu 20.04 以上、Debian 10 以上、Fedora 40、CentOS 8/9 都驗證過。
部署流程實際上長什麼樣
把專案放上去的方式有四種：直接接 GitHub 或 GitLab repo 自動 build、貼一份 Dockerfile、貼一份 docker-compose.yml、或選一個現成 template（n8n、Plausible、Umami 都有範本）。Dokploy 內建 Nixpacks 與 Heroku Buildpack，連 Dockerfile 都不用寫，把 Node.js、Python、Go 的 repo 丟進去就會被自動偵測語言並打包成映像。
這裡值得拿來與其他做法比較。常見的 GitHub Actions 自動部署流程，本質上是把建置與推送寫成 YAML，然後在 VPS 上 docker compose pull && up；換成 Dokploy 之後，這些步驟被收進 Webhook：push 到 main 分支就觸發一次 build，build 失敗有 rollback、build 成功直接接管子網域與憑證。原本要寫 80 行 YAML 才搞定的事，介面上點幾下完成。
資料庫管理是另一個簡化。MySQL、PostgreSQL、MongoDB、MariaDB、Redis 這五種常見資料庫都有 first-class 支援，按下「建立」就會起一個對應容器，連線資訊以環境變數注入到應用程式。內建的排程備份可以直接打到 S3、Backblaze B2 或任何相容物件儲存，省掉自己寫 cron + pg_dump + rclone 的步驟。
介面方便不代表所有東西都該收進來
雖然 Dokploy 把多數情境簡化得很好，但有幾類服務不適合塞進去管理。
第一類是高效能資料庫。容器化的 PostgreSQL 適合中小型應用，但若單一資料庫要支撐每秒上千次寫入，瓶頸通常會出在容器儲存層與 storage driver 帶來的額外磁碟 I/O 開銷；若還有頻繁的跨容器通訊，overlay 網路則會另外增加網路轉送成本。這種情境應該另外開一台 VPS 直接 bare metal 安裝資料庫，讓 Dokploy 上的應用透過內網連過去。
第二類是有狀態的叢集服務，例如 Kafka、Elasticsearch、Cassandra。Docker Swarm 的編排能力處理 stateless web 應用沒問題，碰到需要嚴格 quorum 的分散式系統就力有未逮，這種要嘛上 Kubernetes，要嘛交給專門的託管服務。
第三類是 Dokploy 本身的 Postgres。它不該拿來當應用程式的資料庫使用——那是平台的後設資料儲存，更新 Dokploy 時可能會跑 migration，把業務資料混進去會出事。應用程式的資料庫永遠走 Dokploy「Database」分頁建立的獨立實例。
從 docker-compose 過渡的策略
如果現在 VPS 上已經跑了一堆手寫 compose 服務，不需要急著重做。實務上比較順的做法是新服務先放進 Dokploy，舊服務維持原樣，用 Traefik 的 host rule 讓兩邊共存——Dokploy 的 Traefik 預設只接管自己管理的 service，不會搶佔 host 上其他容器的 port。
要把舊服務搬進 Dokploy 也單純：在介面上開一個 Compose 類型的應用程式，把 docker-compose.yml 內容貼進去，Dokploy 會自動處理網路、子網域、TLS。原本寫死的 80/443 port mapping 改成 Traefik label，環境變數從 .env 改成介面上設定，差不多一個服務 5 分鐘搞定。
值得提醒的是 Dokploy 採用 Apache 2.0 授權但並非完全自由——有付費的雲端版本與企業功能。社群版本足夠 95% 的自架使用情境，但要評估長期是否會碰到功能牆，可以先看官方的 pricing 頁面再決定要不要把核心業務綁上去。
什麼樣的團隊真的會受惠
對於在 2GB 到 8GB 之間的 VPS 上同時跑多個服務的開發者，Dokploy 是 2026 年最划算的自架 PaaS 選擇——資源開銷比 Coolify 少一半、Docker Compose 支援比 CapRover 完整、單一指令就能完整安裝。它不會讓 Kubernetes 過時，也不打算取代手動精雕的 production stack，但對於想把心力花在應用本身、不想再寫第二份部署腳本的人來說，這是最近兩年最值得認真評估的工具之一。
NCSE Network 提供採用 Intel Gold CPU 與 NVMe SSD 的臺灣 VPS 主機，從 2GB 入門方案到多核心高記憶體規格都有，搭配位於是方電訊機房的低延遲網路，無論是 Dokploy 這類 PaaS 還是直接跑 Docker Compose，都能取得穩定的執行環境。詳細方案歡迎參考官網。
