Coolify 與 Dokploy，自架 PaaS 的部署流程與資源佔用

Dokploy 的安裝流程

Dokploy 同樣提供一鍵腳本，會安裝 Docker 並啟動自身服務，核心元件包含應用本體（TypeScript 生态，前端 React、後端 tRPC）、PostgreSQL、Redis，以及預設的 Traefik 反向代理。官方文件標示的最低需求也是 2 GB 記憶體，但由於元件較精簡，實際閒置佔用明顯低於 Coolify。

另一個實務差異是：Dokploy 的安裝過程對「已存在的 Docker 環境」較為寬容，若你的機器上已有其他容器在跑，它通常能和平共處；Coolify 則較傾向接管整台機器的 Docker 環境，混用時需要多留意連接埠與網路衝突。

三、部署流程實測：從 Git 到上線

部署流程是這類工具最核心的體驗。以下以最常見的場景為例：一個 Node.js / Next.js 應用，程式碼託管在 GitHub，需要連接資料庫並綁定自訂網域。

Coolify 的部署流程

在 Coolify 中，第一步是建立 Project，然後在 Project 底下新增 Resource。Resource 的類型非常多：Application（Git 來源）、Dockerfile、Docker Compose、靜態網站、預建映像檔，以及一鍵資料庫。選擇 Application 後，授權 GitHub App（或使用 Deploy Key）並挑選倉庫與分支，Coolify 會自動偵測框架類型並建議 Nixpacks 或 Dockerfile 建置方式。

接著設定 Build Pack、啟動指令、連接埠、環境變數、持久化磁碟區（Persistent Storage），最後按下 Deploy。Coolify 會執行 build、啟動容器、由 Traefik 註冊路由，並在網域 DNS 指向正確時自動申請 Let's Encrypt 憑證。整個過程在 UI 上以即時日誌呈現，失敗時錯誤訊息相當詳細，通常足以定位問題。

Coolify 的一大優勢是「一鍵資料庫」與「服務模板」。它內建 PostgreSQL、MySQL、MariaDB、MongoDB、Redis、ClickHouse 等資料庫範本，還有一個涵蓋數百種自架應用的服務市集，像是 Uptime Kuma、n8n、Plausible、MinIO 等，選了就能部署，省去大量撰寫 compose 檔的時間。

Dokploy 的部署流程

Dokploy 的操作路徑類似但更扁平：建立 Project → 建立 Application → 連接 Git Provider（支援 GitHub、GitLab、Bitbucket、Gitea 與自訂 Git 位址）→ 選擇分支與建置方式。建置方式包含 Nixpacks、Dockerfile、Heroku Buildpacks、靜態輸出與 Docker Compose，選項與 Coolify 相當。

Dokploy 的亮點在於部署後的「環境」概念。它原生支援 Preview Deployment，可以為每個 Pull Request 建立獨立環境並自動帶入對應的網域，這對需要多人協作、想在有 QA 環境的團隊非常實用。此外，它的網域管理介面把「服務網域」與「容器連接埠」的對應關係講得很清楚，初次使用者較不容易迷路。

部署完成後同樣會由 Traefik 接手路由與 HTTPS。Dokploy 也提供內建資料庫（PostgreSQL、MySQL、MariaDB、MongoDB、Redis），並支援自動備份到 S3 相容儲存。

兩者部署流程的關鍵差異

Coolify 在「廣度」上勝出：資源類型多、服務模板多、設定選項細，適合需要一個平台處理各種奇怪需求的人。它的學習曲線也因此稍陡，UI 資訊密度高，新手第一次進入可能會有點迷路。

Dokploy 在「流程順暢度」上勝出：每一步的引導明確，Preview Deployment 與多環境管理是原生設計而非外掛，對於習慣 Vercel 工作流的團隊來說轉換成本更低。不過它的生態與模板數量仍不及 Coolify，遇到冷門需求時可能需要自己寫 Dockerfile 或 Compose。

四、資源佔用實測：2 GB 機器的生存遊戲

這一節是本文重點。以下數據來自一台 2 核 2 GB 的 KVM VPS（Ubuntu 22.04、Docker 27.x），以 docker stats 與 free -m 在「安裝完成、閒置 30 分鐘、無任何使用者專案」的狀態下取樣。請注意，具體數字會隨版本更新與作業系統差異而變動，但比例關係具參考價值。

閒置狀態的記憶體基準線

Coolify 在完全閒置時，整體容器組約佔用 750 MB 至 1,100 MB 記憶體，其中應用本體（PHP-FPM 與 Laravel 佇列）約 250 至 400 MB，PostgreSQL 約 100 至 150 MB，Redis 約 20 至 40 MB，即時通訊服務約 80 至 120 MB，Traefik 約 30 至 60 MB。加上作業系統本身約 200 至 300 MB，一台 2 GB 機器在還沒部署任何專案時，可用記憶體就已經所剩不多。

Dokploy 的閒置佔用明顯較低，整體約 400 MB 至 650 MB。應用本體（Node.js 服務）約 150 至 250 MB，PostgreSQL 約 80 至 120 MB，Redis 約 20 至 30 MB，Traefik 約 30 至 50 MB。同樣加上系統開銷，2 GB 機器仍保有一半左右的餘裕。

部署一個 Next.js 應用後的變化

在兩邊各部署一個相同的 Next.js 應用（standalone 輸出、Nixpacks 建置）後，Coolify 端整體記憶體上升到約 1.3 至 1.6 GB，Dokploy 端約 800 MB 至 1.1 GB。換句話說，在 2 GB 機器上，Coolify 部署第二個應用時就有相當高的機率觸發 OOM 或頻繁使用 swap，而 Dokploy 還能再塞一到兩個輕量服務。

