Cloudflare、Denoを買収 — Deno Deployは6ヶ月で終了、移行先と影響を解説

Cloudflareは2026年10月9日、Denoチーム全員がCloudflareに合流すると発表しました（実質的にDenoの買収・統合です）。結論として、Deno Deployは発表から6ヶ月後（2027年4月頃）に終了し、Denoランタイムは1年間のサポート後に開発終了、JSRは継続されます。Deno Deployを使っている方は、早めに移行先を決める必要があります。

本記事では、Deno公式ブログ（Ryan Dahl氏）とCloudflare公式ブログ（Kenton Varda氏・Ryan Dahl氏）の2つの一次情報をもとに、何が決まり何が未発表なのかを整理し、Deno Deployからの移行先、Denoランタイム利用者の選択肢、移行の最短手順を解説します。なお、発表は2026年10月9日のもので、続報が「今後数ヶ月のうちに」出るとされています。最新情報は必ず公式ブログで確認してください。

今回の発表の骨子は、「Denoチーム全員のCloudflare合流」「Deno Deployの終了」「Denoランタイムの開発終了（1年後）」「workerdのセルフホスト強化」の4点です。DenoはNode.jsの作者でもあるRyan Dahl氏が2018年に立ち上げたランタイムで、2024年のDeno 2でNode/npm互換性を大きく高めていました。今回、ランタイム自体は役目を終える方向になりますが、オープンソース（MITライセンス）のまま残り、他の人が開発を引き継ぐことも歓迎されています。

ポイントは、期限が付いているのは「Deno Deploy（6ヶ月）」と「Denoランタイム（1年）」の2つで、Fresh・Deno KVのような周辺プロダクトは何も明言されていないことです。「明言されていない」は「継続する」ではありません。自社で使っているものは、不明なまま放置せず、代替を前提に計画するのが安全です。

Cloudflareの公式ブログによると、背景にあるのは「Workersのプログラミングモデルを、Cloudflareのネットワークだけでなく自前のインフラでも動かせるようにしたい」という狙いです。Workersは、Cloudflareが公開しているオープンソースのランタイム「workerd」で動いており、本番と同じコードが手元でも動きます。2022年にWorkers for Platformsを提案した際、Shopifyからオープンソースのランタイムを求められたことが、workerd公開のきっかけだったと説明されています。

ただし、workerdのDurable Objectsサポートは現状、単一インスタンスのみです。ローカルでのテストには十分ですが、スケールはしません。そこで鍵になるのがDenoチームが2026年8月に公開した「celld」です。celldはRustのバイナリで、外部依存はオブジェクトストレージだけ。Durable Objectsを中心としたWorkersのプログラミングモデルの上に作られています。Cloudflareは、このcelldの分散アプローチをworkerdに取り込む（workerdとcelldを統合する）計画を示しています。

Durable ObjectsについてはCloudflare Durable Objects解説、Cloudflareだけで構成するスタックの考え方はCloudflareだけで完結するスタックも参考になります。Denoチームは今後、WorkersとDurable Objectsのチームと作業を統合し、このモデルを「Cloudflareのネットワーク上でも、自前のインフラ上でも、サーバーを作るときの標準的な方法」にすることを目標にしています。AIエージェントを大規模に自前インフラで動かしているチーム向けの問い合わせ窓口も、Deno側のブログで案内されています。

- Deno Deployのユーザー: 影響が最も大きい層です。6ヶ月以内に別のホスティングへ移る必要があります。有料顧客はWorkersへの移行支援を受けられます
- Denoランタイム（CLI）のユーザー: 1年間は毎月のバグ修正とセキュリティ更新が続きます。ローカル開発やスクリプト用途なら、すぐに止まるわけではありません
- Freshのユーザー: 公式発表に言及がなく、将来は不明です。新規採用は慎重に、既存利用は移行余地を確認しましょう
- Netlify Edge Functions / Supabase Edge Functions のユーザー: どちらもDenoランタイムをベースにしています。影響や今後の方針は各社から未発表なので、各社の告知を確認してください
- JSRで公開しているパッケージの作者: JSRは運用継続でインフラがCloudflareに移るだけなので、当面は大きな作業は不要です
- Deno KVを使っているユーザー: Deno Deployと密接に結びついた機能のため、データのエクスポート手段を今のうちに確保しておくと安心です（今後の扱いは未発表）

移行先は、コードの互換性とコスト、運用の好みで選びます。Cloudflareが移行支援を明示しているのはWorkersですが、他の選択肢も現実的です。以下の料金・互換性の記述は一般的な目安であり、各社の最新の料金ページで必ず確認してください。

