Zeabur 開源了，不用它也值得讀：我讓 AI 拆完 6 個 repo 挖出的設計與資安教訓

10 月 28 日 Zeabur 把自己的部署平台開源了，社群留言卻幾乎全在吵「誰敢用」「誰想被駭」。

我用 Zeabur 用了大半年，歷經 8 月與 10 月兩次環境變數外洩、10 月 17 日官方宣布年底結束營運後，早就把服務搬到 Railway。照理說，我最沒理由再回頭看它。但看到開源的消息，我第一個念頭就是直接派 AI 把它開出來的 6 個 repo 全抓下來拆一遍，看看人家的 PaaS 到底是怎麼做的。

到底誰說開源專案一定要拿來用？拿來當自己做產品與自架服務的參考文件不行嗎？

為甚麼一個你已經不用的開源專案，反而值得讓 AI 讀一遍？

因為產品官網只會告訴你它能做甚麼，開源出來的程式碼卻會直接攤開它怎麼做、在哪裡妥協。

平常我們用別人的 SaaS 或 PaaS，看到的只是包裝好的介面。新用戶第一次部署預設值怎麼填、容器記憶體爆掉跳甚麼訊息、建置跟上線怎麼切開，這些別人花了三年半試出來的產品決定與踩過的坑，平常根本看不到，現在卻整套攤在 GitHub 上。

以前這種跨好幾個 repo 的系統很少人會細讀，光自己翻完就要好幾天。現在先讓 AI 把架構走一遍，針對你想學的主題把檔案路徑與實作挖出來，不到一小時就能換回一份自己做系統時隨時能翻的對照表。

我實際讓 AI 拆完 Zeabur 的 6 個開源 repo，那三個問題挖出了甚麼？

我們直接把 zeabur、builder、zbpack、cli、catalog、identity 六個 repo 拉下來，讓 AI 針對「好設計、黏著體驗、資安盲點」三題逐一追查，挖出了這些具體實作。

問 AI 的問題	對應的開源模組與路徑	從原始碼挖出來的實際做法
1. 哪些架構設計做得好，值得學？	`zeabur-oss/zeabur`（`crates/zeabur-kube`）與 `zeabur-oss/builder`	管理層不自己養資料庫，直接拿 Kubernetes 當唯一正本；Webhook 驗簽後必回 Git 查證版本，且單次建置只拿單次 registry 推送權限
2. 使用者為甚麼會黏著，做了哪些體驗優化？	`zeabur/zbpack`、`zeabur-oss/catalog`、`zeabur-oss/zeabur`（`crates/zeabur-gaps`、`crates/zeabur-plan`）	自動偵測框架零設定上線、把「出事時」做成直連設定頁的診斷器，改設定前先預覽會不會重啟或掉資料
3. 為甚麼會出資安問題，有哪些寫法要避開？	`zbpack/pkg/zeaburpack/injection.go`、`cli/pkg/config/init.go`、`cli/internal/cmd/auth/login/login.go`	建置階段把使用者變數寫進 Dockerfile `ENV`、CLI 把 token 明文存本機設定檔，開 `--debug` 時還可能把登入 token 印進日誌

第一題：哪些設計做得好，值得學？

最漂亮的一個決定，是管理層自己不養資料庫，直接拿 Kubernetes 當唯一正本（zeabur-oss/zeabur 的 crates/zeabur-kube）。 很多團隊做管理後台，習慣在資料庫存一份狀態再去同步容器叢集，最後兩邊對不上就開始鬼打牆。它直接讀寫 Kubernetes 資源，就算把整個 Web 管理介面拆掉，已經部署上去的服務照樣能正常跑。

建置與部署的隔離也很乾淨。收到 Git Webhook 驗完簽章，它不會直接相信 payload 裡的資訊，一定回頭向 Git 查證實際版本；接著每個版本開一個獨立的 Kubernetes Job 用 BuildKit 建置（zeabur-oss/builder），內部映像倉庫的推送權限只發給那一次 build，建置完再交給 Keel 自動接新映像更新 Deployment。

翻根目錄時還有一個意外收穫。它在 .claude/skills/ 底下直接放了 8 個團隊內部寫給 AI 用的 Skill（從 zeabur-dev、zeabur-spec-work、zeabur-cluster-tests 到 zeabur-ui 與 zeabur-wording），連團隊平常怎麼規定 AI 寫規格、跑叢集測試與統一介面用字，都能直接打開來學。

第二題：使用者為甚麼會黏著，它做了哪些體驗優化？

很多人當初離不開 Zeabur，是因為它把部署跟除錯這兩件最煩的事降到最低門檻。 看原始碼，這套體驗靠三個模組撐起來：