CPU 方面，兩者在閒置時都接近 0%，差異不顯著。真正的差異出現在建置階段：Nixpacks 建置 Next.js 應用時，Coolify 端峰值 CPU 可達單核 100% 持續 2 至 4 分鐘，記憶體峰值可能衝到 1.5 GB 以上；Dokploy 的建置流程相似，但因基底佔用較低，整體峰值較不易觸頂。這也是為什麼社群普遍建議：若使用 2 GB 機器跑 Coolify，最好額外加上 2 GB swap。

磁碟佔用的比較

安裝完成後，Coolify 的映像與資料約佔用 2.5 至 4 GB，Dokploy 約 1.5 至 2.5 GB。差異主要來自 Coolify 內建較多服務模板與映像快取。長期使用下，兩者都會累積建置快取與舊映像，需要定期清理；Coolify 的 UI 有內建的清理功能，Dokploy 則需手動執行 docker system prune 或透過排程任務處理。

綜合來看，資源佔用的結論相當明確：Dokploy 在同等功能下更省資源，特別適合 2 GB 甚至 1 GB（勉強）的入門 VPS；Coolify 則建議至少 4 GB 記憶體，才能舒服地跑兩三個服務加上資料庫。

五、功能特性對照：不只是記憶體的問題

資源佔用只是選型的一環。當你把兩者的功能攤開對照，會發現它們的設計取向確實不同。

反向代理與網路

Coolify 預設使用 Traefik，也支援切換至 Caddy，並提供較細緻的代理設定（自訂 Traefik 標籤、middleware、基本驗證）。Dokploy 同樣以 Traefik 為核心，將其包裝成較高階的「網域」與「連接埠」概念，設定更直覺但彈性稍低。若你有複雜的路由需求（例如多層 path-based routing、自訂 middleware），Coolify 的可控性更高。

資料庫與備份

兩者都提供一鍵資料庫與 S3 相容備份。Coolify 的資料庫選項較多（含 ClickHouse、KeyDB 等），備份排程設定也較完整；Dokploy 的備份流程設計得相當順手，支援定時備份與一鍵還原，對於只想「設定一次就忘記它」的人來說體驗更好。

監控、日誌與通知

Coolify 內建即時資源監控圖表與容器日誌檢視，並支援 Discord、Slack、Telegram、Email 等通知管道。Dokploy 同樣提供日誌與基本監控，並可整合外部監控工具。整體而言，Coolify 的內建可觀測性稍強，但兩者都不到專業 APM 的水準，正式環境仍建議外接 Uptime Kuma 或 Grafana 系列。

多伺服器與擴展

Coolify 支援透過 SSH 新增遠端伺服器，將不同專案分散到多台機器，並可指定建置伺服器。Dokploy 則以 Docker Swarm 為基礎，支援多節點部署與服務複本，對於需要水平擴展的場景更為自然。若你的目標是「一台機器跑很多小專案」，Coolify 的多伺服器管理更直覺；若目標是「同一服務跑多個複本」，Dokploy 的 Swarm 整合更合適。

六、誰該選 Coolify？誰該選 Dokploy？

沒有一個工具能在所有情境勝出。以下依照常見使用情境給出建議。

適合 Coolify 的情境

你有一台 4 GB 以上的 VPS，想把它當成個人版的 Heroku，跑五六個不同性質的服務。

你想要較成熟的社群與較多的教學資源，遇到問題時容易找到答案。

適合 Dokploy 的情境

你的預算只能租 2 GB 的入門 VPS，希望平台本身不要吃掉大半資源。

你的團隊習慣 Vercel 式工作流，重視 Preview Deployment 與多環境管理。

你計畫用 Docker Swarm 做多節點部署，或需要為同一服務開多個複本。

你偏好乾淨、引導明確的 UI，不想一開始就被大量設定選項淹沒。

兩者共同的限制

無論選哪一個，都要認清這類自架 PaaS 的共同限制：它們不是 Kubernetes，沒有真正的自動水平擴展與自我修復能力；備份需要你自己驗證還原流程；平台本身也是需要維護的服務，升級時可能遇到 breaking change。把它們視為「大幅降低維運成本的工具」而非「零維運」，期待會更貼近現實。

七、結論：先問你的記憶體，再問你的工作流

如果只能給一句建議，那就是：先看你的機器規格，再看你的工作習慣。

在 2 GB 的入門 VPS 上，Dokploy 幾乎是更理性的選擇。它把「平台自身開銷」壓到較低的水準，讓你辛苦買來的記憶體能真正留給應用程式，同時提供了相當完整的功能與更順暢的部署體驗。對於獨立開發者、Side Project 玩家、小型團隊的內部工具部署，這個組合的性價比極高。

若你手上是 4 GB 以上的機器，或者你明確需要大量現成服務模板、更細緻的反向代理控制、更成熟的社群支援，Coolify 仍然是功能最完整的開源 PaaS 之一。它的資源胃口確實較大，但換來的是更廣的覆蓋面與更少的「這個需求它做不到」時刻。

最後提醒兩件事。第一，無論選哪個，請務必設定 swap、設定資料庫自動備份並定期演練還原，這兩件事比選哪個平台更能決定你會不會在某個凌晨被叫醒。第二，兩者都在快速迭代，本文的資源數據會隨版本更新變動，建議在正式遷移前，先在自己的 VPS 上實際安裝、觀察一週的 docker stats，用真實數據做決定。

自架 PaaS 的價值，不只是省下訂閱費，而是讓你重新掌握部署流程的主導權。選一個你願意長期維護的，比選一個功能最多但讓你頭痛的，重要得多。

```

🏠 返回首頁