從 Zeabur 搬出來：Openship 與 Coolify 比較、最低主機規格

Openship 的部署方式，和 Coolify 有什麼不同？#

Openship 安裝文件列出兩種伺服器模式：Linux 上有 Docker 時，預設使用 Compose；其他環境使用 bare 模式。桌面 App 則讓個人使用者在自己的電腦上操作控制端。

這裡的 PostgreSQL、Redis 是部署平台本身的元件，不能直接當成你的應用程式資料庫。搬一個使用 PostgreSQL 的網站時，還要另外計算網站資料庫所需的記憶體和磁碟。

Openship README說明，桌面控制端只在 App 開啟時運作；需要接收 GitHub webhook 的 push-to-deploy，則要常駐伺服器或 Cloud。對只偶爾手動部署的人，桌面模式值得試；對每次推送都要自動上線的網站，應該比較兩套平台的常駐部署方式。

Coolify則以常駐控制台管理一台或多台透過 SSH 連接的伺服器，應用程式跑在你提供的主機上。Coolify Cloud 代管的是控制端，工作負載主機仍由自己提供。

Openship 最低需要多少 CPU、RAM 和磁碟？#

在本次查閱的安裝文件、README 與自架 Compose 設定中，沒有找到 Openship 控制端明確的 CPU／RAM／磁碟最低要求。 因此，不能把「1 GB 就夠」寫成官方保證。

官網的 Cloud 方案容量、應用程式資源限制，也不能拿來當完整自架平台的最低配置。資源設定文件中的 256 MB、512 MB 等級，是個別容器的限制選項，並未涵蓋整台主機上的控制端、作業系統與其他服務。

下面是供試用選機的估算起點，未經本次實測：

這張表不承諾可以跑幾個專案。十個靜態網站和十個 Node.js API 的資源需求差很多；向量資料庫、Dify 或本機模型也不能套用一般網站的估算。

磁碟要計入映像、建置快取、舊版本、資料庫、上傳檔案和備份。假如資料本身已有 30 GB，40 GB 的系統碟就不適合承擔整個環境。備份另存到其他主機或物件儲存，才有主機故障後可還原的資料。

Coolify 的官方最低要求，比較有明確依據#

截至查核日期，Coolify 官方安裝頁列出：

文件也允許預算有限時從 1 核心、1 GB RAM 開始，再按工作負載升級；更小配置雖然可能運作，官方不建議。對要從 Zeabur 搬服務的情境，我不會用這種縮減配置作為正式容量基準。

站內先前的 Zeabur 與 Coolify 比較記錄的是當時 30 GB 空間要求；本篇採用此次查到的 10 GB 可用空間數字。租 VPS 時仍建議預留比安裝門檻更多的空間。

目前也沒有足夠證據斷言 Openship 比 Coolify 省 RAM。桌面模式讓 VPS 少跑控制端，和兩套完整常駐平台的資源比較，是不同的測試條件。

真正影響小 VPS 的，是建置放在哪裡#

網站上線後佔用的記憶體，和重新部署時需要的記憶體不同。像 Astro 部落格平常可以只提供靜態檔案，但更新時仍要安裝套件、建置網站、處理圖片與搜尋索引。

Openship 部署精靈提供在自己電腦建置的選項；建置錯誤文件也把本機建置列為處理記憶體不足的方式之一。

Coolify 建置文件說明，預設在部署主機建置，也可以部署預先建立的 Docker 映像。若使用獨立 build server，需要容器 registry，而且目前該選項不適用 Docker Compose Application。多服務 Compose 專案可以另外在 CI 建好各服務映像，再讓部署端拉取。

因此，想節省 VPS 規格，可以先把建置移到本機或 CI，再量測部署端需要多少 RAM。多租一台全年常駐的 build server 會增加成本，應先看部署頻率是否值得。

Openship 與 Coolify，搬遷時應該比較哪些功能？#

功能列依據 Openship 功能頁、Coolify 平台說明與 Compose 文件。功能頁代表官方描述，本篇尚未逐項執行驗證。

Openship 有一個值得先釐清的地方：功能頁列出 private networking、scaling 和 load balancing，但 README 的「Coming next」仍列出 private networking、multi-node clusters 與 load-balancing UI。這可能涉及文件同步或功能範圍差異，現有資料不足以確認每一條自架路徑都已完成。

如果你的目標只是單台 VPS 跑網站和 API，先驗證基本部署就有價值。若必要條件包含跨主機私有網路、叢集或負載平衡，應先查選定 release 的實作與限制，再安排搬遷。README 的「Production-ready core」也不能代替自己的還原測試。

Openship 手動 Compose 安裝還有一個容易弄錯的路徑：應使用 docker/docker-compose.yml。根目錄的同名檔案用途不同。自架檔案掛載主機 Docker socket，控制端具有很高的主機權限；部署平台的管理帳號和對外入口需要當作主機管理入口處理。

還有什麼值得一起試？Dokploy#

如果想了解 Coolify 以外的常駐部署控制台，可以把 Dokploy列入下一個候選。它的文件涵蓋應用程式、Docker Compose、資料庫、遠端伺服器和備份；官方安裝頁建議至少 2 GB RAM、30 GB 磁碟，並要求安裝時 80、443、3000 連接埠可用。

這裡先把 Dokploy 當成另一個試用方向，尚未做三套平台的操作或效能排名。對已用過 Coolify 的人，Openship 的桌面模式提供不同工作流程；Dokploy 則適合拿相同 Compose 專案比較常駐控制台的操作感受。

從 Zeabur 搬出來，先搬哪一個服務？#

先選一個容易重新建立、沒有重要持久化資料的服務，例如靜態網站或小型 API。用它跑完部署、網域、更新和回滾，才能知道新平台是否符合日常操作需求。

1. 盤點目前服務。 記錄來源儲存庫、映像版本、啟動指令、環境變數、網域、Volume、資料庫版本，以及服務間的連線名稱。
2. 在新 VPS 重建一個服務。 先用測試子網域，確認 HTTPS、日誌、重新部署和主機重啟後的狀態。
3. 驗證容量。 記錄閒置、一般流量和建置時的 RAM、CPU、磁碟使用量。可以配合 btop 主機監控指南觀察主機，再用 docker stats 看容器即時用量。
4. 另做資料庫與檔案還原演練。 將備份還原到測試環境，確認登入、上傳與背景任務可用，再安排正式資料同步。
5. 最後切換正式流量。 有寫入資料時，安排暫停寫入和最後同步；切換期間避免新舊環境同時接受寫入。DNS 回切只能改變流量方向，不能自動合併兩邊的資料。

備份不能只保存 Git 儲存庫和環境變數。上傳檔案、資料庫內容和其他 Volume 需要各自確認；如果搬的是 Dify，可先用站內的 Zeabur Dify 備份指南盤點資料種類，再按目前版本查證匯出與還原方式。

我的建議是：第一台驗證用 VPS 先規劃 2 vCPU、4 GB RAM、40–60 GB SSD，以 Coolify 作為已知基準，另用 Openship 試一個無狀態服務。 若 Openship 的桌面操作和本機建置確實減少日常工作，再進一步測試常駐自動部署、備份還原和版本升級。等這些流程通過後，才搬需要保存資料的服務。

參考資料：

Openship Features

Openship GitHub

Openship Installation

Coolify 自架安裝與主機規格

Coolify 建置方式

Dokploy Installation