Zeabur 即將關閉，你該搬去哪裡？

許多獨立開發者與小型團隊仰賴的部署平台將於 12 月 31 日正式停止服務。這篇文章將指引你如何理性遷移，不必在恐慌中白白浪費整個週末。

發生了什麼事

10 月 17 日，Zeabur 創辦人向客戶發布電子郵件，宣布公司即將結束該平台的營運。這封信發出前三天，平台剛遭遇第二次資安入侵，距離第一次入侵大約相隔七週。8 月底，攻擊者利用一組舊版 API key 讀取了專案中儲存的環境變數。而 10 月的入侵更進一步滲透到 Zeabur 內部系統及部分客戶的服務，創辦人表示這次受影響的範圍比 8 月那次更大。

他表示團隊在評估資安風險、維持系統運作的龐大負擔，以及繼續營運所需付出的代價後，最終選擇終止服務。他也提到平台的成長已面臨瓶頸。

如果你平時的習慣是將程式碼 push 到 GitHub 後就全交給 Zeabur 處理，這項消息固然令人困擾，但還不至於演變成災難。你還有時間，雖然不算充裕，但只要這週開始著手，時間依然足夠。

重要時程

時程資料源自創辦人於 10 月 17 日寄給客戶的說明信。

• **10 月 17 日起：**不再提供新購專屬伺服器或網域名稱。帳戶餘額退款管道已開啟。
• **12 月 1 日：**共享叢集暫停運作，專屬伺服器停止續約。每台伺服器將在 12 月間各自的到期日關機。被暫停的共享服務可手動重啟以供備份。
• **12 月 31 日：**全數停止運作。Zeabur 表示這是最後期限，並不保證你的服務能一路穩定運行到當天。
• **尚未公布：**資料徹底刪除的確切時間，以及最後匯出期限。切勿乾等這些日期公布。

透過 Zeabur 購買的網域名稱，目前已可自行轉出。

尋找新家前必做的三件事

1. 將所有機敏資訊視為已洩漏。 第一次事件洩漏了環境變數，第二次則滲透得更深，因此請立即輪換（rotate）資料庫密碼、API 金鑰、OAuth 密鑰以及自動化權杖（如 n8n 等工具）。請現在就做，不要等搬遷完成後才處理。
2. 完整備份所有資料。 包括資料庫 dump、儲存空間資料卷（volumes）及上傳的檔案。同時將環境變數複製備份到密碼管理工具中。
3. 提出退款與求償。 帳戶餘額退款與資安外洩損失補償是分開處理的請求，皆須透過 Zeabur 客服提出。台北市消保官表示，退款應以你當初付款的幣別退還。請妥善保存各項收據。

該搬去哪裡：依運行架構選擇

市場上沒有單一的最佳解。本文並未比較目前的方案價格或免費額度，在做決定前，請務必先查看各家服務商的定價頁面。以下建議主要著眼於架構是否契合。

請根據你實際運行的專案架構來挑選。

從 GitHub 部署的 Web 應用程式或 API

可以考慮 Railway 或 Render。兩者都能從你的儲存庫（repo）自動建置、掛載資料庫並處理 HTTPS 憑證。一份 Zeabur 替代方案評測指出，Railway、Render 和 Vercel 是最接近的選擇。我的經驗法則：Railway 的一鍵部署體驗最貼近 Zeabur，而 Render 則是較為穩健、偏向 Heroku 風格的選擇。

以純前端為主：Next.js、Astro、靜態網站

Vercel、Netlify 和 Cloudflare Pages 正是為此而生。但有一點要注意：Zeabur 是以常駐伺服器（persistent server）的形式運行你的應用程式。Serverless 平台執行的則是短暫運作的函式（short functions），因此背景工作（background jobs）、Websocket 以及任何暫存在記憶體中的狀態，可能都需要重新調整架構。

你租用了專屬伺服器，且偏好掌控整台主機

保留獨立主機的想法，但拋棄平台綁定。租用 Hetzner 或 DigitalOcean 的 VPS，搭配 Coolify 或 Dokploy 這類開源自架的部署工具，就能讓你在保有完全控制權與金鑰的同時，享受 push-to-deploy 的便利。代價是你必須自行替主機安裝修補程式。經歷了這個秋天發生的事，相信許多人都能接受這點。如果你之前是將自己的 VPS 連接到 Zeabur，請向你的主機供應商確認當 Zeabur 的控制層關閉後，主機會受到什麼影響。這一點在停運公告中尚未明確說明。

有合規需求或全球用戶的企業

轉向大型公有雲的容器服務：Google Cloud Run、AWS App Runner 或 Azure Container Apps。設定過程需要花比較多時間，但你能獲得完整的稽核軌跡（audit trails）、正式發票，以及受到採購部門認可的伺服器節點。若面對跨國用戶，請確認三件事：鄰近用戶的機房節點（Zeabur 過去在亞洲用戶群中相當受歡迎）、資料依法儲存的地理位置，以及計費使用的幣別。

由 AI 工具協助建置的應用程式

你不需要因此去苦學基礎架構維運，但也不要盲目重新部署。請你的 AI 程式輔助工具提供一份針對目標主機的逐步搬遷計畫，先在預備環境（staging）測試副本，確認無誤後再去動正式的網域。選擇文件齊全的主機商會讓這個過程輕鬆很多。

挑選新主機時必問的四個問題

這次事件是個深刻的提醒：為你提供主機服務的公司隨時可能消失。在註冊任何服務之前，請花十分鐘檢視以下幾點：

• 我能匯出所有資料嗎？ 確認是否支援標準資料庫 dump、可下載的資料卷，以及有文件記載的設定匯出方式。
• 機敏資訊如何儲存與輪換？ 理想的架構應具備限定存取範圍（scoped）與有效期限的金鑰，而非一把能開啟所有大門的陳舊萬用 token。
• 我的用戶分布在哪？資料又存放在哪？ 這項資訊直接關係到連線延遲與法律合規風險。
• 如果服務關閉會有什麼處置？ 明確的提前通知期以及公開的資料刪除政策是負責任的表現；若隻字不提則是個警訊。

這四個問題無法保證搬遷過程萬無一失，但能讓你看清一家廠商有多認真看待那些枯燥繁瑣的細節——而這些細節往往正是你付費購買的核心價值所在。

如何平順無痛地搬遷

在舊環境旁並行建立新環境。還原資料庫備份、在暫時的網址上運行應用程式、完整測試所有重要功能，接著提前一天降低 DNS 的 TTL（存留時間）並進行切換。切換後，將舊環境維持運行一週以接收正常殘存的流量。目標是在 11 月中旬前完成這一切。拖到 12 月 30 日絕對不是可行的計畫，因為共享服務在 12 月 1 日就會暫停。

最後，請選擇隨時能夠抽身的架構。在你的 repo 裡放一份 Dockerfile，搭配能自行執行的資料庫 dump 檔，未來就算再次面對平台關閉，也不過就是耗費一個下午的功夫罷了。

重點速查表