這篇是〈Zeabur 搬家前先換金鑰〉的延伸。停止營運的時程與搬家順序請先看那篇；搬去哪個 PaaS 的平台比較，見〈Zeabur 替代方案總比較 2026〉。這裡不再比各家平台，只談兩件事：怎麼做決定，以及怎麼替下一次留退場計畫。
文中官方資料的查詢日期是 2026 年 10 月 18–19 日，兩套工具的實測在 10 月 19 日進行。Coolify、Dokploy 的內容引自兩者的官方文件與 GitHub 上的 README、授權檔；兩者都有付費的雲端代管版，這篇不寫價格，以官方價格頁為準。
這次停運，讓「退場」從紙上談兵變成行程表
先看 Zeabur 官方公告與文件寫了什麼，只列事實：
- 時程：12 月 1 日起，專用伺服器停用續費功能，依各自到期日在 12 月間陸續關閉；共享叢集暫停所有運行中的服務，仍可手動恢復運行來備份資料。12 月 31 日所有專用伺服器到期關閉、所有共享叢集停止服務。公告也寫明：「12 月 31 日是平台服務全部停止的日期，並不代表每一項服務都會持續運作到那一天。」
- 還沒確定的日期：公告寫明「資料刪除日期、最晚匯出期限，以及 Zeabur Support 的停止服務日期，目前尚未確定」，並提醒「不要等到資料刪除期限公布才開始準備」。
- 備份：官方文件寫明，主控台的備份「只保留您備份 7 天時間」，而且「尚未支援備份到您自己的 Amazon S3 儲存空間」，要長期留存得自己下載，或寫程式用 API 取回。
- 匯出專案：官方文件寫明，「Export」會把映像、Git repo、環境變數、Volume 定義匯出成 YAML 檔，但不包含資料（does not include data）。
這四件事放在一起，就是退場計畫要先回答的問題：
- 如果供應商下個月就要關，我的資料在哪裡、多久能完整拿到手？
- 備份是存在供應商那邊，還是存在我自己的空間？保留多久？
- 我能不能在別的地方把服務重建起來，而不是只拿到一份設定檔？
- 網域、DNS、帳號在誰名下，能不能自己改、自己轉走？
- 這些事情有沒有人實際做過一次？
這些問題跟選 PaaS 還是自架無關，每一種做法都要回答。差別只在答案由誰負責。
要人代搬可看服務頁。
先做三張檢查表：資料、部署、網域帶不帶得走
下面三張是精簡版，每一項都回答「可以」才算帶得走。答不出來的項目，就是退場計畫要補的地方。
表一：資料可攜
| 檢查 | 怎麼確認 | 答不出來的話 |
|---|---|---|
| 資料庫能用標準工具匯出 | 用 pg_dump、mysqldump 這類資料庫本身的工具，從外面連進去匯出一次 | 只靠平台自家格式的備份，先確認能不能還原到別的地方 |
| 備份能存到自己的空間 | 看平台能不能把備份送到你的 S3 相容空間，或至少能下載 | 平台做不到，就排程自己匯出一份，存到平台以外 |
| 備份保留多久 | 看官方文件寫的保留天數 | 保留期短的，自己另存，保留期拉長 |
| 上傳的檔案（Volume）整包帶得走 | 試著把 Volume 下載或備份一次，對檔案數量 | 改存到物件儲存，或另外排程打包 |
| 還原真的做過 | 在另一台機器還原，比對資料筆數，讓應用程式讀一次 | 先做一次，才知道備份能不能用 |
表中末項不是我們多慮。Coolify 的資料庫備份文件寫得很直接：「A successful backup only proves that Coolify created a file.」（備份成功只代表產生了一個檔案），要還原到一個用完即丟的資料庫、確認應用程式讀得到，才算可以復原。
PostgreSQL、MySQL 的匯出、還原與驗證指令，見〈Zeabur 資料庫備份怎麼帶走〉。
表二：部署可攜
| 檢查 | 怎麼確認 | 答不出來的話 |
|---|---|---|
| 有 Dockerfile 或 docker compose 檔 | 放在你自己的 Git repo 裡，不是只存在平台主控台 | 在本機或另一台機器用它建置一次，補齊缺的步驟 |
| 環境變數有一份清單 | 每個變數的名稱、用途、去哪裡換；值放密碼管理工具 | 從主控台整份複製出來（Zeabur 有「編輯原始環境變數」，可用 .env 格式整份編輯） |
| 知道用了哪些平台專屬變數 | 在程式碼與設定裡搜平台前綴，例如 ZEABUR_ | 搬走後這些變數沒有值，要換成新平台的寫法 |
| 知道「匯出」包含什麼 | 看官方文件，匯出的是設定還是連資料一起 | 只有設定的話，資料另外照表一處理 |
| 排程、建置指令寫在檔案裡 | cron、建置與啟動指令不只存在主控台的欄位 | 寫進 repo 或文件 |
Zeabur 文件列出的平台專屬變數，例如 ${ZEABUR_[連線埠名稱]_URL}、${ZEABUR_SERVICE_ID}、${ZEABUR_PROJECT_ID}，換到任何平台都不會有值。
表三：網域可攜
| 檢查 | 怎麼確認 | 答不出來的話 |
|---|---|---|
| 網域註冊在誰名下 | 登入註冊商看註冊人，是公司還是外包工程師的個人帳號 | 先把網域移到公司帳號 |
| DNS 在哪裡管 | 查網域的 nameserver 指向哪一家 | 搬家前先決定 DNS 要放哪 |
| 能不能自己改 nameserver、自己轉出 | 實際登入看得到這兩個功能 | 平台代購的網域先轉出；Zeabur 公告寫明，在 Zeabur 購買的網域已開放自助轉出 |
| DNS 紀錄有備份 | 匯出一份全部紀錄，包含信箱（MX）與驗證用的 TXT | 換 DNS 時漏了 MX，公司信箱會收不到信 |
| 註冊商帳號的登入方式在誰手上 | 誰有密碼、兩步驟驗證綁誰的手機 | 至少兩位公司內的人能登入 |
網域轉出與 DNS 切換的做法，見〈Zeabur 網域怎麼轉出？〉。
四種選項：誰顧主機、備份在哪、下次好不好搬
三張表做完，再來看要選哪一種。下表是我們依各家官方文件與實務整理的分工，不是任何一家的官方說法：
| 選項 | 誰負責更新與資安修補 | 備份在哪 | 下次要搬容不容易 |
|---|---|---|---|
| PaaS（Railway、Render 等） | 平台顧主機與執行環境；你的程式碼、套件與金鑰仍是你的 | 內建備份通常存在平台那邊，保留天數看平台；要長期留存得自己另存 | 看平台專屬設定用得多不多；有 Dockerfile 與環境變數清單就好搬 |
| 自架 PaaS（VPS＋Coolify／Dokploy） | 作業系統、Docker、控制台本身的更新都是你 | 可設定送到你自己的 S3 相容空間 | 資料與設定都在你的主機上；工具本身也要列入退場計畫 |
| 純 VPS（自己裝 Docker Compose） | 全部是你 | 你自己排、自己決定放哪 | 只要有文件，換一台主機照做即可 |
| 代管（交給別人顧） | 看合約寫誰負責 | 看合約；要問清楚備份存在哪、你拿不拿得到 | 看合約有沒有寫交接方式與資料返還 |
需要的技能，大致是一層一層往上加：
- PaaS：會用 Git、看得懂建置與執行紀錄、會設環境變數。
- 自架 PaaS：再加上 Linux、SSH、防火牆、DNS 與 Docker 的基本操作，以及控制台本身的更新與備份。
- 純 VPS：再加上反向代理、HTTPS 憑證、備份排程與監控，這些都要自己設。
- 代管：技術上不用自己動手，但要會看合約、會驗收，並且手上留一份資料。
自架 PaaS 那一列，Coolify 官方文件寫得很清楚。它的〈Security Model〉列出使用者自己負責的範圍，包括「Operating system and Docker updates, SSH access, firewall rules」，以及「Secret rotation, workload data, backups, restore testing, monitoring, and incident response」。換句話說，工具幫你把部署變簡單，主機的責任還是在你身上。
搬去哪一家 PaaS、各家的區域與計價方式，見〈Zeabur 替代方案總比較 2026〉。
Coolify 和 Dokploy：官方文件寫得到的差異
兩者都是開源、可以自己架的 PaaS 工具，裝在自己的主機上，提供類似 PaaS 的管理介面。下表只列兩邊官方文件與 GitHub repo 寫得到的內容，不比好壞：
| 項目 | Coolify | Dokploy |
|---|---|---|
| 授權 | Apache License 2.0 | 主要是 Apache License 2.0；放在 /proprietary 資料夾的程式另用 Dokploy Source Available License，正式環境使用這部分要有商業協議 |
| 官方寫的需求下限 | 2 核心 CPU、2 GB 記憶體、10 GB 磁碟；只能跑在 Linux，amd64 或 arm64 | 至少 2 GB 記憶體、30 GB 磁碟；80、443、3000 埠要空著 |
| 怎麼管伺服器 | 控制台用 SSH 連到各台伺服器執行 Docker 指令，伺服器上不用裝常駐代理程式 | 安裝腳本會初始化 Docker Swarm；可加遠端伺服器，也可把其他伺服器加成 Swarm 節點 |
| Docker Swarm | 官方標為實驗性功能，不建議新建，v5 會移除 | 多節點擴充用 Docker Swarm |
| 反向代理 | 預設 Traefik，可改 Caddy，或不用內建代理 | Traefik |
| 建置方式 | Nixpacks、Railpack、Dockerfile、Docker Compose、現成的 Docker 映像 | Nixpacks、Railpack、Dockerfile、Buildpack、靜態網站，另原生支援 Docker Compose |
| 資料庫備份 | PostgreSQL、MySQL、MariaDB、MongoDB、ClickHouse、SQLite 可排程備份，存在資料庫那台伺服器，可再上傳一份到 S3 相容空間；Redis、Dragonfly、KeyDB 不在這套流程內 | 備份目的地是 S3 相容空間，排程用 cron 設定；另有 Volume 備份，只支援 Docker named volume，不支援 bind mount |
| 控制台本身的備份 | 有每日的 instance 備份；加密用的 APP_KEY 不在備份裡，要另外保存 | 「Web Server → Backups」把 Dokploy 的資料庫與檔案系統打包成 .zip，上傳到 S3 目的地 |
| 多伺服器 | 一個控制台可管多台伺服器；同一個應用可部署到多台，但不支援 Docker Compose 應用，有持久儲存的應用也不能加伺服器，流量分配要另設負載平衡 | 遠端伺服器分「部署用」與「建置用」；建置伺服器目前只支援 Applications，不支援 Docker Compose |
| 雲端代管版 | Coolify Cloud：Coolify 團隊代管控制台，應用與資料庫仍跑在你提供的伺服器上 | Dokploy Cloud：Dokploy 團隊代管控制台（UI、資料庫、管理層），你接上自己的伺服器 |
幾個從官方文件讀到、跟退場計畫有關的地方：
- 雲端代管版只代管「控制台」。Coolify 文件寫明，Coolify Cloud 改變的是誰來維運 Coolify 本身，連接的伺服器、應用、資料庫與資料的責任不會轉移；Dokploy 文件同樣寫明，Dokploy Cloud 只管部署的調度，應用、資料庫跑在你自己的伺服器上。所以選雲端代管版，主機的更新與備份還是要自己顧。
- 控制台本身也要備份。Coolify 的 instance 備份不含應用與資料庫的資料，而且還原時少了 APP_KEY，存在裡面的密碼都讀不回來；官方建議備份不要只放在 Coolify 那台主機上。Dokploy 的整站備份則要先設好 S3 目的地才能用。
- 停用工具之後會怎樣。Coolify 的 GitHub README 寫明：「If you stop using Coolify, your running resources continue to work and remain manageable.」Dokploy 的官方文件有完整的移除步驟（移除它建立的 Swarm 服務、Volume 與網路），我們沒有查到它對「移除後應用是否繼續運作」的說明，以官方文件為準。
- Dokploy 授權的細節。依 GitHub repo 的資料夾內容，/proprietary 裡放的是 SSO、自訂角色、稽核紀錄、白標等企業功能；官方文件寫明部署的核心功能在各版本都相同。只用部署功能的話，這部分影響不大，但要用企業功能，先看授權條款。
兩者的差異主要在底層架構與多伺服器的做法，不在「能不能部署」。選之前，建議在一台測試主機上各裝一次，部署一個你自己的服務、做一次備份與還原，再決定。
我們在同一台機器各裝了一次
上面的建議我們自己也做了。在自己機房的一台測試虛擬機（4 核 CPU、8 GB 記憶體、60 GB 磁碟，Debian 13）上，每次先退回同一個乾淨系統的快照，再照官方的一行安裝指令安裝，部署同一個小服務（traefik/whoami），用同樣的方法量：
| 項目 | Coolify v4.4.6 | Dokploy v0.30.8 |
|---|---|---|
| 一行安裝跑完 | 4 分 35 秒 | 5 分 39 秒 |
| 網頁可以開 | 第 260 秒 | 第 309 秒 |
| 安裝程式附帶的 Docker | 29.9.1 | 28.5.0，並把主機初始化成 Docker Swarm |
| 閒置時多用的記憶體 | 約 820 MiB（整台 1,165 MiB） | 約 1,175 MiB（整台 1,472 MiB） |
| 多用的磁碟 | 約 2.85 GB | 約 4.7 GB（主程式映像本身 3.25 GB） |
| 第一個服務從建立到有回應 | 約 11 秒 | 約 6.4 秒 |
| 裝完開著的連接埠 | 80、443、8000、8080、6001、6002 | 80、443、3000、2377、7946，UDP 另有 4789、7946 |
「建立」是透過 API 建立服務，不含在網頁上點選的時間；兩邊各量一次，當作量級參考。兩套官方寫的記憶體下限都是 2 GB，以我們量到的閒置用量，2 GB 的主機裝完控制台後，留給服務的空間不多，主機規格要把控制台本身算進去。
裝的過程中，有幾件事是官方需求表看不出來、上線前要知道的：
- Coolify：裝完一定親手打開網頁確認。安裝時可以用環境變數預先設定管理員，但 email 驗證會實際查 DNS。我們用測試網域時驗證沒過，安裝程式照樣跑完、沒有報錯，錯誤只出現在容器紀錄裡；管理員沒建起來，註冊頁就還開著，第一個打開網頁的人就能註冊成管理員。
- Coolify：API 預設是關的，token 要從網頁產生；要寫自動化腳本，先到網頁開啟。
- Dokploy：API key 預設每 24 小時只能呼叫 10 次，用完之後只回
Unauthorized，看不出是次數用完，要看服務紀錄才知道；建 key 時沒帶組織 ID，也一律回Unauthorized。寫自動化腳本前先知道這兩件事。 - 兩邊都有連接埠要收：Coolify 的 8080（Traefik 儀表板）、6001、6002，Dokploy 的 3000（管理介面）、2377、7946、4789（Swarm 用），正式上線前用防火牆收掉。
localhost不一定連得到：兩邊在我們的測試裡，用localhost連服務都失敗、用127.0.0.1正常，原因是localhost先走 IPv6（::1），服務或轉發只走 IPv4。健康檢查與反向代理的位址寫127.0.0.1。
這些都不影響「能不能部署」，但會影響第一次上線的安全與自動化，所以列進測試主機要驗的項目。
退場計畫範本：一頁可以照抄的清單（我們的建議）
下面是我們的建議，不是任何官方要求。一份退場計畫不用很長，一頁就夠，重點是每一項都有人負責、寫得出答案：
服務清單
- 每個服務一行：跑在哪一家、用誰的帳號、哪張卡付款、合約或方案到期日
- 每個服務標出有沒有資料庫、有沒有上傳檔案（Volume）
資料
- 每個資料庫的匯出指令寫成文件，換一個人也照得做
- 備份存兩個地方，其中一個不在同一家供應商
- 自己另存的備份，保留期要長過「發現資料出問題」通常需要的時間
- 每季演練一次還原：在另一台機器還原、比對筆數、讓應用程式讀一次，並寫下花了多久
部署
- Dockerfile 或 compose 檔放在公司自己的 Git repo
- 環境變數清單（名稱、用途、去哪換）放文件，值放密碼管理工具
- 列出用到的平台專屬變數與平台專屬功能，寫下換到別家要怎麼改
網域與帳號
- 網域註冊在公司名下，記下註冊商、DNS 服務商與登入方式
- 每季匯出一份全部 DNS 紀錄
- 主控台、註冊商、雲端帳號都至少有兩位公司內的管理員，用公司信箱註冊、開兩步驟驗證
啟動條件與順序
- 寫下什麼情況就啟動退場：供應商公告停運、發生資安事件、方案或價格大改
- 寫下搬家順序：哪個服務先搬、預計停機多久、誰負責切 DNS
- 每季檢查一次這份清單，跟還原演練同一天做
Zeabur 這次的公告寫明，資料刪除日與最晚匯出期限尚未確定。有退場計畫的團隊，這時候只要照清單做；沒有的，得先花時間弄清楚自己有哪些服務、資料在哪。
我們的做法
我們自己的官網就是 WordPress，跟我們經營的另外幾個 WordPress 站一起跑在我們自己管的主機上，每天自動備份。佈景主題與外掛的程式碼放在我們自己的 Git repo，主機定時從 repo 拉新版本，所以主機要換，程式碼不用另外找；資料庫與上傳的檔案則靠每天的備份帶走。
自己管主機的代價，就是上面表格「自架」那一列寫的：更新、備份、監控都是我們的事。這篇的三張檢查表與退場清單，也是我們拿來對照自己的。
揭露
火曜領航有提供代搬到客戶自選平台、主機代管與金鑰輪換的服務。這篇提到的 Coolify、Dokploy 與各家平台都沒有付我們任何費用，文中沒有聯盟連結；三張檢查表與退場清單，不需要找任何人也能自己做。
如果您的服務還在 Zeabur 上，需要人幫忙盤點、搬遷或輪換金鑰，可以到〈PaaS 停運搬家與資安檢查服務〉看四種做法，或直接填寫詢價表單，我們會在一個工作日內回覆搬遷順序建議。
常見問題
小公司需要退場計畫嗎？
需要，但不用寫得很長。一頁服務清單、資料與網域在誰手上、每季一次還原演練，就涵蓋了大部分情況。以 Zeabur 為例，官方公告在 10 月 17 日發布，12 月 31 日全部停止服務，部分服務 12 月 1 日起就陸續停止。平常有清單的團隊，這段時間可以直接照做。
Coolify 跟 Dokploy 差在哪？
依官方文件，主要差在底層與多伺服器的做法。Coolify 用 SSH 連到各台伺服器執行 Docker 指令，Docker Swarm 是實驗性功能、v5 會移除，反向代理預設 Traefik、可改 Caddy；Dokploy 安裝時會初始化 Docker Swarm，多節點用 Swarm，反向代理用 Traefik。需求下限 Coolify 是 2 核心、2 GB 記憶體、10 GB 磁碟，Dokploy 是 2 GB 記憶體、30 GB 磁碟。我們在同一台 4 核、8 GB 的測試機各裝一次，Coolify 安裝 4 分 35 秒、閒置多用約 820 MiB 記憶體；Dokploy 5 分 39 秒、多用約 1,175 MiB。授權上 Coolify 是 Apache 2.0；Dokploy 主要是 Apache 2.0，企業功能那部分另有授權。兩者都有雲端代管版，只代管控制台，價格以官方價格頁為準。
自架一定比較便宜嗎？
不一定，要看成本結構。自架的成本是主機租金、備份用的儲存空間，加上人的時間：作業系統與工具的更新、監控、半夜出狀況時的處理。PaaS 把這些維運工作包在價格裡，用量大時可能比較貴，用量小時不一定。比較時，把「每個月要花多少小時顧主機」也算進去，才是完整的成本。
自架被駭了誰負責？
你自己。Coolify 官方的〈Security Model〉寫明：「You remain responsible for the security of every server, application, database, network, and backup you control.」即使用 Coolify Cloud，連接的伺服器、應用與資料的責任也不會轉移。另外，這類控制台存著連到各台伺服器的 SSH 金鑰，官方提醒控制台被入侵時，攻擊者可以透過同樣的管理路徑連到伺服器，所以控制台的帳號、兩步驟驗證與更新要特別顧好。
退場計畫多久演練一次？
我們的建議是每季一次完整還原：在另一台機器把資料庫與上傳檔案還原、比對筆數、讓應用程式實際讀一次，並記下花了多久。另外，換了負責人、平台大改版、或方案與合約變動時，再加做一次。
參考來源
- Zeabur，2026-10-17：Zeabur 停止營運公告與服務遷移安排
- Zeabur 文件：備份與還原（2026-05-08 更新）；英文版 Backup
- Zeabur 文件：Export Project（2026-05-08 更新）
- Zeabur 文件：搬遷專案（2026-06-22 更新）
- Zeabur 文件：環境變數（2026-03-19 更新）
- Coolify：GitHub README、LICENSE、官網
- Coolify Docs：Start with Self-hosted、How Coolify Works、Self Hosted vs Coolify Cloud、Security Model、Database Backups、Instance Backup、Docker Swarm、Multi-Server Deployments、Proxy Overview
- Dokploy：GitHub README、LICENSE、LICENSE_PROPRIETARY、官網
- Dokploy Docs：Installation、Architecture、Cloud、Cloud vs Self-Hosted、Backups、Database Backups、Volume Backups、Build Type、Cluster、Remote Servers、Uninstall
以上資料皆於 2026 年 10 月 18–19 日查詢。
最後更新：