迷ったときの目安は次のとおりです。短期間でとにかく止めたくないならFly.ioやVPSでのDenoセルフホスト、中長期でメンテされる道を選ぶならWorkers、サーバーレスの他社基盤を既に使っているならそのFunctionsへ、という整理になります。ただしDenoセルフホストは「1年後に開発が止まる」ことを前提にした一時避難と捉えるのが安全です。

Deno Deployのアプリは、多くの場合「Deno.serveでFetchハンドラを書いている」ため、Workersへの移植は比較的素直です。Workersもfetchハンドラをexport defaultで公開する形式で、リクエストとレスポンスはWeb標準のRequest/Responseです。次の順序で進めると、作業の手戻りが減ります。

- 1. 棚卸し: Deno.serve、Deno.*のAPI（Deno.env、Deno.readFileなど）、Deno KV、npm:やjsr:のimportを洗い出します
- 2. Deno固有APIをWeb標準に置き換え: 環境変数はenvバインディング、ファイル読み込みはビルド時に埋め込むかR2/KVなどへ、Deno.serveはexport default { fetch }に変更します
- 3. import指定を整理: npm:はパッケージをpackage.jsonに追加して通常のimportに、jsr:はnpm互換の取り込み方法に切り替えます
- 4. Deno KVの代替を決める: Workers KV、D1、Durable Objectsなどから、アクセスパターン（強い整合性が必要か）に合わせて選びます
- 5. wranglerでローカル確認・デプロイ: wrangler devで動作を確認し、wrangler deployで公開します。必要ならnodejs_compatフラグを有効にします
- 6. 切り替え: 新しいURLで検証後、DNSを切り替えます。旧Deno Deployは期限まで残して切り戻し用にします

移植性を高める定石は、フレームワークにHonoを使うことです。HonoはDeno、Workers、Bun、Node.jsのいずれでも動くため、ルーティングとミドルウェアのコードをほぼそのまま持ち越せます。詳しくはHono × Cloudflare Workers実践ガイドを参照してください。Deno固有のAPIを呼ぶ部分だけをアダプタ層に切り出しておけば、今後の移行コストも下がります。

ローカルのスクリプトやCLIツール、開発環境としてDenoを使っている場合、1年間は毎月のバグ修正とセキュリティ更新が受けられるので、慌てて乗り換える必要はありません。ただし、1年後の開発終了を見据えて、次の3つから方針を決めておくとよいでしょう。

- Denoのまま使い続ける: MITライセンスのオープンソースで、有志による継続開発が歓迎されると公式に述べられています。コミュニティフォークが現れる可能性はありますが、現時点では未発表です
- Node.jsへ移る: 近年のNode.jsはTypeScriptの型ストリッピングに対応しており、.tsファイルを直接実行できる場面が増えています。npm資産もそのまま使えます
- Bunへ移る: TypeScript実行とnpm互換が組み込まれており、移行の心理的ハードルは低めです

Denoの特徴だった「デフォルトで権限を絞る」モデルは、Node.jsやBunにそのまま同じ形で置き換わるものではありません。信頼できないコードを動かす用途がある場合は、移行時にコンテナ化やOSレベルの隔離で補う必要があります。

- 正確な終了日は未記載: Deno Deployの終了は「6ヶ月後」とされていますが、具体的な日付は発表されていません。2027年4月頃を目安に、余裕を持って計画してください
- FreshとDeno KVの扱いは不明: 公式発表に言及がありません。依存している場合は、代替を前提にした設計に切り替えるのが安全です
- Netlify / Supabase のEdge Functionsは各社の告知待ち: Denoランタイムの終了が自社基盤にどう影響するか、現時点で各社からの発表はありません
- Denoランタイムの継続はコミュニティ次第: 公式サポートは1年間です。その後のフォークや引き継ぎは未発表です
- 続報が「今後数ヶ月」で出る予定: workerdとcelldの統合、セルフホストの具体的な仕様などは、これから明らかになります
- 料金や移行支援の条件は個別確認: 有料顧客向けの移行支援の詳細は、契約している方がDenoの窓口に確認する必要があります

今回の発表は、「Denoを買収して終わり」ではなく、Workersのプログラミングモデルをクラウドでも自前環境でも動く標準にするというCloudflareの方向性の表明でもあります。一方で利用者にとっては、Deno Deployが6ヶ月で終わる、Denoランタイムは1年で開発終了という具体的な期限が付いたことが最も大きな変化です。Deno Deployを使っているなら、まず棚卸しをして、Honoのような移植性の高い構成に寄せ、Workersか他のホスティングへ移るのが現実的です。Denoランタイム利用者は、1年の猶予の中で、Node.jsやBunへの移行を検討しておきましょう。続報は今後数ヶ月で出る予定なので、公式ブログをこまめに確認してください。