Zeabur 停運怎麼搬家？2026 搬遷步驟與高 CP 值替代方案比較（Railway、Render、VPS 加 Coolify）

Zeabur 在 2026 年 10 月 17 日寄信通知所有用戶：平台將停止營運，12 月 31 日前全面關閉。先給結論：共享叢集用戶的真正死線是 12 月 1 日，那天所有運行中的服務會被暫停；專用伺服器則依各自到期日，在 12 月 1 日到 31 日之間陸續關機。想省錢又不想顧主機，Railway 或 Render 是最接近 Zeabur 的選擇；有三個以上服務的團隊，一台 VPS 加 Coolify 或 Dokploy 最划算，前提是有人顧。

我們公司自己也在這波搬家名單裡。恆遠有數十個系統跑在 Zeabur 專用伺服器上，從官網、自家產品到客戶系統都有，收到信的當天早上，我們就把搬遷排進了工作清單。這篇整理的是我們實際在走的步驟、之前在 Zeabur 上搬服務踩過的坑，以及花了一整天查證的替代平台價格。

還有一件事比搬家更急。10 月 14 日晚間到 15 日凌晨，Zeabur 發生了今年第二起資安事件，動區動趨的整理指出，攻擊者取得共享叢集的平台管理憑證，讀到部分使用者資料庫內容與環境變數，主要目標是 n8n、PostgreSQL、MySQL、Redis 與 AI 類服務。所以這次搬家有一條鐵律：舊平台上的密鑰一個都不要原封不動帶走，搬到哪裡都要換新。事件本身的完整拆解可以看第二次資安事件與停運拆解。

Zeabur 停運時程：12 月 1 日才是真正的死線

一句話：別把 12 月 31 日當成期限。Zeabur 的通知信寫得很清楚，12/31 是「全部停止」的日子，不代表每項服務都能撐到那天。下面這張表把官方公布的時程、你該做的事，以及還沒確定的部分放在一起：

共享叢集其實早就在退場。Zeabur 官方文件寫明，3 月 15 日起不能在共享叢集開新專案，4 月 1 日起既有專案也不能再加服務。當時官方說既有服務會繼續運行，很多人就放著沒動，結果第二次資安事件剛好打在這批服務上，停運公告又把最後期限拉到眼前。

退款與賠償是兩件事，要分開申請。餘額退款是把帳戶裡沒用完的錢拿回來；資安損失賠償是針對 10 月事件造成的損失。兩項都由 Zeabur Support 受理，建議在搬家初期就送出，別等到 Support 停止服務那天才想起來。

官方也說會準備遷移指南，包含提供給 Claude Code、Codex 這類 AI 程式助理讀的 Markdown 指南與 Skills。截至 10 月 17 日我們還沒看到公開版本，官方文件目前只有一份「從共享叢集遷移到伺服器」的七步驟說明，那份是搬到 Zeabur 自己的伺服器，這次已經用不上。

搬家前先盤點：這八樣東西漏一樣就會出事

先講結論：盤點表做完，搬家就完成一半。Zeabur 把很多事情包在平台裡，平常感覺不到，搬走後才發現少了什麼。下面八項逐一填完，每一項都要寫清楚「現在在哪、要搬去哪、誰負責」。

盤點時有個小技巧：把每個服務的「依賴關係」畫出來。哪個 App 連哪顆資料庫、哪個排程呼叫哪支 API、哪個 Webhook 打到哪個服務。畫出來之後，搬遷順序就很清楚了：被依賴的先搬，依賴別人的後搬。

我們自家的產品也在這份清單上，例如把註冊、登入、訂閱與權限抽成共用中樞的恆遠會員中樞系統，底下接了好幾個產品，它就得排在最後切換，因為一動就影響全部。如果你手上的系統也有這種「一個核心牽動好幾個產品」的結構，搬遷順序沒排好很容易連環出事，我們很樂意先陪你把依賴圖畫出來。

資料遷移本身的策略（一次切換、並行運作、漸進切換）我們在客製化系統資料遷移指南寫過完整版。這次 Zeabur 搬家多數情況適合「並行運作後切換」：新舊平台同時跑一段時間，驗證沒問題才切流量。

Zeabur 替代方案怎麼選：五種用戶各有最適合的去處

一句話分流：只跑 n8n 的去 n8n Cloud 或便宜 VPS；個人專案去 Railway；Next.js 前端去 Vercel 加外部資料庫；有資料庫的公司系統，三個服務以下去 Render 或 Railway，三個以上考慮 VPS 加 Coolify；一定要台灣機房的看 GCP 台灣。

