Zeabur 避難 skill
這幾天很多人在討論 Zeabur 的資安事件。
我有一個朋友跟我說，他在 Zeabur 裡面大概有 30 幾個專案，現在只能一個一個查。
簡單講，Zeabur 在 2026-08-28 公開資安事件，說明有一組內部服務憑證遭未授權存取，並被用來取回專案環境變數記錄。很多人放在上面的 OpenAI、Anthropic、OpenRouter API key，後來也傳出被盜刷或濫用。
於是我寫了一個 Claude Code skill，讓它照著正確步驟幫你止血、盤點、判斷要搬去哪裡：
https://github.com/dawson54068/zeabur-refugee
這篇不是在講很深的技術。這個專案本身也沒有什麼太深奧的東西。
它比較像一份「AI 會照著跑的避難流程」——把人容易漏掉、順序容易做錯、需要根據專案判斷的地方，整理成一個 skill。
先止血，再搬家
這次最容易做錯的地方，是一開始就急著搬。
但如果環境變數已經被讀走，第一步不是「找下一個平台」，而是先把會繼續燒錢或繼續外洩的東西處理掉。
所以這個 skill 一開始會先引導你做幾件事：
- 保留用量截圖，之後才有機會跟平台或供應商溝通
- 關掉或暫停可能繼續自動扣款的服務
- 撤銷已經外洩的 API key
- 盤點 Zeabur 上每個專案用到哪些環境變數
- 再決定哪些專案要搬、哪些可以直接下線
這個順序很重要。
如果你先把 key 撤掉，卻沒有留用量截圖，後面要申請補償會很麻煩。反過來，如果你只截圖不撤 key，損失可能繼續擴大。
問題不在模型多聰明，而在流程有沒有先排好。
30 幾個專案，不應該搬 30 幾次
朋友那句「我現在一個一個查」，其實就是這個 skill 最想解的問題。
如果你 Zeabur 上只有一個小 side project，那手動處理還可以。
但 30 幾個專案就不是這樣了。
每個專案可能有不同狀態：
- 有些只是靜態網站
- 有些有 database
- 有些有 webhook
- 有些有 cron job
- 有些其實已經沒在用
- 有些只是 demo，但裡面還放著真 key
這時候你需要的不是「全部搬到同一個地方」。
你需要的是先盤點，分出優先順序，再根據每個專案的特性選新平台。
這種情境很適合用 skill，因為這不是有固定答案的問題。
如果只是把所有專案打包搬到某台 VPS，那寫一段固定流程就好。但這次真正麻煩的是判斷：哪個可以關、哪個要保留資料、哪個要先換 webhook URL、哪個要先凍結寫入。
這些判斷很適合交給 AI 做第一輪整理，人再確認。
替代平台沒有唯一答案
很多人會問：那要搬去哪裡？
這題沒有標準答案。
Railway、Render、Fly.io、Vercel、Cloudflare、自己架 Coolify 或 Dokploy，各自都有適合的使用情境。
如果你的專案是 Node.js API，而且需要 database，Railway 可能很順。
如果是前端網站，Vercel 或 Cloudflare Pages 可能比較自然。
如果你想把控制權拿回來，又可以接受自己維護 VPS，那 Coolify / Dokploy 會比較像 Zeabur 的自架替代品。
但如果你的專案有長時間執行的背景工作、固定排程、特殊網路需求，答案又會不一樣。
所以我沒有把 skill 寫成「請把所有東西搬到 X」。
它做的是先看你的專案架構跟需求，再用平台的限制去比對。
這也是我覺得 skill 比單純文件更適合的地方：文件可以列選項，但 AI 可以幫你把你自己的專案拿進來比。
資料庫不是倒出來一次就結束
這次如果只是搬一個不把重要資料存在服務本身的 app，還算單純。
麻煩的是 database。
很多人直覺會想：我把資料倒出來一次，再倒進新平台，就好了。
但如果你的服務還在線上，有人在寫資料，這樣很容易少資料。
比較安全的流程應該是：
- 先演練一次備份跟還原
- 確認新平台可以正常連線
- 找一個可以接受的時間點凍結寫入
- 做最後一次備份
- 還原到新平台
- 驗證資料筆數跟主要功能
- 確認沒問題後再切流量
這些步驟本身沒有魔法。
但人在事件壓力下很容易漏掉步驟。尤其是 API key 已經外洩、帳單可能正在燒、服務又不能停太久的時候，更容易只想趕快搬完。
skill 的價值就在這裡：它不是幫你按下一個萬能按鈕，而是在每一步先提醒你要確認什麼。
我為什麼把它寫成 skill
如果只是一份清單，我可以寫 README。
如果只是固定動作，我可以寫 script。
但 Zeabur 這件事卡在中間：
它有固定流程，也有很多地方需要判斷。
固定流程包含：先止血、保留證據、撤 key、盤點專案、選新平台、遷移、驗證、最後下線。
需要判斷的地方包含：每個專案要不要保留、資料庫要怎麼搬、哪個平台適合、哪些環境變數要換、哪些 webhook 或 token 也要一起處理。
這種東西很適合寫成 skill。
因為 skill 不是把所有答案寫死，而是先限制模型不要亂跑：先做什麼、不能做什麼、做到哪一步要停下來讓人確認。
對我來說，這個專案不是在展示什麼厲害技術。
它只是把這場混亂，整理成 AI 能照著跑、人也看得懂的流程。
一句話總結：這次需要的不是更快的搬家工具，而是不要在慌亂中把順序做反。
- zeabur-refugee：https://github.com/dawson54068/zeabur-refugee
- Zeabur 資安事件說明：https://zeabur.com/forum/posts/698a59ea290fc4cc98b92c4e
- INSIDE 事件報導：https://www.inside.com.tw/article/42241-zeabur-environment-variable-leak-api-keys-stolen
- KodeLab 事件整理：https://klab.tw/2026/08/zeabur-environment-variable-key-leak/