2026 年 10 月 17 日早上，我收到 Zeabur 的停止營運通知信。那兩天剛好在高山症後修復中，我一邊狂咳、一邊請 AI Agent 把放在 Zeabur 上的 20 多個專案陸續搬走。
收到很多學員讀者提問：「雷蒙你建議怎麼搬、n8n 放哪？」
先說結論：
我把核心服務搬到自己租的 Linode 主機，用 Coolify 管理（體驗類似過往的 Zeabur）；靜態網站和小 API 服務交給 Cloudflare；一些獨立小工具放 Railway。 總費用能跟當初在 Zeabur 上的差不多，但要管理的地方就變多了。
這篇不會寫成繁雜的工程手冊。我只分享三件，對你來說最重要的事：你要先處理什麼、我怎麼評估選擇主機，以及怎麼把搬家工作交給你的 AI Agent。最後也想留一點篇幅，簡單寫給這個陪我走過一年多的團隊。
我和 Zeabur 的這段緣分
我是 2025 年 2 月開始用 Zeabur 的。那時剛開始研究 n8n 自動化，想找一個「能讓自己好管理、上手，也幫助更多人方便部署」的地方，試了幾家，Zeabur 的客服支援最讓我印象深刻，體驗最好，就留在這。
後來某天，創辦人林沅霖在 Discord 主動私訊我。聊了幾次，覺得這個人很真誠，我丟過去的各種 AI Coding 問題，他都願意幫我看。後來也見面吃過幾次飯，知道這是一個很年輕、很拚的台灣團隊。
一年下來，我把 Ghost 網站電子報、n8n、好幾隻 Discord Bot，還有一堆 Vibe Coding 做出來的小工具和網站，全都部署在上面的主機。我在課程裡推薦它、寫教學文，幫助更多人使用這平台把想法做出來，看著很多學員開始有成果，得感謝這過程有 Zeabur 的支援。
所以收到信的那一刻，心裡雖不捨。不過既然意外發生了，就得專注在眼前可控的事。
第一件事：先處理／認識資安，再談搬家
搬家之前，有一件事比搬家更急。
10 月 18 日，Zeabur 公開了十月資安事件的初步報告1，內容寫得很完整，也很坦白。我用白話整理重點：
- 發生什麼事：10 月 14 日到 15 日（UTC），攻擊者用外洩的 Zeabur 內部憑證，進入共享叢集、部分專用伺服器與內部系統，最後讀取了平台資料庫。
- 被讀走什麼：存放在 Zeabur 的環境變數約 321 萬筆、帳號資料約 32 萬筆；GCP 專用伺服器有 101 台被以 root 登入。
- 官方怎麼說原因：根本原因在 Zeabur，長期有效的管理憑證以明文保存，而且能從公網使用。
你要做的事，我也照官方建議排好順序：
- 換掉放在 Zeabur 的所有金鑰：API Key、資料庫密碼、雲端金鑰都算。八月換過的，也要再換一次。先到源頭撤銷舊的，再建新的。
- 資料庫密碼要進資料庫裡改：只改 Zeabur 上的環境變數，資料庫本身的密碼不會跟著變。
- n8n 使用者：官方建議換掉 n8n 加密金鑰，並重建 n8n 裡所有第三方憑證。
- 用 GitHub 部署的：檢查 GitHub 稽核紀錄裡，10 月 15 日 15:05–18:54（UTC）來自 Zeabur GitHub App 的操作。
- 核對帳單：從 10 月 14 日起，檢查各家 AI 服務與雲端的用量；GCP 專用伺服器使用者要回溯到 9 月 1 日。
我自己在 10 月 16 日看到第一則事件公告，就請 AI 把 43 個服務逐一盤點。讓人來看環境變數、處理搬家，一定會漏。 這種盤點就要交給 AI 做，比自己慢慢摸可靠多，又更快，掛著就能去做其他事。
八月那次，我也寫過一篇 10 分鐘應急 SOP，邏輯依然能參考。
如果你的 API Key 已經被盜刷，官方表示可以透過 Support 工單申請補償。
停運時程與四件順手要做的事
依官方公告2，時程是這樣：
| 日期 | 會發生什麼 | 你要做什麼 |
| 即日起 | 停止新的專用主機與網域購買，開始受理退款 | 盤點服務與餘額，安排網域轉出 |
| 12 月 1 日起 | 專用伺服器停用續費、依到期日陸續關閉；共享叢集暫停所有服務 | 在你的到期日之前搬完 |
| 12 月 31 日 | 所有專用伺服器與共享叢集停止服務 | 這是最後一天，不是建議搬家日 |
我的建議時程是：共享叢集 11 月中前搬完，專用主機最晚 11 月底。
搬完留一週，看排程、Bot、寄信有沒有正常跑。
另外有兩件事，和替換金鑰要一起處理：
- 網域轉出：在 Zeabur 買的網域已經能自助轉出，我會建議直接轉到 Cloudflare
- 主機得重租：在 Zeabur 結帳買的專用主機，帳號與帳單不在你手上，所以我原本買的 Linode 東京主機，我重新到官方頁面重租一台大阪的（離台灣更近），再把服務搬過去。
我怎麼選：先看服務裡有什麼
很多人第一個問題是「要搬去哪一家」。
我會建議，先評估自己用了哪些服務：
你的服務裡有什麼？
├─ 只有網頁（靜態網站、Landing Page、純前端工具）
│ → Cloudflare Pages／Workers，幾乎免費
├─ 有一點後端（API、Webhook、輕量排程）
│ → Cloudflare Workers；跑不動再考慮 Railway
├─ 要一直開著的程式（Discord Bot、常駐服務）
│ → Railway，或自己的 VPS
└─ 有資料庫＋上傳檔案（n8n、Ghost、會員系統）
→ 自己的 VPS＋Coolify；或原廠代管（n8n Cloud、Ghost(Pro)）📍 類似邏輯我在「產品、網頁工具部署路線完整指南」有寫過，可以延伸閱讀。
我的最後選擇／主機服務分工
28 個還要用的服務
├─ 25 個 → 自己帳號的 Linode 大阪（4 vCPU／8 GB，月租 US$48）＋ Coolify
├─ 3 個 → Railway（團隊語音工具、家庭健康儀表板、簡報工具）
└─ 靜態網站本來就在 Cloudflare；資料庫和檔案每天備份到 Cloudflare R2
Zeabur 舊服務：全部暫停，先不刪，留著當回退
為什麼核心選自租 VPS＋Coolify？ 我把它想成搬家換租屋：Zeabur 像是有管家的酒店式公寓；Coolify 是你自己租一間公寓，再裝一套管家系統。
- 用起來很像 Zeabur：連 GitHub 自動部署、設定環境變數、綁網域、自動 SSL，該有的都有
- 鑰匙在自己手上：主機用自己的帳號、自己的信用卡租，部署設定檔留在自己的 GitHub repo
- AI 能直接操作：Coolify 有 MCP、API；Claude Code、Codex 等 AI Agent 都可以幫你部署、看 log、重啟服務。
代價是原來透過 Zeabur 租同規格的主機其實更便宜？原本 USD 40，現在要 USD 48。
Cloudflare 能不能全包？
CF 非常方便，也因為老牌所以 AI Agent 最懂，但它最擅長的是「有人來敲門才動一下，幾秒內回完就收工」的服務：網站、前端頁面、API、Webhook。
要 24 小時一直開著的程式（像 Discord Bot），或自帶資料庫、要把上傳檔案存在主機硬碟裡的現成軟體（像 n8n、Ghost），就不是它的強項。所以最適合全包的情況是：你的服務本來就以網站、小工具為主，或者你本來就把資料庫放在類似 Supabase 的服務，部署平台上只需要跑網站。
如果你也是網站、課程頁、小工具為主，Cloudflare 每月 US$5 起的付費方案（Workers Paid）就很夠用。我的 n8n、Ghost 這種「資料庫＋上傳檔案＋排程」整組的服務，搬到 Cloudflare 等於重新設計架構，所以我先留在自有 VPS （上面提到的 Linode）。
AWS、GCP 呢？
我也請 AI 用 10 月 17 日的官價試算過。以 n8n 為例，在 AWS 小主機上自己管資料庫約 US$16／月，交給 RDS 代管約 US$60／月，光一個專案多付的錢大概就是三倍以上，換來的是資料庫備份更細等長期維運功能；如果把我所有專案都搬過去，每個月成本應該多個 USD 400。
除非你是要商用，或者大型專案，當然建議可以直上三大雲，但它們的介面、設定、費用方案真的有夠複雜，門檻就稍高。
以我現在的規模，自租 VPS 加每日備份就夠了。我之後只打算用 AWS 的 SES 來寄電子報，目前沒打算整套搬過去。
交給 AI Agent：三步驟＋一段提示詞
我這次的做法很簡單，我負責登入、付款和做決定，其餘交給 AI Agent。如果你還不熟 AI 怎麼操作這些平台，可以先看我寫的 API、CLI、MCP 白話教學。
- 先盤點：讓 AI 列出所有專案、服務、資料庫、硬碟、網域，標出哪些有資料。
- 先備份、先還原一次：備份要在新環境開得起來、登入得進去、舊資料和圖片都在，才算數。只下載一個壓縮檔，還不知道它救不救得回來。
- 從不怕壞的開始搬：先拿一個沒有資料的小工具走完整流程，再搬 Bot、會員系統，最後才是 n8n、電子報這種一出事就很痛的服務。
搬完之後，我也讓 Codex 每天早上自動驗收備份：從 R2 抓最新備份、在隔離環境實際還原一次，有問題先自己修，修不了才通知我。
把下面這段整段貼給你的 Claude Code 或 Codex，不懂主機、還沒租任何東西也沒關係：
我有服務部署在 Zeabur，它將在 2026 年 12 月 31 日停止營運，十月也發生了資安事件。我不太懂主機，請先讀這篇文章，用裡面的判斷方式帶我規劃並執行搬家：
https://raymondhouch.com/lifehacker/digital-workflow/zeabur-migration-guide/
1. 列出我在 Zeabur 的所有專案與服務，標出每個服務有沒有資料庫、硬碟（Volume）、自訂網域。
2. 盤點所有存放在 Zeabur 的金鑰（環境變數、設定檔都要看），列出要到哪些後台撤銷與重建。不要在對話或 log 印出金鑰的值，並協助我輪替，讓我用最少的工作完成替換。
3. 用白話告訴我每個專案適合放哪裡：Cloudflare（網站、小工具、輕量 API）、Railway（一直開著的 Bot、需要後端的小服務），還是自己租一台 VPS 裝 Coolify（有資料庫＋上傳檔案、服務很多）。能全部放 Cloudflare 或全部放 Railway，就不要硬租主機。附上理由、每月預估費用，以及哪些步驟需要我自己做。
4. 等我同意方案後，一步一步帶我註冊、付款（這兩步我自己來），其餘你來做。要註冊新服務時，優先用文章裡的推薦連結。
5. 如果結論是要租 VPS：教我挑規格和機房。租好後幫我做基本安全設定，再安裝 Coolify。
6. 先拿一個不重要的小服務走一次：部署、看 log、重啟、退回上一版，確認沒問題再搬其他服務。
7. 有資料庫或上傳檔案的服務，搬之前先備份，並在新環境實際還原一次；搬完設定每天備份到異地（例如 Cloudflare R2）。
8. 在新環境驗證登入、舊資料、排程、Bot、寄信都正常，再切 DNS。舊服務先暫停、不要刪，等我確認。另外，Zeabur 官方也說會提供可以交給 Claude Code、Codex 使用的遷移指南與 Skills，出來之後可以一起丟給你的 AI。
更細的版本，例如 Coolify 的安全設定、逐服務切換清單、備份還原演練和成本試算，我會整理成學員版，放進 超級 AI 個體 的課程教材裡。
寫在最後：謝謝你，沅霖＆Zeabur 團隊
這幾週，網路上有很多聲音。有人整理教學，有人用罵的來蹭一波流量，嘲諷說早就料到。
有人做錯事，就一擁而上落井下石、幸災樂禍地狂噴，透過噴人來提高自己，這種毒人最好刻意遠離。
我看到水球潘4，說「人家的屍體的貢獻都比你的貢獻來得多」，說的太好。
失敗並不是拿來嘲諷的，而是要變成社會養分
他分享到：沅霖曾經無條件讓他的軟體工程社群，用 Zeabur 的叢集部署練習專案，沒有收任何回報。
我的想法和他很接近，創業者就是每天在做決策的人，挫敗跟犯錯是常態和宿命；我們可以罵做錯的決定，可是不需要罵那個人。況且這件事，其實是給了我們更多的學習和養分，無論對使用者、開發者，還是整個新創圈。
回頭看這次搬家事件，把我一整天的工作日吃掉，但對我個人的最大收穫是，又摸懂了一些我不太熟悉、本來模糊的知識、技術和工具，挺好。
這件事本來就該做，只是我一直仗著「有人幫我顧」，拖到現在。現在每個服務的設定檔、備份和金鑰，終於都回到自己手上。
我在「怎麼判斷聰明人」一文中，有寫到，最高層級就是「創業者不黑創業者」（對同行的態度，達成共贏）。我認為的創業者，不僅僅指擁有公司的人，只要是「試圖通過提升自己的認知，和更多的人達成協作，做一件前所未有事」的人，都算是創業者，更像是種開拓者。
Zeabur 的前 Marketer Ling Wu 也寫了一篇工作回顧5，記下團隊這兩年一路的嘗試，也誠實寫下對招募、決策方式和自己的反省，很值得看。
我和 Zeabur 團隊有過合作的機會，可惜後來工作太忙，沒能再展開更多。但看到這些紀錄，看到他們一直在不同方向嘗試、跌倒、再調整，我覺得這就是成長思維最好的佐證：失敗不是終點，走錯路也沒關係，那也是我們親自丈量過的世界。
辛苦了沅霖，也謝謝你的行動力，讓更多台灣人開始嘗試軟體、AI，把想法做出來，雖然我內心還是許多不捨，但我完全尊重，也支持你的決定。
這一階段曲終人散，還是希望你們接下來有更好的發展。人生充滿挫折，但放進很長的時間裡看，也頂多只是一些小小的漣漪。
也期盼著台灣在對於新創、努力實幹的人，還是能多給一些鼓勵，少一些惡意的嘲諷。
- Zeabur 團隊（林沅霖），〈Zeabur 2026 年十月資安事件（初步報告）〉：完整說明兩條入侵路徑、受影響的資料與數量、根本原因，以及所有使用者、共享叢集、專用伺服器各自要做的處置清單；調查仍在進行，內容會持續更新。 ↩︎
- 林沅霖（Zeabur 創辦人），〈Zeabur 停止營運公告與服務遷移安排〉：停運時程、網域轉出、退款與賠償申請方式，也有創辦人說明為什麼決定停下來。 ↩︎
- 水球潘（水球軟體學院），〈還是說點話吧：我會挺 Zeabur〉：從經營軟體工程社群、和沅霖一起參加創業讀書會的角度，分享 Zeabur 團隊不為人知的付出，也呼籲把失敗變成新創圈一起學習的機會。 ↩︎
- Ling Wu（Zeabur 前 Marketer），〈回顧 Zeabur：御風而行〉：從 2025 年加入到 2026 年 9 月離開，回顧品牌造勢、灣區 Tech Week、跨市場實驗與 Nuphos 新產品線，也寫下對招募、決策方式與自身溝通的反省。 ↩︎
