Deno 併入 Cloudflare：八年 Runtime 願景的轉向與退場

2026 年 10 月 9 日，Deno 創辦人 Ryan Dahl 與 Cloudflare 聯合發布公告，宣布 Deno 團隊全體加入 Cloudflare。這筆交易將 Deno 團隊併入 Cloudflare Workers 組織，宣告了這家曾獲得 Sequoia 等機構投資 $2,600 萬美元的開源商業實體正式劃下句點。

隨之而來的，是旗下產品線的全面重組：核心專案 Deno Runtime 進入為期一年的維護倒數，託管平台 Deno Deploy 則排定半年後關閉。

這場收購反映了 Cloudflare 長年難以突破的邊緣自架瓶頸、新專案 celld 在分散式狀態上的架構突破，以及開發工具生態在 AI 浪潮下全面被雲端與算力巨頭整編的深層趨勢。

五大資產去向與下游 PaaS 的三種命運

官方公告劃定了 Deno 五項核心資產的去向：

在這份清單中，最令人震撼的是 Deno Runtime：官方生命週期只剩一年。Dahl 在公告中寫道：

“support the Deno runtime for another year with monthly releases containing bug fixes and security updates. After that year we will end our development of the Deno runtime.”

相較於 Node.js 擁有中立的 OpenJS Foundation 託管、Bun 被 Anthropic 納入旗下，Deno 目前沒有任何基金會或企業承諾接手維護，一年後將完全取決於開源社群自發的力量。

託管平台 Deno Deploy 的謝幕同樣徹底。這已經是該產品線兩年內的第二次退場——2026 年 7 月舊版 Deploy Classic 才剛停止服務，如今新版 Deploy 亦將於 6 個月後正式關閉。

下游 PaaS 的架構依賴風險

Deno 的退場，對依賴其生態的下游雲端平台帶來了截然不同的衝擊。架構依賴的層次不同，風險也不同：

• 平台層依賴（Netlify Edge Functions）：Netlify 自 2022 年起將 Edge Functions 的執行環境整個外包給 Deno（Deno Subhosting）。不過它已趕在退場公告之前，於 2026 年 9 月底宣布改在自家邊緣網路上的 Firecracker MicroVM 執行函式，提前拆除了這顆平台層依賴的未爆彈。
• 函式庫層依賴（Supabase Edge Functions）：Supabase 基於 deno_core 自建開源 Edge Runtime。雖然官方承諾持續支援底層的 rusty_v8，但公告並未點名上層的 deno_core。Supabase 短期內仍可自行維護 Runtime，但長期已失去上游核心團隊的演進支援。
• 自研標準層（Vercel Edge Functions）：Vercel 當初選擇以 V8 Isolate 打造自有 Edge Runtime，並遵循 WinterTC（前身 WinterCG）跨平台 Web 標準，在此次震盪中完全不受波及。

唯一在這次交易中獲得強大生機的是 JSR（JavaScript Registry）。JSR 原生支援 TypeScript 發布、文件解析與跨 Runtime 取用，這項試圖超越 npm 傳統分發模式的標準化實驗，獲得了 Cloudflare 龐大基礎設施的長期支撐。

交易核心：celld 如何解開 Durable Objects 的自架死結

Cloudflare 買下 Deno 團隊的核心原因，在於一項剛發布不久的關鍵技術資產：celld。

長期以來，Cloudflare Workers 的開源執行環境 workerd 存在一個關鍵缺口：它對 Durable Objects（DO） 僅支援單節點本地測試，無法在多節點間水平擴充。

Cloudflare Workers 技術負責人 Kenton Varda 坦承，Cloudflare 內部驅動 DO 的路由架構「是一頭巨獸（a beast）」——為處理數百個據點而設計，並牽動多個外部服務，並不適合給使用者在私有伺服器上自架。Varda 今年春天曾嘗試重寫一套簡化版分散式路由，但以失敗告終。

