Cloudflare 於 2026 年 10 月 9 日宣布收購 Deno，整個 Deno 團隊加入 Cloudflare，並把 deno 執行時與新專案 celld 的開發併入 Workers 與 Durable Objects 團隊。依官方公布安排，Deno 執行時只維持一年，期間提供每月修正與安全更新，期滿後停止開發但保留開源；Deno Deploy 於六個月後關閉，付費客戶可遷移至 Workers；JSR 套件註冊庫繼續運作，其基礎設施一併遷入 Cloudflare。這項消息同時出現在 Deno 官方部落格與 Cloudflare 部落格，由 Ryan Dahl 與 Kenton Varda 分別說明。
Cloudflare 收購 Deno 是什麼一回事？
這是一項收購案，Deno 全體團隊加入 Cloudflare，把執行時與分散式應用框架的開發整併到 Workers 生態，並非單純的技術合作、授權或轉投資安排。
依兩份官方公告，這次並非授權或策略合作，而是 Deno 團隊整批加入 Cloudflare。Cloudflare 部落格把事件歸類為收購，並說明開發方向是把 workerd 與 celld 兩套專案合併；Deno 一方則由創辦人 Ryan Dahl 親自撰文，交代團隊的決定與後續安排。雙方對外口徑一致：目標是讓同一套程式設計模型同時適用於 Cloudflare 網路與開發者自有的基礎設施。
值得留意的是整併的重心並非單純保留一個執行時，而是把分散式應用所需的抽象往上收攏。公告反覆出現的關鍵詞是 Workers、Durable Objects 與 celld，顯示雲端平台與執行時專案的邊界正在被重新劃定。
Deno 執行時與 Deno Deploy 的未來安排如何？
Deno 執行時只維持一年修正與安全更新，期滿停止開發但保留開源；Deno Deploy 六個月後關閉並提供遷移支援；JSR 繼續運作並遷入 Cloudflare。
官方公告列出四項具體安排。第一，Deno 執行時在未來一年內持續收到每月發佈的修正與安全更新，一年後團隊將結束對執行時的開發，但專案維持開源，歡迎其他開發者接手延續。第二，Deno Deploy 在六個月後停止服務，付費客戶可獲得遷移至 Cloudflare Workers 的支援。第三，JSR 套件註冊庫繼續運作，其基礎設施會遷入 Cloudflare。第四，團隊會繼續維護 rusty_v8，並朝著把它整合進 workerd 的方向推進。
這些安排意味著執行時本身走向維護模式，而團隊的研發能量集中到共享平台上。對依賴 Deno 執行時的專案而言，一年之後將不再有官方功能演進，僅剩社群自發的延續。
為何 Deno 團隊選擇加入 Cloudflare？
官方說法是對更強抽象層的追尋：由 Deno 到 Deno Deploy 再到 celld，團隊認定分散式程式設計模型才是可持續方向，因此把開發集中於共享平台。
Ryan Dahl 在公告中回顧，自己長年尋找能簡化系統的抽象。他舉早年 Node.js 發表會的即時通訊示範為例，說明真正困難的問題不在語法，而在分散運算、狀態協調、資料儲存與自動擴展。Deno 改善了撰寫 JavaScript 的體驗，卻沒有改變開發者仍須自行組裝執行時周邊的現實。
他描述，當讀到 Cloudflare 的 Durable Objects 時，解法才變得清晰。每個 Durable Object 如同一個可單獨定址的小型伺服器，附帶自己的關聯式資料庫，JavaScript 執行為單執行緒且易於推論，並原生處理 WebSocket。以每個頻道對應一個 Durable Object 的即時通訊應用為例，資料與連線便自然完成分片，擴展性來自程式設計模型本身，而非額外搭建的基礎設施。
celld 與 Durable Objects 有什麼關係？
celld 是建構於 Workers 程式設計模型上的框架，以 Durable Objects 為核心，讓分散式應用從一開始就具備分片與狀態，開發者不必自行組裝底層設施。
Celld 是 Deno 團隊在 Deno Deploy 之後推出的下一步。團隊指出，營運 Deploy 的過程讓他們看清使用者體驗之下仍藏著大量複雜度，於是嘗試把這一層也簡化。celld 建立在 Cloudflare Workers 的程式設計模型上，讓開發者從專案起始就按分散式應用來設計，並把擴展能力內建於模型，而非留待每個應用自行解決。
Durable Objects 在此扮演樞紐角色。它把低成本無伺服器執行、持久狀態、WebSocket 與高階 JavaScript 介面整合為單一抽象，對需要長時間運作、保存狀態的代理程式特別合用。Ryan Dahl 亦明言，這正是他對 celld 最感興趣的部分，也是整併後的主要探索方向。
這項收購對自架開發者有何意義？
意義在於同一套程式設計模型可同時運行於 Cloudflare 網路與自有基礎設施，開發者不必為自架另行組裝抽象層，原語的可移植性因此提高。
公告反覆強調「自架」這個詞。Cloudflare 的說明指出，團隊加入的目的是大幅簡化自架 Workers 與 Durable Objects 的流程，讓開發者在更多地方使用同一組原語。對不希望完全依賴單一雲端平台的團隊而言，這代表未來的程式設計模型不必在雲端與自架之間二選其一。
技術上的關鍵是把 workerd 與 celld 合併。workerd 是 Workers 的開源執行時，celld 則是建立於其上的分散式框架；兩者整合後，同一份應用邏輯有望在雲端與自有機器上以相近方式運行。配套的 rusty_v8 整合亦朝這個方向推進，讓整個鏈條的開源程度提高。
對現有 Deno 使用者有什麼影響？
現有使用者仍有一年時間取得修正與安全更新，之後須自行承接或轉向替代方案；Deno Deploy 使用者須於六個月內遷移；JSR 使用者受到的影響最小。
短期內既有專案仍可正常運作。一年之內，Deno 執行時會持續收到每月修正與安全更新，執行環境不致立即中斷。真正需要規劃的是時間表之後的空白：官方不再開發新功能，使用者若要長期採用，須評估由社群接手的分支，或轉往其他執行時。
Deno Deploy 的處置較為急迫。服務在六個月後關閉，付費客戶可取得遷移支援，把應用搬往 Cloudflare Workers。相對之下，JSR 使用者受到的直接影響最小，套件註冊庫照常運作，只是底層基礎設施換到 Cloudflare。整體而言，這次變動把選擇權交回使用者手上，遷移成本則取決於專案對 Deno 專有能力的依賴程度。
Deno 專案的規模數據如何？
Deno 儲存庫累積約十萬零八千顆星標與六千四百個分支，以 Rust 撰寫並採用 MIT 授權，是 JavaScript 生態中受注目的現代執行時之一。
上述數據取自 Deno 儲存庫於公告期間的公開資料。十萬顆以上的星標規模，說明專案在開發者社群中具備相當份量，也令這次收購被視為 JavaScript 生態近年最重要的整併之一。
出處連結有哪些？
本文資訊整理自 Deno 官方部落格與 Cloudflare 部落格的收購公告，時間、功能安排與授權描述均以兩份官方公布內容為準。
完整的公告內容、技術脈絡與後續安排，可於下列來源查閱：
常見問題有哪些？
以下整理四個常見疑問，涵蓋收購性質、執行時存續、自架意義與遷移安排，答案以 Deno 與 Cloudflare 的官方公告為準。
這次是收購還是單純合作？
屬於收購。Deno 全體團隊加入 Cloudflare，Cloudflare 部落格亦將事件歸類為收購，而非授權、轉投資或技術合作。
Deno 執行時會否立即消失？
不會。官方會維持一年每月修正與安全更新，期滿後停止開發但保留開源，社群可自行接手延續。
自架開發者可以從中獲得什麼？
同一套程式設計模型有望同時用於 Cloudflare 網路與自有基礎設施，workerd 與 celld 合併後，原語的可移植性提高。
Deno Deploy 使用者該如何準備？
服務將於六個月後關閉，付費客戶可取得遷移至 Cloudflare Workers 的支援，宜及早評估遷移範圍與成本。
總結：Cloudflare 收購 Deno 適合什麼團隊關注？
這則消息最值得關注的是自架 Workers 與 Durable Objects 的團隊，以及正在評估執行時長期風險的開發者；短期使用 Deno 者仍有一年緩衝。
這項收購的意義，在於把執行時與分散式框架兩條路線收束為一條。Cloudflare 取得 Deno 團隊的抽象設計經驗，Deno 團隊則取得把程式設計模型推向自架場景的資源。對社群而言，開源的 Deno 執行時得以延續，但官方研發重心已然轉移。
是否受影響，取決於對 Deno 專有能力的依賴程度。深度綁定 Deno Deploy 的專案須在六個月內規劃遷移；僅使用執行時的專案則有一年緩衝，可觀察社群分支或其他替代方案的成熟度再作決定。對關注自架與可移植性的團隊，這次合併提供的程式設計模型值得持續追蹤。