更新日期：2026 年 10 月 19 日
先講結論：Zeabur 官方已宣布逐步結束平台營運，但目前能確認的是「停止營運」，不等於法律或財務意義上的「破產倒閉」。部分服務將自 2026 年 12 月 1 日起陸續停止，所有專用伺服器與共享叢集最晚於 12 月 31 日關閉。
2025 年 11 月，Zeabur 才宣布完成 200 萬美元種子輪融資，當時自稱擁有超過 5,000 名個人付費客戶、年成長率達 500%。約 11 個月後，這家以「後端版 Vercel」起家的台灣團隊，卻宣布結束營運。
真正讓 Zeabur 停下來的，不只是單一駭客事件，也不能簡化成一句「新創燒完錢」。官方說法顯示，這是連續資安事故、長期技術債、產品方向擴張、成長瓶頸與團隊責任承載能力同時交會的結果。
Zeabur 真的倒閉了嗎？
截至 2026 年 10 月 19 日，Zeabur 官方用詞是「逐步結束 Zeabur 平台的營運」，並未在公告中宣告破產、清算或資不抵債。
因此，最精確的說法是：
- 已證實：Zeabur 平台將停止營運。
- 已證實：停止新購專用伺服器與網域，並受理餘額退款。
- 已證實：12 月起分階段停用服務，12 月 31 日完成平台關閉。
- 尚未證實：Zeabur Inc. 是否進入法律上的解散、清算或破產程序。
- 不能直接推論：關站是因資金用盡。官方公告沒有公布現金流、虧損或剩餘資金。
網路上說「Zeabur 倒了」容易理解，但如果要寫成新聞，建議使用「Zeabur 宣布停止營運」會更準確。
Zeabur 停止營運時間表
| 日期 | 事件 |
|---|---|
| 2026 年 10 月 17 日起 | 停止新的專用伺服器與網域購買；開始受理帳戶餘額退款、資安事件損失賠償及遷移協助。 |
| 2026 年 12 月 1 日起 | 專用伺服器停止續費，依個別到期日陸續關閉；共享叢集暫停運行中的服務，但可手動恢復以備份。 |
| 2026 年 12 月 31 日 | 所有專用伺服器到期關閉，所有共享叢集停止服務。 |
| 尚待公告 | 資料刪除日、最晚匯出期限、Zeabur Support 終止日期及完整遷移指南。 |
官方特別提醒，12 月 31 日是平台全部停止的最後日期，不代表每一項服務都能運作到當天。專用伺服器使用者應以自己的到期日為準。
Zeabur 是什麼？它如何從「後端版 Vercel」走到 AI DevOps？
Zeabur 的核心理念，是讓開發者不必理解複雜的雲端設定，也能像使用 Vercel 部署前端一樣，一鍵部署後端、資料庫及開源服務。
創辦人林沅霖曾表示，最初是在浙江大學撰寫畢業論文、同時處理外包專案時，因為厭倦 AWS、GCP、DNS、防火牆、YAML 與 CLI 的繁瑣流程，決定打造「後端版的 Vercel」。MVP 完成後，團隊加入 MiraclePlus 新創加速器。
產品後來不斷擴張：從共享 PaaS、模板一鍵部署，走向專用伺服器、BYOS（Bring Your Own Server）、多雲主機採購，再轉向能用自然語言操作基礎設施的 Zeabur Agent 與 AI Hub。
這條路線讓 Zeabur 從「部署工具」逐漸變成一個橫跨運算、網路、網域、資料庫、憑證與 AI 的 DevOps 控制平台；價值提高的同時，系統複雜度、維運責任及資安風險也同步上升。
Zeabur 發展歷程完整時間線
2022 至 2023 年：開發起點、MVP 與 Zeabur v1
Zeabur 的官方 GitHub 組織建立於 2022 年 6 月，核心公開倉庫則建立於同年 11 月，可作為產品開發已在 2022 年展開的公開痕跡。
創辦人把畢業論文題目轉化為產品，主打降低後端部署門檻，之後加入 MiraclePlus。2023 年 3 月 30 日，Zeabur v1 正式發布，開放計費及一鍵部署市場。
官方關站公告稱平台成立約三年半；需要注意的是，產品與團隊的起點早於美國公司 Zeabur Inc. 的正式登記日期。
2024 年 11 月：突破 1,000 名個人付費用戶
Zeabur 表示，2024 年 11 月 11 日首次突破 1,000 名個人付費用戶。此時產品已不只提供共享平台，也開始往專用主機及自架伺服器管理發展。
2024 至 2025 年：從 PaaS 轉向 BYOS 與多雲管理
Zeabur 推出 Dedicated Server，讓使用者把 AWS、GCP、Linode、Hetzner、DigitalOcean 等伺服器接入平台，或直接透過 Zeabur 購買主機。
這次轉型擴大了市場，但也使平台需要管理更多供應商、主機權限、網路路徑與初始化憑證。
2025 年初：Zeabur Agent 上線
生成式 AI 與 Vibe Coding 興起後，Zeabur 把定位升級為「AI DevOps Engineer」，讓使用者用自然語言部署、分析日誌及管理基礎設施。
2025 年 1 月 14 日：Zeabur Inc. 成立
Zeabur 官網公司資訊列出的 Zeabur Inc. 成立日期為 2025 年 1 月 14 日，登記地址位於美國德拉瓦州。這是法人登記時間，不等於產品首次上線時間。
2025 年 11 月 11 日：完成 200 萬美元種子輪融資
Zeabur 宣布完成 200 萬美元種子輪融資，由 500 Global 領投，Baidu Ventures、AVA Angels 與早期投資人 MiraclePlus 參與。
當時官方公布的數據相當亮眼：個人付費客戶超過 5,000 名、年成長率 500%，月成長率約 10% 至 15%。募資用途包括擴大研發、客服，並提升系統穩定性與安全性。
2025 年 11 月 12 日：AI Hub Beta 上線
Zeabur 在融資公告隔天發布 AI Hub Beta，以單一 API Key 聚合多家 AI 模型，採預付額度及按量計費。這項服務增加了新的營收可能，也增加供應商金鑰、額度退款、濫用防護與資安責任。
2026 年 2 至 4 月：虧本的共享叢集開始退場
Zeabur 在 2 月公布共享叢集退場計畫，3 月停止建立新專案，4 月停止在既有專案建立新服務。官方明言，共享叢集按量價格低於成本、長期由公司補貼；以 AWS 等上游雲端再轉售算力，也欠缺結構性的價格優勢。
這表示退場不只是架構選擇，也是單位經濟問題。團隊在重大資安事件前已知道舊架構需要淘汰；然而，既有服務仍持續運行，舊 API Key、網路路徑與權限設計也沒有在退場期間完全消失。
2026 年 8 月 27 日：第一次重大資安事件
攻擊者先利用共享叢集中一個舊版 NextChat 服務的遠端程式碼執行漏洞，進入叢集內網，再取得快取中的高權限 Zeabur Legacy API Key。
接著，攻擊者從內部管理服務讀到包含 AWS root 金鑰的環境變數，控制東京共享叢集，最後透過既有私有網路與權限過大的資料庫憑證，讀取部分帳號資料及專案環境變數。
外洩內容可能包含第三方 API 金鑰、資料庫密碼、雲端憑證與應用程式簽章金鑰。官方承認，內部憑證保存、權限劃分、網路隔離、監控與告警均有不足。
2026 年 9 月 7 日：公布八月事件報告
Zeabur 停用 Legacy API Key、撤銷相關憑證、移除共享叢集回連核心系統的路徑，並要求受影響使用者更換密碼及金鑰。
但後來的十月報告顯示，八月後的輪替與修補並未涵蓋所有長期憑證。
2026 年 9 月 22 日：AI Hub 永久停止
AI Hub 在 8 月 28 日因應資安事件先行關閉，9 月 22 日確認永久停止、不再重啟。官方表示，早在第二季便已重新評估其維護成本、營運與安全風險；八月事件成為立即停用的契機。未使用額度可退回 Zeabur Credit 或申請現金退款。
2026 年 10 月 14 至 15 日：第二次、影響更大的入侵
攻擊者使用外洩的 Zeabur 內部憑證，入侵九個區域的共享叢集、部分專用伺服器與內部系統。
官方初步報告指出，攻擊者曾在 865 個資料庫服務中執行指令，並以 root 身分登入 101 台由 Zeabur 代管、涉及 92 位使用者的 GCP 專用伺服器。
平台資料庫另有 3,218,965 筆環境變數名稱與值，以及 321,810 筆帳號資料遭讀取，九個區域的共享叢集均受影響。
Zeabur 把根本原因明確歸責於自身：長期有效的管理憑證以明文保存，而且可以從公網使用；叢集管理權杖沒有期限、管理介面對外開放，部分金鑰及內網規則權限過大。
2026 年 10 月 17 日：宣布停止營運
第二次事件後，團隊重新評估繼續營運所需投入，以及能否承擔對客戶服務與資料的責任，最後決定關閉平台。
2026 年 10 月 19 日：公布十月事件初步報告
Zeabur 公開兩條主要攻擊路徑、受影響範圍與已知時間線，並要求所有使用者再次輪替存放於 Zeabur 的密碼及金鑰，即使八月事件後已更換過也不例外。
Zeabur 為什麼停止營運？六個關鍵原因
1. 第二次資安事件是直接導火線
關站公告發布於第二次入侵後數日，官方也直接表示，八月事件後曾長時間討論是否繼續；十月再次遭入侵後，團隊重新評估所需投入與責任，最終決定停下來。
所以，第二次資安事件不是背景雜音，而是促成決策的直接事件。
2. 問題不是單一漏洞，而是系統性的權限與憑證管理缺陷
八月事件雖由使用者服務漏洞起頭，但災情之所以能一路擴大，是因為不同系統之間存在可串聯的高權限路徑：無 scope 的舊 API Key、AWS root 金鑰、可連回正式環境的私有網路，以及超出任務需求的資料庫權限。
十月事件又暴露出長期憑證明文保存、權杖無期限、管理介面對公網開放、舊 GCP 金鑰仍能讀取設定等問題。
這代表 Zeabur 面對的不是「補一個 CVE」就能解決的事件，而是需要重新設計控制面、憑證生命週期、網路邊界、最小權限與稽核系統。
3. 快速開發與多次轉型累積了技術債
Zeabur 官方承認，系統從三年半前的快速開發專案起步，為回應市場不斷調整架構與方向，因而累積越來越高的複雜度及維護難度。
從共享 PaaS 到 Dedicated Server、多雲採購、BYOS、AI Agent、AI Hub、網域與郵件，每增加一項能力，就增加新的權限、供應商整合及故障邊界。
這一點屬於基於官方產品歷程的分析：對小型新創而言，產品廣度成長速度若高於平台治理與資安工程能力，早期為求速度做出的捷徑，最終可能變成難以一次清除的系統性風險。
4. 共享算力低於成本，原始商業模式缺乏結構優勢
Zeabur 早期把部署體驗與共享運算綁在一起，但底層仍使用 AWS 等上游資源。官方在 2026 年承認，共享叢集的按量售價低於成本，差額長期由公司補貼；身為上游雲端的再包裝者，也很難取得價格優勢。
這解釋了 Zeabur 為何先調高 AWS 共享叢集價格，再退出共享算力，改推 BYOS、軟體訂閱與 AI DevOps。問題在於，商業模式轉型尚未完全站穩，舊平台的安全與維運責任卻仍然存在。
5. AI 同時帶來需求，也削弱原有差異化
官方指出，n8n、OpenClaw 與 Vibe Coding 帶來前所未有的部署需求；但 AI 也快速降低部署門檻，讓 Zeabur 必須重新回答「平台還能提供什麼長期價值」。
這是一個典型的 AI 兩面刃：更多人能快速做出應用，確實增加託管需求；但 Coding Agent 也能生成 Dockerfile、設定 VPS、排查部署錯誤，削弱「幫你簡化部署」本身的護城河。
Zeabur 已嘗試用 AI DevOps Agent 回應這個轉變，但當市場定位仍在重塑時，平台又必須投入大量資源處理舊架構與資安問題，形成雙重壓力。
6. 這是資安、商業與團隊承載能力的聯合失敗，不宜簡化成「沒錢」
完成 200 萬美元融資，不代表足以承擔全球基礎設施平台的全部責任。雲端平台需要全天候監控、事件應變、資安工程、客服、法務、賠償及多供應商維運，成本與風險都遠高於一般 SaaS。
但目前沒有公開財務資料證明 Zeabur 因現金耗盡而關站。最合理的表述是：官方承認成長遇到瓶頸；兩次資安事件又大幅提高重建成本、信任成本與持續營運責任，團隊評估後認為無法再承擔。
為什麼拿到 200 萬美元，仍然救不了 Zeabur？
首先，融資是產品擴張資金，不是安全保證。資安成熟度需要制度、人才、架構及長期執行，不能只靠短期增加預算。
其次，Zeabur 的問題牽涉舊憑證、核心權限、跨雲網路、共享叢集與正式環境邊界。若要在不中斷大量客戶服務的前提下全面重建，難度遠高於開發新功能。
第三，第二次事件發生後，公司不只要修系統，還要處理調查、通知、賠償、退款與客戶遷移。即使帳上仍有資金，董事與經營團隊也必須判斷是否有能力恢復可信任的服務。
因此，200 萬美元融資與不到一年後停止營運並不矛盾：前者證明公司一度獲得成長資本，後者反映基礎設施新創的失敗可能來自技術、治理、信任與商業模式同時惡化，而不只是募不到錢。
Zeabur 事件帶給 SaaS 與雲端新創的教訓
安全不能等產品找到 PMF 才補
只要平台代管客戶程式、資料庫與環境變數，資安就已是產品本體，而不是企業化之後才加上的功能。
淘汰舊系統不等於風險已消失
共享叢集與 Legacy API Key 已進入退場，但只要舊服務、金鑰或網路路徑仍存在，攻擊面就仍然存在。
祕密輪替必須有完整資產清冊
八月後的輪替沒有涵蓋十月被利用的所有憑證，說明「換過金鑰」不等於完成治理。企業需要知道每一組憑證在哪裡、由誰使用、權限多大、何時到期，以及能否自動撤銷。
最小權限與網路隔離不能只停留在設計文件
兩次事故都出現權限過大與邊界被串聯的問題。真正安全的架構必須假設某個服務一定會被攻破，並確保攻擊者無法因此橫向移動到整個平台。
成長數字不能取代可靠性
5,000 名付費用戶、500% 年成長及融資新聞都很吸睛，但基礎設施產品最終販售的是信任。對開發平台而言，一次大規模祕密外洩，就可能讓成長成果迅速歸零。
Zeabur 使用者現在該做什麼？
如果你的服務仍在 Zeabur，現在不應只做「下載程式碼」，而要完成一套可驗證的遷移：
- 立刻輪替所有祕密：API Key、資料庫密碼、雲端金鑰、OAuth Secret、JWT Secret、Webhook Token、SSH Key 等，即使八月後換過也要再換。
- 備份資料庫與持久化磁碟：除了匯出檔，也要實際在新環境還原一次。
- 盤點服務相依性：記錄環境變數、網域、DNS、Port、Volume、Cron、Worker、Queue 與第三方整合。
- 提前轉出網域：不要等到最後一週才處理授權碼、DNS 與 TTL。
- 確認專用伺服器到期日：部分伺服器會在 12 月 1 日至 31 日間依到期日提早關閉。
- 檢查第三方異常活動：查看雲端帳單、GitHub、AI API、資料庫及支付服務是否出現陌生登入或用量。
- 申請退款或損失賠償：帳戶餘額退款與資安損失賠償是兩個不同項目，需分別向 Zeabur Support 申請。
- 保留證據：保存帳單、日誌、異常用量、通知信與客服紀錄，以利後續申訴或賠償。
結論：Zeabur 不是突然倒下，而是速度、複雜度與信任同時失衡
Zeabur 的故事很符合 AI 時代新創的縮影：開發速度越來越快，產品可以在短時間內找到市場、募到資金並快速成長；但基礎設施、權限治理及事件應變能力，未必能用同樣速度成熟。
第二次資安事件是關站的導火線，卻不是唯一原因。真正的問題是，快速開發留下的舊架構與高權限路徑尚未清理，產品又持續往多雲與 AI DevOps 擴張；同時，AI 正在改寫部署工具的競爭規則。
所以，Zeabur 的結局不能只用「被駭所以倒了」概括。更完整的答案是：當安全債、技術債、虧本的舊商業模式、產品轉型與成長瓶頸同時到期，一家仍在高速成長的新創，也可能在很短時間內失去繼續營運的條件。
FAQ
Zeabur 什麼時候停止服務？
部分服務自 2026 年 12 月 1 日起陸續停止；所有專用伺服器與共享叢集最晚於 12 月 31 日關閉。專用伺服器可能依個別到期日提早停止。
Zeabur 是破產嗎？
目前官方只宣布停止平台營運，尚未公開宣告破產、清算或資不抵債。把它稱為「停止營運」最準確。
Zeabur 為什麼關站？
官方列出的核心因素包括連續兩起資安事件、舊架構的複雜度與維護困難、共享算力低於成本、成長瓶頸，以及 AI 降低部署門檻後必須重新思考長期價值。
Zeabur 的資料有外洩嗎？
有。官方確認部分專案環境變數、帳號與專案資料遭讀取；十月事件亦涉及共享叢集、部分專用伺服器及平台資料庫。使用者應立即更換曾存放於 Zeabur 的所有密碼與金鑰。
Zeabur 使用者可以退款嗎？
官方已開放申請帳戶餘額退款。若因資安事件蒙受損失，亦可另案申請賠償；兩者是不同申請項目。
主要資料來源
- Zeabur，〈Zeabur 停止營運公告與服務遷移安排〉，2026-10-17：https://zeabur.com/zh-TW/blogs/zeabur-is-shutting-down
- Zeabur，〈Zeabur 2026 年十月資安事件（初步報告）〉，2026-10-19：https://zeabur.com/zh-TW/blogs/october-2026-security-incident
- Zeabur，〈Zeabur 2026 年八月資安事件〉，2026-09-07：https://zeabur.com/zh-TW/blogs/august-2026-security-incident
- Zeabur，〈我們的 200 萬美元天使輪融資〉，2025-11-11：https://zeabur.com/zh-TW/blogs/our-2m-seed-round
- Zeabur，〈認識團隊／公司資訊〉：https://zeabur.com/zh-TW/about
- Zeabur，〈共享叢集退場計畫〉，2026-02-23：https://zeabur.com/zh-TW/changelogs/phasing-out-shared-cluster
- Zeabur，〈AI Hub 停止服務公告與退款說明〉，2026-09-22：https://zeabur.com/zh-TW/changelogs/aihub-shutdown
- Zeabur，〈Zeabur v1 正式發布〉，2023-03-30：https://zeabur.com/zh-TW/changelogs/announcing-zeabur-v1
- GitHub API，Zeabur 官方組織及核心倉庫建立時間：https://api.github.com/orgs/zeabur、https://api.github.com/repos/zeabur/zeabur
本文將官方已證實事實與作者分析分開呈現。若 Zeabur 後續更新資料刪除日、事件調查、法律狀態或遷移方案，應同步更新本文。