Deno 於 2026 年 8 月 5 日發布的 celld（v0.1.0），正好填補了這個架構空缺。

 +-------------------------------------------------------+
 |                     celld Daemon                      |
 |                                                       |
 |  +--------------------+       +--------------------+  |
 |  |  V8 Runtime (JS)   | <---> |    SQLite State    |  |
 |  +--------------------+       +--------------------+  |
 |            ^                                          |
 |            | Lease & LTX Sync                         |
 |            v                                          |
 |  +-------------------------------------------------+  |
 |  |  Shared Object Storage (S3 / GCS / Azure Blob)  |  |
 |  +-------------------------------------------------+  |
 +-------------------------------------------------------+

celld 的核心抽象是 「Cell」——一個帶有獨立 SQLite 資料庫、可透過名稱唯一定址的輕量伺服器，本質上實作了 Stateful Serverless 與 Actor 模型。它的技術突破在於完全不需要共識服務（Consensus-free）：

• 捨棄 Raft 與成員協定：傳統分散式系統要保證同名物件全叢集僅有一個活動實例，必須仰賴 Paxos、Raft 或複雜的 Leader 選舉。celld 捨棄了共識層，改以「條件寫入（Conditional Write）」向純物件儲存桶（S3/GCS/Azure Blob）取得 Cell 的租約（Lease）。
• 極簡維運拓撲：整個叢集只需要 N 個可替換的 celld 節點加上一個共用儲存桶，免去維運分散式協調中介軟體的沉重負擔。
• 交易級複製（LTX）：以 LTX（Lite Transaction）複製日誌格式捕捉狀態變更。單節點寫入需等待物件儲存桶寫入確認（延遲約 90ms）；雙節點以上時，寫入只要已保存到另一個節點的磁碟即視為持久（約 25ms），物件儲存桶的上傳在其後完成。
• 明確劃定邊界：celld 在設計之初即劃清範疇，明確將 Cloudflare 全球網路、GPU 算力與瀏覽器 Farm 列為超出範圍（Out of Scope），專注解決自架伺服器上的狀態與路由問題。

正如 Varda 在聯合公告中的感嘆，celld 正是 Cloudflare 想做卻未能完成的最後一塊拼圖。celld 的程式碼與設計理念將併回 workerd。

由 Dahl 與 Belder 領導的新團隊，任務是讓企業在自有基礎設施上，自架水平擴充的 Workers 與 Durable Objects 成為官方一級支援；正式發布時程為公告所稱的「coming months」。

雙重策略：逃生門商業學與 AI Agent 載體

這起收購背後，反映了 Cloudflare 在商業策略與技術趨勢上的雙重佈局。

1. 逃生門策略（Escape Hatch）

早在 2022 年 Cloudflare 向 Shopify 推廣 Workers for Platforms 時，Shopify 便明確表態：「Runtime 若不開源就不採用」。

雖然 Cloudflare 隨後開源了 workerd，但其分散式 Durable Objects 依然依賴閉源的內部系統，企業始終無法真正將整套架構搬回私有環境。celld 補上之後，這條退路才延伸到 Durable Objects 的狀態層。不想等整合完成的人，今天已可自架 celld 或 workerd。

這種策略有助於化解大型企業對單一雲廠商的鎖定疑慮。正如 Varda 所言，給予客戶逃生門反而是筆好生意，因為 Cloudflare 的競爭優勢來自全球網路的成本結構與效能，而非強行扣留使用者程式碼。

2. AI Agent 基礎設施

一個具備獨立記憶、工具呼叫與會話能力的 AI Agent，在架構上天然映射為一個 Durable Object：

• 獨立狀態隔離：每個 Agent 的對話上下文、記憶與長期狀態直接存入專屬的 SQLite 資料庫。
• 長連線雙向通訊：透過 WebSocket 維持即時串流與人機互動，免去重複建立連線的負擔。
• 無伺服器成本彈性：Agent 閒置時自動休眠、不佔用常駐運算資源，喚醒時能瞬間載入狀態。

