Deno Is Joining Cloudflare: What Ends, What Stays, and How to Plan Your Migration

On 9 October 2026, Ryan Dahl announced that the entire Deno team is joining Cloudflare. The headline is a company story, but the details are an engineering problem for anyone running Deno in production: the Deno runtime now has roughly a year of maintenance left from its original team, and Deno Deploy has about six months before it shuts down. This post sets out what was actually announced, what was not, and a practical way to decide where your Deno code should go next.

What was announced

There are two official posts: one on the Deno blog by Ryan Dahl, and a joint post on the Cloudflare blog by Kenton Varda, a principal engineer on Cloudflare Workers, and Dahl. Neither post uses the word “acquisition” in its text, but The New Stack and others reported it as Cloudflare acquiring Deno; financial terms were not disclosed.

The concrete commitments from the Deno announcement are:

• Deno runtime: “We will support the Deno runtime for another year with monthly releases containing bug fixes and security updates.” After that, the team will end its development of the runtime. Deno stays open source (it is MIT-licensed), and the post says others are welcome to continue its development.
• Deno Deploy: “Deno Deploy will continue operating for six months before shutting down.” Paying customers moving to Cloudflare Workers will get migration support.
• JSR: the JavaScript registry continues operating, with its infrastructure moving to Cloudflare.
• rusty_v8: the Rust bindings to V8, which many other projects depend on, will continue to be supported, with work toward integrating them into workerd.

Neither post gives an exact end date for the runtime or for Deploy. Counting from the announcement, Deploy’s six months run out around April 2027 and the runtime’s year around October 2027, but treat those as estimates until Deno publishes firm dates.

Why Cloudflare wanted the Deno team

The key piece is celld, a project the Deno team released in August 2026. According to the Cloudflare post, celld is a Rust binary whose only external dependency is object storage, built to be compatible with the Workers and Durable Objects programming model. That matters because Cloudflare’s own open-source runtime, workerd, supports Durable Objects only as a single instance. That is fine for local testing, but the Cloudflare post calls it the main gap in workerd’s production readiness for self-hosting.

The plan is to merge code and ideas from celld into workerd, with Dahl and Deno co-founder Bert Belder leading an effort to make workerd self-hosting “a first-class supported way to build and run apps”. Cloudflare says more announcements will come “in the coming months”. In his own post, Dahl explains that Node.js compatibility became a large part of Deno’s work because users wanted Deno’s improvements while still plugging into the existing JavaScript ecosystem, and he presents the path from Deno to Deno Deploy to celld as the reason the move makes sense.

It is the second runtime company deal in under a year: The New Stack notes it follows Anthropic’s purchase of Bun in December 2025. The difference is that Bun is still being developed, while Deno’s runtime development is scheduled to end.

What was not mentioned

Several things Deno users depend on are not covered in either announcement, so their future is unconfirmed:

• Deno KV (the hosted key-value store on Deploy)
• Fresh, Deno’s web framework
• Deno Subhosting, used by platforms that run their own customers’ code on Deno’s infrastructure

If you use any of these on Deploy, assume they are covered by the same six-month window unless Deno tells you otherwise, and ask your Deno contact directly. For KV specifically, it helps to know that the KV backend was open-sourced in November 2023 as denokv, an MIT-licensed, SQLite-backed server you can run yourself, so there is at least one path that does not require rewriting data access code straight away.

Who needs to act, and how soon

A runtime receiving monthly security fixes for a year is not an emergency. The real risk is the long tail after that: dependencies that stop testing against Deno, and security issues with nobody officially responsible for patching them.

The three realistic destinations

Cloudflare Workers

This is the path Deno itself is pointing paying Deploy customers toward, and the programming model is close to what Deno Deploy apps already use: a function that receives a web-standard Request and returns a Response. A typical Deploy app looks like this:

// Deno Deploy
Deno.serve((req) => {
  const name = new URL(req.url).searchParams.get("name") ?? "world";
  return new Response(`Hello, ${name}`);
});

The Workers equivalent exports a fetch handler instead:

// Cloudflare Workers
export default {
  async fetch(req, env, ctx) {
    const name = new URL(req.url).searchParams.get("name") ?? "world";
    return new Response(`Hello, ${name}`);
  },
};