n8n 用戶要多想一步。10 月事件的主要目標之一就是 n8n，n8n 的資料庫裡存著你串接的每一個服務的憑證（Google、Slack、LINE、ERP 的 API 金鑰），而解密這些憑證用的 N8N_ENCRYPTION_KEY 就放在環境變數裡。環境變數和資料庫都可能被讀過，等於這些憑證都要當成已外洩處理。所以 n8n 搬家時，工作流可以照搬，每一個 credential 都要到原服務重新產生。

n8n 自架的社群版依 Sustainable Use License 免費使用，公司內部用沒有問題；n8n Cloud 的 Starter 方案年繳每月 20 歐元，每月 2,500 次工作流執行。我們的經驗是：工作流少於二十條、沒有要連公司內網的，付 Cloud 省下的維運時間很值得；超過這個規模，自架在一台 VPS 上，成本只有幾分之一。

想更完整了解各 PaaS 的定位差異，可以回頭看我們之前寫的五大 PaaS 平台完整比較，那篇的平台特性分析大多仍然適用，只是 Zeabur 這一欄已經要劃掉了。

Zeabur 替代平台價格比較表（2026 年 10 月官網實查）

下面每一列的價格，都是我們在 2026 年 10 月 17 日逐一讀官方價格頁或官方文件得到的，以美元計價為主，Hetzner 與 n8n 以歐元計價，皆未含稅。雲端價格常常調整，簽約前請以點進去看到的數字為準。

VPS 上要裝一套自架 PaaS 才會有接近 Zeabur 的操作體驗。Coolify 自架版免費，伺服器最低需求是 2 核心、2 GB 記憶體；如果不想自己維護控制面板，Coolify Cloud 每月 5 美元起可以管 2 台主機。Dokploy 自架也是免費，雲端代管版每台主機每月 4.5 美元起，最低需求 2 GB 記憶體。兩套都能從 GitHub 自動部署、自動簽 HTTPS 憑證、一鍵開資料庫。

有兩個數字特別值得注意。第一，Hetzner 在 2026 年 6 月 15 日大幅調價，CPX22 在歐洲從 €7.99 漲到 €19.49，「Hetzner 最便宜」這個印象要更新了，入門的 CX23 系列漲幅較小，仍然便宜。第二，Hetzner 新加坡機房的價格比歐洲高出不少，要亞洲低延遲的話，Vultr 東京或新加坡的 2 核 4 GB 反而更划算。

延遲方面，東京、新加坡、香港的機房離台灣都比美國近得多，一般網站用起來感覺不出差別；要真的落在台灣，目前大廠裡只有 Google Cloud 的 asia-east1。台灣機房 VPS 的完整比較（含台智雲、中華電信與在地業者）可以看台灣 VPS 怎麼選。

CP 值最高的 Zeabur 替代方案：三個服務以上就該認真考慮 VPS

我們的判斷很直接：一家中小企業如果有三個以上的服務加一顆資料庫，一台 VPS 加 Coolify 或 Dokploy 是 CP 值最高的選擇。前提只有一個：公司裡要有人顧得了這台主機。沒有，就乖乖付 Railway 或 Render 的錢，省下來的月費不夠付一次半夜主機掛掉的代價。

用一個常見的組合算給你看：三個小型 Web 服務、一顆 PostgreSQL、一個 n8n。算式都用上面價格表的官方單價：

價差看起來是兩到八倍，但隱藏成本要算進去：主機系統更新、資料庫備份要自己設、磁碟滿了要自己清、被攻擊要自己處理。一個月花兩個小時顧主機，用工程師時薪換算，常常就把省下來的錢吃掉了。所以服務數量越多，VPS 越划算；只有一兩個服務的，直接用 PaaS 比較實際。

還有一個常被忽略的取捨：PaaS 把 HTTPS 憑證、反向代理都包好了，自己開 VPS 就要自己處理。Coolify 與 Dokploy 底下都會幫你裝好反向代理；如果想自己從頭架，可以看我們寫的 Caddy Server 入門，它是最省事的自動 HTTPS 方案。

Railway 的情況比較特別。它按秒計費，小服務閒置時幾乎不花錢，三個低流量服務加一顆資料庫，常常落在 Hobby 的 5 美元額度附近，比固定月費的 Render 便宜。但用量計費的帳單比較難預估，流量一衝起來就跟著漲，記得在後台設好花費上限。

Zeabur 搬遷 SOP：從匯出資料庫到切換網域的九個步驟