一鍵辨識與組合模板（zeabur/zbpack ＋ zeabur-oss/catalog）：zbpack 會依序跑各語言與框架的辨識器，第一個命中的就自動決定建置方式，讓會用 AI 寫程式卻不懂 Dockerfile 的人一兩分鐘就能上線；catalog 的模板則是一次把應用程式、資料庫、密碼生成與內網連線全部綁好。當你在上面一鍵開了十幾個互相連線的服務，搬家成本自然就高。
把「出事時」當成產品來做（crates/zeabur-gaps/src/diagnose.rs、trace.rs）：一般平台服務掛掉只會丟一堆 log 叫你自己翻。它專門做了一層診斷與鏈路追查，逐段追 DNS → 入口 → 憑證 → Pod 卡在哪裡，把容器記憶體爆掉（OOM）或缺少 Secret 翻成白話原因，旁邊直接放一顆跳去對應設定頁的按鈕。
高風險操作先預覽後果（crates/zeabur-plan/src/change.rs、durability.rs）：在介面改設定按下儲存前，它會先算出這次改動會重啟哪些元件、會不會短暫停機、有沒有掉資料的風險，列清楚才讓你按確認。這對我們自己做 AI 代操作或顧問交付工具很有啟發。

第三題：為甚麼會出資安問題，同樣的寫法在別的地方還有沒有？

對照官方先前的資安報告與停運公告，雲端版兩次出事的破口都很清楚，而且在開源出來的程式碼裡也能看到同類型的邊界習慣。 第一次（8 月）是東京共享叢集上某個用戶部署的容器漏洞被打穿進內網；第二次（10 月）則是設定 repo 裡放了設為「不過期」且從未輪替的明文叢集管理 token，加上主機初始化設定的明文 root 密碼一直沒修，被入侵後整整 36 小時都沒有告警。

帶著這個問題讓 AI 去掃開源出來的幾個 repo，馬上在程式碼裡看到同類型的邊界習慣：

變數直接寫進 Dockerfile ENV（zbpack/pkg/zeaburpack/injection.go）：建置時會把使用者傳入的變數直接拼進 Dockerfile 的 ENV 指令。如果把 API 金鑰當一般環境變數傳進去，密鑰就會留在建置出來的映像層裡，任何能連進內部 registry 讀映像的人都能拿到。
CLI 明文存 token 與除錯日誌外洩風險（cli/pkg/config/init.go、cli/internal/cmd/auth/login/login.go）：命令列工具把登入後的 token 直接用明文寫進 ~/.config/zeabur/cli.yaml，沒特別收緊檔案權限；開啟 --debug 模式時，登入流程的 token 還有被印進日誌的風險。
共享環境的信任邊界：開源版的建置服務使用 privileged 模式，同一個 Namespace 底下共用快取，網路隔離也只擋進向流量不擋出向；所以官方文件直接寫明，同一個叢集裡的使用者必須彼此信任，互不信任的租戶一定要分開叢集。

看完這三點，回頭檢查自己的專案就知道該盯哪裡：別把密鑰塞進會留在 Docker image layer 的 ENV、CLI 存本機憑證要鎖權限並遮罩 debug log、多租戶跑不受信任的程式碼時一定要把叢集與內網隔開。

下次看到別的開源專案，怎麼交代 AI 幫你拆出參考文件？

先叫 AI 畫出架構地圖與請求路徑，再問這三題，並規定每個結論都要附上檔案路徑。

沒先畫地圖就叫 AI 回答問題，它很容易只讀前幾個檔案就順著 README 編故事。下次看到想研究的開源專案，把 repo 拉下來後，直接把這段指令貼給 Claude Code：

程式碼

請先讀這個 repo 的目錄結構與核心套件，不要只看 README：
1. 先畫出模組地圖，以及一個核心操作（例如部署或請求）從入口到完成經過哪些檔案。
2. 接著回答三個問題，每個結論都必須附上實際的檔案路徑與函式位置：
   - 哪些架構或取捨設計得好，值得我們自己的專案學？
   - 它做了哪些降低上手門檻或出錯時留住使用者的體驗細節？
   - 認證、密鑰處理、權限隔離或預設設定裡，有哪些潛在的資安邊界問題？
3. 最後按「我們自己做系統時會碰到的場景」整理成一份可隨時翻查的參考文件。

甚麼時候不用這樣整包拆？

兩種情況，不用大費周章畫地圖跑三題。

只是要查某個 API 怎麼呼叫或修一個小 bug：直接用 rg 搜對應的函式名或錯誤字串，跳進那個檔案讀前後幾十行就夠了，不用把整個專案拆成參考文件。
只有空殼或剛開幾天的玩具專案：還沒經過真實用戶與線上故障考驗的 repo，裡面多半只有框架預設樣板，讀了也挖不出「在哪裡妥協、怎麼處理出事現場」的設計經驗。

這跟你用不用 AWS、GCP，或者還會不會用 Zeabur 都無關。別人花了三年半在真實市場試出來的架構決定、留人細節與資安慘痛教訓就攤在那裡，讓 AI 花一小時幫你拆開讀一遍，換回來的就是自己做產品時少走冤枉路的底氣。

這種「動手前先讓 AI 把現場走一遍」的做法，我寫測試時也一樣照做：叫 AI 補 E2E 測試前，一定先讓它打開瀏覽器當一次實際的使用者。具體流程可以看〈叫 AI 寫測試之前，先叫它當一次使用者〉。