Ryan Dahl 在公告中指出，Durable Objects 匯集了對開發 agent 特別有用的一組能力：低成本無伺服器執行、持久狀態、WebSocket 長連線，以及高階 JavaScript 介面。吸收 Deno 團隊與 celld 後，Cloudflare 有望在公有邊緣網路與私有部署兩端，都提供這類輕量狀態載體。

生態重組：通用開發工具全面被 AI 基礎設施收編

回顧過去半年的開發工具版圖，三筆收購勾勒出一場板塊重組：

半年之內，通用開發工具公司全數被 AI 基礎設施邏輯收編。

這三起收購呈現的共同點是：純開發者工具難以單靠自身建立永續的商業模式。它們都仍在營運，但主人與目的已經更換——Bun 服務 Claude Code、Astral 服務 Codex、Deno 的狀態模型服務 agent 載體。

在這波收編潮過後，Node.js 成為三大主流 JavaScript Runtime 中唯一由非營利基金會（OpenJS Foundation）中立治理的專案。

過去五年，Node.js 迅速吸收了原生 fetch、內建 Test Runner 以及原生 TypeScript 型別剝離（Type Stripping）等現代特性。這些改變常被歸因於 Deno 與 Bun 的外部壓力，但 Node 的改進有多重動因，Deno 只是催化劑之一。

當 Node.js 逐步補足這些功能，龐大的 npm 生態網路效應便成為它穩固的競爭優勢。隨著 Deno 官方開發進入一年倒數，這個外部催化劑少了一個。

Deno 的八年：哪些失敗了，哪些留下來？

商業與 Runtime 退場，技術成果延續

要客觀評價 Deno 的成敗，必須區分不同的面向：

• 作為商業實體（失敗）：累計獲投 $2,600 萬美元，但作為唯一核心營收引擎的 Deno Deploy 兩度退場，無法在重資產的雲端託管市場中自立。
• 作為通用 Runtime（失敗）：未能達成「取代 Node.js」的初始目標。在生態引力與 npm 相容性的拉扯下，市占率長年處於邊緣，最終由官方宣告終止開發。
• 作為生態催化劑（成功）：作為催化劑之一，參與促使 Node.js 加速現代化，推動了 WinterTC Web API 跨平台互通標準，並留下了 JSR 註冊表。
• 作為技術資產（成功）：在 V8 Isolate 與邊緣狀態協同的探索成果（rusty_v8、celld），其價值獲得 Cloudflare 以收購行動本身確認。

取代 Node.js 為何走不通？

Deno 這段軌跡，留給軟體生態三條架構教訓：

1. 生態引力的兩難：Deno 早期為追求純粹性，捨棄了 package.json 與 node_modules、強推 URL Import，實質上將自己割裂於龐大的 npm 生態之外。後期為了生存回頭支援 npm，卻也同時消解了開發者大費周章切換 Runtime 的核心動機。
2. 兩面夾擊的市場定位：Node.js 快速補齊了開發者最有感的功能（Fetch、TS 直接執行），大幅提高了遷移的機會成本；而效能敏感型的開發者則被主打 Drop-in 替代的 Bun 吸引，使 Deno 處境尷尬。
3. 雲端託管的規模經濟壁壘：邊緣託管平台的基礎設施固定成本極高（全球 Anycast 節點、DDoS 防護、企業合規），初創公司難以對抗 Cloudflare、AWS 與 Vercel 的規模經濟。

2018 年，Ryan Dahl 在 JSConf 發表《我對 Node.js 感到遺憾的十件事》，立志打造更純粹、更安全的執行環境。

八年過去，從最初的架構革命，到 2024 年提出《JavaScript Containers》——主張以輕量 V8 Isolate 與 Web 標準取代笨重 Linux 容器的願景，Dahl 最終選擇將這個程式模型放進掌控全球網路流量的 Cloudflare 帝國。

這並非單純的潰敗；系統架構師為自己的理想，找到了一個規模更大、更具現實承載力的宿主。