先講結論：照「備份、建新環境、換密鑰、雙跑驗證、切換、保留舊服務」的順序做，每一步都留退路。Zeabur 沒有把服務直接搬到別的平台的功能，所有東西都要在新平台重建，整個流程如下：

步驟一：提前兩天把 DNS TTL 調低

TTL 是 DNS 紀錄被各地快取保存的時間。如果現在設 3600 秒，切換後最久要一小時，全世界的訪客才會連到新主機。提前 48 小時把要切換的紀錄改成 300 秒，切換當天就能在五分鐘內生效。DNS 放在 Cloudflare 且開了橘色雲朵代理的，對外 IP 是 Cloudflare 的，改來源主機幾乎即時生效，這一步可以省略。

步驟二：匯出資料庫

Zeabur 的資料庫服務可以開對外轉發埠，從自己電腦連進去匯出。四種常見資料庫的指令如下，匯出用的工具版本要大於等於伺服器版本，不然會報錯：

# PostgreSQL：自訂格式，還原時可以挑表、可以平行還原
pg_dump "$OLD_DATABASE_URL" -Fc --no-owner --no-acl -f app.dump
pg_restore --no-owner --no-acl -d "$NEW_DATABASE_URL" app.dump

# MySQL：--single-transaction 讓 InnoDB 匯出時不鎖表
mysqldump -h OLD_HOST -P OLD_PORT -u root -p --single-transaction \
  --routines --triggers --set-gtid-purged=OFF app_db > app.sql
mysql -h NEW_HOST -P NEW_PORT -u root -p app_db < app.sql

# MongoDB：壓縮成單一檔案
mongodump --uri="$OLD_MONGO_URI" --archive=app.archive --gzip
mongorestore --uri="$NEW_MONGO_URI" --archive=app.archive --gzip

# Redis：只當快取用的不必搬；有存工作佇列或 session 的才匯出 RDB
redis-cli -u "$OLD_REDIS_URL" --rdb dump.rdb

匯出完一定要做兩個檢查：在新資料庫逐表比對筆數，以及抽幾筆最新的資料確認內容一致。筆數對了但內容是三天前的版本，這種事在「先匯出、隔幾天才切換」的流程裡很常見，所以正式切換前要再匯出一次最新資料。

步驟三：搬 Volume 裡的檔案

使用者上傳的圖片、PDF、SQLite 檔案通常放在 Volume。用 Zeabur 控制台的檔案管理下載，或在服務的指令執行功能裡把掛載目錄打包成 tar 再取回。檔案多的話，建議趁這次改放到 S3 相容的物件儲存（例如 Cloudflare R2），以後換平台就不用再搬一次檔案。

步驟四：環境變數匯出，密鑰全部換新

這是這次搬家最重要的一步。把每個服務的環境變數逐項抄出來，存進公司的密碼管理工具，不要存成明文檔案丟在雲端硬碟。接著把清單分成兩類：一般設定（網址、功能開關）照搬；所有密鑰一律到原服務重新產生，包括資料庫密碼、OpenAI 與 Anthropic 的 API 金鑰、金流金鑰、JWT 簽章密鑰、OAuth 用戶端密鑰、寄信服務金鑰。

為什麼要這麼麻煩？因為 10 月事件中被讀取的就是環境變數。舊密鑰帶到新平台，等於把一把可能已經被複製的鑰匙裝到新家門上。輪替的優先順序與做法，我們在 Zeabur 資安事件白話拆解整理過 72 小時止血清單；公司如果密鑰散落在各處，也可以藉這次搬家導入密鑰管理工具，選型可以參考企業密鑰管理工具採購指南。

還有一個 Zeabur 特有的雷：Zeabur 會把同專案每個服務的 「服務名_HOST」 變數自動注入到所有服務。複製變數時要把這些濾掉，不然新平台上會留下一堆指向舊專案的死參照。

步驟五：新平台上 App 連資料庫一律走內網

這是我們在 Zeabur 上用慘痛經驗換來的教訓。我們曾經有系統的資料庫連線字串寫的是主機的公網 IP 加轉發埠，封包要繞到公網再繞回同一台機器。平常完全正常，直到某天機房公網塞車，同一個列表查詢走公網要 7.9 秒，改走內網只要 16 到 44 毫秒，整站速度差了上百倍。

所以到了新平台，App 連資料庫一律用平台給的內網位址：Railway 的私有網路、Render 的 Internal URL、Fly.io 的 .internal 網域，自架 Coolify 或 Dokploy 則用同一個 Docker 網路裡的服務名稱。上線前在容器裡把實際連線的 host 印出來確認，看到一串公網 IP 就要回頭改。