The differences show up around the edges. Environment variables and bindings arrive on the env argument rather than through Deno.env.get(). Deno KV has no direct equivalent; you would move to Workers KV, Durable Objects or D1 depending on how you used it. Node.js compatibility in Workers is now on by default for projects with a compatibility_date of 2026-08-04 or later; older dates need the nodejs_compat flag. Some Node modules, such as node:child_process, exist only as non-functional stubs, so check Cloudflare’s compatibility list for anything your dependencies import.

Node.js

For self-hosted servers and CLI tools, Node.js is the most conservative destination, and it has closed much of the gap that originally made Deno attractive. Node runs TypeScript files directly: type stripping is enabled by default since v22.18.0 and is marked stable in current releases. It only handles erasable syntax, so enum, runtime namespaces, parameter properties and decorators are not supported, and imports must include the .ts extension, which Deno code usually already does.

Node also has a permission model. A Deno command like this:

deno run --allow-net --allow-read=./data main.ts

maps roughly to:

node --permission --allow-net --allow-fs-read=./data main.ts

The mapping is not exact. Node’s --allow-net, added in v25.0.0, is still marked as in active development, and it is all-or-nothing rather than allowing specific hosts as Deno does. Node’s documentation also describes the permission model as a safeguard for trusted code rather than a security boundary against malicious code, so do not treat it as a sandbox.

The common API swaps are mechanical:

Bun

Bun is the third option. It runs TypeScript natively, is largely Node-compatible, and is still under active development, with Anthropic having committed to keeping it open source. If you liked Deno’s all-in-one tooling (runtime, test runner, bundler and package manager in one binary), Bun is the closest in spirit. The trade-off is that you are again betting on a single company-backed runtime, which is precisely the situation Deno users are now in.

Make the code portable before you move it

The cheapest migration is the one where you change hosting without rewriting your app. Two habits get you most of the way.

First, write your HTTP layer against a framework that runs everywhere. Hono, for example, runs on Deno, Node.js, Bun and Workers with the same application code. Only the entry point changes:

// app.ts - shared by every runtime
import { Hono } from "hono";

export const app = new Hono();
app.get("/", (c) => c.text("Hello"));
app.get("/health", (c) => c.json({ ok: true }));

// Deno entry point
import { app } from "./app.ts";
Deno.serve(app.fetch);

// Node.js entry point
import { serve } from "@hono/node-server";
import { app } from "./app.ts";
serve(app);

// Cloudflare Workers entry point
import { app } from "./app.ts";
export default app;

That means you can keep running on Deno today while the same codebase passes tests on Node or deploys to Workers.

Second, follow Deno’s own portability advice. Deno’s documentation recommends importing built-ins with the node: prefix (for example node:path), keeping dependencies in package.json rather than in deno.json import maps or inline npm: specifiers, and using import.meta.dirname instead of __dirname. All of these work in Deno today and survive a move to Node or Bun unchanged. Then search your codebase for Deno.: every hit is a small piece of work to wrap or replace, and the count gives you a realistic estimate of the migration.

A suggested plan

1. This month: list every Deno service, where it runs, and whether it uses KV, cron, queues, Fresh or Subhosting.
2. Next: for anything on Deno Deploy, pick a destination and deploy a test copy. Do the data export rehearsal early, not in the last week.
3. Then: refactor shared code toward node: imports, package.json dependencies and a portable HTTP layer, so it runs on both Deno and your target.
4. During 2027: move self-hosted Deno services before the year of patches ends, or adopt a community fork only once it has visible maintainers and regular releases.

My recommendation for most teams is to treat Deploy-hosted apps as urgent and everything else as a planned 2027 project. The Deno runtime will not stop working on the day support ends, but software without an active maintainer gets riskier every month, and a calm migration is much cheaper than a rushed one.

Sources: Deno blog: Deno is joining Cloudflare, Cloudflare blog: The Deno team is joining Cloudflare, The New Stack, Simon Willison, Deno blog: self-hosted Deno KV, Cloudflare Workers Node.js compatibility docs, Node.js TypeScript docs, Node.js permissions docs, Node.js CLI docs, Deno Node.js compatibility docs, Hono docs

Related reading

• TypeScript 7 Is Here: What the Go Compiler Changes, and What Angular Developers Should Do Now
• The Three Pillars of JavaScript Bloat, and How to Trim Your Dependencies
• How Docker Changed Software Development: A Short History of Containers (2013–2026)