Zeabur 開源了。我們把這四年開發與維運部署平台累積的經驗，結合對安全性與使用體驗的研究，重新實作成一個可以自行架設的 Zeabur。你可以把它放在自己的伺服器或 Kubernetes 叢集裡，繼續用熟悉的方式部署和管理服務，也能閱讀、修改它的程式碼。
在第一次資安事故之前，我們就已經開始討論 Zeabur 2.0。當時，平台在擴充與維護上的限制逐漸明顯，使用者提出的需求，也讓我們不斷回頭檢查原本的設計。服務數量增加之後，介面要怎麼幫人掌握狀況？工程師需要更細的設定時，平台能不能保留足夠的操作空間？出了問題，使用者能不能知道該從哪裡開始處理？我們自己也使用 Zeabur，很清楚有些操作雖然做得到，過程卻不夠直覺；有些錯誤訊息看得見，仍然不知道接下來能做什麼。
那時候想改的東西很多，從安全性、底層架構，到部署流程和介面，幾乎每一部分都有重新整理的必要。但既有平台上有正在運作的服務，改造也得照顧它們。因此，一部分工作沿著原有程式逐步改善，讓使用者盡量不用遷移，就能獲得新的功能與安全性改進；另外一些牽涉較廣的想法，則透過新的程式做實驗。整份計畫攤開來看，離完成還很遠。後來，我們先放下完整版本的想像，挑出幾個過去一直沒有解好的問題，一個一個重新研究。
從 Kubernetes 裡找新的做法
起點是重新看 Kubernetes 生態裡已有的元件。網域、憑證、儲存、監控和資料庫，各自都有成熟的做法。我們整理它們適合的使用情境，試著安裝、組合，再觀察哪些地方需要調整。原本需要平台自己維護的能力，有些可以直接交給現有元件處理，剩下的工作，就是怎麼把它們接成使用者容易理解的操作。
其中一個實驗，是直接從 Kubernetes 裡整理出平台上的服務。過去，平台在自己的資料庫裡保存一份服務設定，再根據它建立底層資源。如果工程師直接修改 Kubernetes 裡的內容，平台就得讓兩份資料保持一致。我們想試試看，能不能省掉這份重複的紀錄，直接讀取叢集裡正在使用的設定，從資源之間的關係找出服務、網域、環境變數和磁碟區。
當這些關係能整理成一個專案畫面時，很多事情也跟著變得簡單。原本用其他工具部署的服務，可以直接出現在介面裡；用 kubectl 改過的設定，下次讀取時就能看見。使用者從專案和服務開始管理環境，需要深入時，再回到原本的 Kubernetes 工具。已經有基礎設施的團隊，也不必為了使用介面重新部署服務。
接著是權限。使用者按下「重新啟動」，或打開一份設定時，平台要用誰的身分執行？我們研究讓 Kubernetes 直接驗證登入者身分，再依同一套權限規則決定能不能操作。沿著這個方向做下去，登入逐漸成為一個可以獨立使用的專案，也就是現在的 Zeabur Identity。
把通行密鑰登入、短效權杖和 Kubernetes 授權接起來，是開發過程裡很令人興奮的一步。每個人用自己的帳號登入，能做什麼由 Kubernetes RBAC 決定；管理員有專用帳號，只能用通行密鑰登入，權杖 5 分鐘到期。這套流程也能接到 kubectl 和其他支援 OpenID Connect 的工具，讓團隊成員各自登入，減少共用長期管理員認證資訊的需要。原本從平台登入開始的研究，逐漸有了更廣的用途。
這些實驗進行的同時，既有平台的安全性改造也持續推進。第一次資安事故之後，我們重新檢查敏感資料如何保存、認證資訊如何管理，以及內部服務能取得哪些權限。瀏覽器工作階段、通行密鑰、將部分敏感資料移到使用者自己的伺服器，以及 Kubernetes 原生架構，都是這段過程裡投入的工作。平台應該保存多少資料、持有哪些權限，也成為後續設計反覆檢查的問題。
後來第二次資安事故發生，團隊重新評估既有系統需要的改造與維護，決定結束原有託管平台的營運。使用者提出了希望 Zeabur 開源的期待，我們也放不下這些已經開始有成果的研究。四年來的開發、維運和使用者交流，累積了很多對部署平台的理解；一些以前難以處理的問題，現在有了新的實作方式。於是，我們決定將這些成果重新整理，做成可以自行架設、持續改進的開源版本。
回到工單裡，看使用者真正遇到了什麼
重新實作，也給了我們一個機會，把過去累積的客服工單和使用者回饋再看一次。以前處理問題時，通常得先讓眼前的服務恢復正常，協助使用者完成部署，再繼續下一件工作。這次，我們把大量紀錄整理成 notes，重新看使用者原本想做什麼、操作到哪裡開始困惑，最後又需要什麼協助。相似的困難放在一起，有些就能回到產品設計裡處理。
例如，服務已經啟動，網址卻打不開。使用者需要知道網域該指向哪裡、HTTPS 是否準備好，以及應用程式有沒有在正確的連接埠回應。又或者，資料庫已經建立，下一步卻要先找出帳號密碼，再自己組合連線字串，貼進另一個服務。各個功能可能都已經存在，中間卻還有一段需要使用者自己接起來的工作。我們開始特別留意這些地方，讓一個操作能順著接到下一個操作。
這也需要理解不同的人怎麼使用平台。獨立開發者可能只想趕快把程式放上網路；團隊裡的工程師需要部署、查日誌，卻沒有叢集管理權限；平台工程師熟悉 Kubernetes，更在意既有工具能否繼續使用；有些人則只需要看懂服務狀況，再把問題交給負責的同事。我們整理這些使用者畫像，讓 Agent 依照各自的需求模擬部署、接資料庫、設定網域和排錯，再回到畫面、程式碼和文件，逐一檢查可能卡住的地方。
早期介面就因此找出了不少問題。它可以呈現 Kubernetes 資源，第一次進來的人卻找不到建立專案或部署映像檔的起點；建置頁寫出底下元件的名稱，使用者真正想知道的卻是「新的建置完成後，會不會直接上線」；備份設定列出完整的物件差異，仍然不容易看懂備份會存到哪裡、多久執行一次。後來，表單、用詞與變更預覽都重新調整過：常用操作先用熟悉的概念說明，底層細節留在需要時可以查看的地方。
我們也把反覆用到的方法寫進開發 skills。寫介面文字之前，先確認使用者看見什麼、想完成什麼；碰到權限或認證問題，先讀規格與上游實作；測試時，實際檢查權限不足、設定同時遭到修改等情境。notes 保留研究與決策脈絡，skills 則讓接續工作的 Agent 能沿用已經學到的方法。過去工單裡的經驗、同事對產品的判斷，就這樣逐步接到新的實作與檢查流程裡。
把它當成每天會用的工具
隨著實際操作增加，我們花了更多時間處理服務上線之後的事。服務反覆重新啟動時，把原因、日誌和資源用量接在一起；網域無法連線時，順著流量經過的路徑，找到需要檢查的地方。Kubernetes 的事件與狀態逐漸整理成診斷，服務頁也開始能從問題說明，接到使用者可以採取的下一步。
很多細節是操作後才看清楚的。新版本尚未部署成功，舊版本可能仍然在提供服務，畫面需要把這兩件事說明白；原因相同的訊息，應該整理在一起，讓人先找到要處理的問題。多人協作時，你正在調整副本數，同事可能同時更新映像檔，因此我們做了「檢查變更」：先看準備修改的內容，確認後再套用；如果這段時間物件已經改過，就重新讀取現況。Helm、Argo CD 或 Flux 管理的設定，也會指出來源，方便回到原本的工具修改。
把更多應用程式放進去使用後，建置流程也成為下一個需要重新處理的部分。從 Git 提交程式、產生映像檔，再部署到服務，是很多 Zeabur 使用者已經習慣的工作方式。我們保留這段流程，另外做出獨立的 Zeabur Builder，將各個專案的建置環境與快取分開，整理建置需要的網路和儲存權限，並透過 BuildKit 的機密傳遞機制提供建置變數。
接回介面之後，使用者可以選擇 Dockerfile 或 Railpack，設定儲存庫、建置目錄與變數，從紀錄裡查看結果，再決定自動部署或手動讓新版上線。沿著這個流程操作，我們也能檢查程式從儲存庫到實際執行之間，還有哪些地方說不清楚，或需要多做不必要的步驟。
AI Agents 協助了大量研究、實作與測試，也讓這些實驗能更快反覆嘗試。但產品要怎麼用、哪裡值得繼續改，仍然需要我們實際操作與檢閱。有時功能已經完成，卡住的卻是一個看不懂的名稱，或不知道接下來該按哪裡。重新整理使用者經驗、準備測試環境，再將發現留下來，成為這次開發裡持續投入的工作。
從第一台伺服器，到資料的長期維護
服務管理逐漸完整之後，問題又往前後延伸。手上只有一台伺服器的人，要怎麼開始？部署完成後，資料如何保存，出問題時怎麼還原？自行架設需要走過這整段過程，安裝工具、元件選擇和備份流程，也因此一起做了進來。
Zeabur Installer 把準備環境的經驗整理成網頁流程：先檢查主機、磁碟與連接埠，再設定網址、選擇元件，確認資源需求與安裝內容後才執行。Kubernetes 的安全性設定、Secret 靜態加密，以及監控和安全元件的選擇，都放進這段流程。安裝完成後，接著註冊第一位管理員的通行密鑰，就能打開 Zeabur、建立第一個專案。
應用程式範本則讓我們重新研究資料與維護的細節。n8n、Dify、WordPress 這些熟悉的應用程式，各自有不能遺失的資料、備份需要的內容、升級步驟，以及增加執行個體的條件。我們把研究和部署設定整理進 Zeabur Catalog，將叢集共用元件分開管理，讓從範本開始的部署，也有後續可以查閱和修改的依據。
資料庫的操作從建立、連線，一路接到備份與還原。透過對應的 operator 建立資料庫，把連線資訊接到應用程式；設定備份目的地後，可以查看執行結果，需要時還原成新的資料庫，先確認內容，再安排服務切換。磁碟區和叢集備份，也分別接上適合的工具。使用者真正需要還原時，通常已經有很多事情要處理，把來源、目的地、狀態和步驟提前整理好，能減少當下重新查找的工作。
從最初幾個架構實驗，到安裝、登入、建置、排錯與資料維護，原本分散的研究逐漸接成了一段能從頭操作的流程。這是開發過程裡很有成就感的地方：以前反覆討論的問題，現在有了可以親自使用、繼續修改的成果。
現在，這些成果一起公開了。Zeabur Identity、Zeabur Builder、Zeabur Catalog 和管理介面，可以各自發展，也能和其他 Kubernetes 工具一起使用。開發使用的 skills 也保留在程式碼裡，讓有興趣的人了解我們怎麼查規格、檢查介面、重現問題，以及讓 Agent 接續工作。已有環境的團隊可以採用適合自己的部分，從一台伺服器開始的人，也有安裝與部署流程可以跟著嘗試。
這四年的工單與回饋，讓我們知道哪些事情值得重新做好；新的技術與開發方法，則讓這些改進有了實作的機會。開源的 Zeabur 還會繼續調整，但你過去學會的部署方式、團隊已經熟悉的操作，都能在新的架構裡接著使用。我們期待你打開它時，既能找到熟悉的地方，也能發現那些以前讓你卡住的問題，現在有了更好的做法。