步驟六：雙跑驗證，再切換網域

新服務先用平台給的測試網址跑起來，完整驗一輪：首頁、登入、資料庫讀寫、檔案上傳下載、排程、寄信、金流測試交易。確認沒問題後，才把正式網域指過去，同時到每一個第三方後台把 Webhook 網址改成新的。

我們 2026 年 9 月在 Zeabur 上搬過一個產品到新專案，流程就是「新專案重建、複製環境變數、切網域、暫停舊服務」，從解綁網域到新網域可以用不到 20 秒。關鍵在於切換腳本寫成「驗證沒過就停手」，舊服務還在，隨時可以綁回去。

切換當下還有一個保險可以加：如果網站前面有 Cloudflare，可以設定在來源主機出錯時先提供快取頁面，切換的那幾秒訪客也看得到內容，做法見 Cloudflare 救援機制實戰。

步驟七：舊服務先暫停，別急著刪

切換成功後，舊服務用暫停取代刪除，至少保留到你確認新平台跑了一個完整的業務週期（月結、排程報表都跑過一輪）。暫停的服務還能恢復，萬一發現少搬了什麼，回去拿還來得及。共享叢集在 12/1 之後也只能手動恢復來備份，所以這個保留期要排在 12/1 之前。

步驟八與九：網域轉出、申請退款

在 Zeabur 買的網域，到網域管理頁取得轉移授權碼，轉到 Cloudflare Registrar 或其他註冊商。ICANN 規定網域在註冊或轉移後 60 天內不能再轉移，最近才買的網域要先確認日期。全部搬完後，把餘額退款與資安損失賠償分別向 Zeabur Support 申請，申請紀錄截圖留存。

這九個步驟本身不難，難在系統一多，每個服務都要走一遍，還要排好順序。看到這裡，如果你在想「我們的系統一個一個搬，要搬到什麼時候」，很歡迎把你的服務清單丟給我們，我們陪你排出搬遷順序，判斷哪些適合 PaaS、哪些適合 VPS。

Zeabur 搬家最常見的踩雷：密鑰原封不動與開機腳本

先講最常見的一個：搬完網站正常，以為大功告成，結果兩週後發現排程沒在跑、通知信沒寄出去。下面是我們整理的常見問題，前三個我們自己都遇過：

開機腳本那一條值得多講。我們之前在 Zeabur 上調整一個系統的資料庫連線時需要重啟服務，重啟會把啟動流程整個重跑。那套系統每次開機都會跑匯入腳本，用器材名稱去比對 Excel，而店員剛好在重啟前兩分鐘改了幾台器材的名字，結果匯入找不到舊名字，又建出一批重複資料。事後花了不少時間比對備份才清乾淨。

搬到新平台時，第一次啟動就是一次「全新開機」，這類問題一定會被觸發。所以搬家前要先檢查入口檔有沒有 seed、backfill、import、deleteMany 這類開機就會寫入的程式，一次性的匯入做完就該從開機流程拿掉。

另外，搬家是重新檢查備份的好機會。新平台的自動備份要開，最好再加一份異地備份到自己的物件儲存，3-2-1 備份原則與復原時間怎麼定，可以參考資料備份與災難復原指南。如果團隊對容器還不熟，先讀 Docker 容器入門，之後不管搬到哪個平台都用得上。

Zeabur 搬遷時程倒推表：從今天到 12 月 1 日

以共享叢集的 12/1 為死線往回推，大約有六週。專用伺服器的用戶請把下表的 12/1 換成你自己的到期日。

系統少的話，這份時程可以壓縮到兩週。真正會拖時間的是「不知道自己有什麼」：沒有文件的老系統、離職同事架的服務、不知道誰在用的排程。這種情況越早開始盤點越好，越晚發現越難補救。

如果這次搬家讓你開始思考「是不是該把所有系統都綁在單一平台上」，我們在 SaaS 退場成本解析整理過簽約前該看的資料遷移條款，選下一個平台時可以拿來對照。也可以回頭看我們之前的 Zeabur 評價，那篇寫於停運之前，裡面講的部署體驗與客服經驗，正好可以拿來當挑選新平台時的檢查項目。

搬家不需要一次做到完美。先把最重要、資料最多的那個系統搬好，其他的照著同一套流程複製就好。要是你手上系統太多、排不出人力，客製化系統開發的團隊可以陪你一起搬，我們很樂意先聽你聊聊現在的情況，哪些自己搬就好、哪些值得找人，我們會直接告訴你。