Deno Joins Cloudflare. The Runtime Gets a Year.

On October 9, 2026, Ryan Dahl announced that the entire Deno team is joining Cloudflare. The post thanks contributors, sketches a new distributed programming model, and then drops the operational details into bullet points.

Here they are, without the soft lighting:

• The Deno runtime gets another year of monthly bug fixes and security updates. After that, the team ends its development of the runtime. The code stays open source. Others are welcome to continue it.
• Deno Deploy keeps running for six months, then shuts down. Paying customers get migration support toward Cloudflare Workers.
• JSR keeps operating, with infrastructure moving to Cloudflare.
• rusty_v8 keeps getting support, with work aimed at workerd.

JSR surviving is nice if you publish packages. It does approximately nothing for whoever is supposed to ship the next trustworthy runtime release after the original team stops.

A short history of a loud dinosaur

#

In 2009, Dahl put JavaScript on the server with Node.js. In 2018 he came back with 10 Things I Regret About Node.js and introduced Deno: TypeScript, secure defaults, and a full toolchain in one binary.

The company formed in 2021 with a $4.9 million seed. Deno Deploy followed. Netlify Edge Functions and Supabase Edge Functions ran on Deploy. Slack built its next developer platform on the Deno runtime. In 2022 came a $21 million Series A led by Sequoia.

For a while it looked like server-side JavaScript had a new logo and a happy dinosaur.

Then the commercial products stopped looking like a victory lap. Deno has said Deploy grew from 25 regions to 35 and now runs in 6, driven by cost and by how people actually used the service. Deno KV launched in 2023, and by May 2025 Deno said it would remain in beta. Fresh 2 took long enough that Deno publicly apologized for the wait. Meanwhile the company opened a USPTO fight over Oracle’s JavaScript trademark and launched a GoFundMe for discovery costs.

By spring 2025, outside criticism was loud enough that Dahl wrote Reports of Deno’s Demise Have Been Greatly Exaggerated. The closer was memorable: “We’re not winding down. We’re winding up.” Seventeen months later, the winding-up announcement includes a calendar.

The interesting object in the room

#

What Cloudflare is excited about lives outside a general-purpose runtime. Dahl’s post describes Durable Objects as cheap serverless execution, persistent state, WebSockets, and a high-level JavaScript interface, then points at celld. In August 2026 the team shipped celld as a self-hosted, distributed Durable Objects system: V8, one SQLite database per object, and S3-compatible storage underneath.

Cloudflare’s joint post is unusually blunt about the gap celld fills. Kenton Varda writes that workerd is open source, that Durable Objects there only run as a single instance good enough for local testing, and that Cloudflare’s production routing is a beast no self-hoster wants. They’d wanted a scalable self-hosted version for years. He tried building one the previous spring and, in his words, embarrassingly, it did not work.

Then the Deno team shipped celld. Cloudflare was delighted.

Ryan and Bert Belder are now supposed to merge celld into workerd and make self-hosting a first-class path for Workers and Durable Objects. That’s a real systems bet, and it’s where the engineering attention is going. If your production stack is Deno Deploy or the Deno runtime, you’re reading a different paragraph of the same press release.

“Why reimplement Node? It works.”

#

On Hacker News, answering who decided to stop developing the runtime, Dahl wrote that it was a joint decision he agrees with. He said Deno had been “sucked into the gravity well of node compatibility,” then asked: “Why reimplement Node? It works. Marginal performance or UX or security benefits are not enough.”

He wants powerful new abstractions, and he calls celld an entirely new model for server development. So the team is moving itself to the distributed model. The MIT-licensed runtime stays available. The people who knew how to release it are booking a different set of tickets.

Bun joined Anthropic in December 2025, with an explicit acquisition statement and a promise that the same team keeps maintaining Bun. In June 2026, Cloudflare acquired VoidZero, the company behind Vite. Deno’s announcement says “joining,” so that’s the word I’m using. Whatever the legal paperwork looks like, the outcome for Deno users is already written down: a support year for the runtime, six months for Deploy, and a welcome mat for whoever wants to pick up maintenance.

Node is now the one major server-side JavaScript runtime that hasn’t been folded into somebody’s cloud or AI roadmap. Please resist the urge to make that a LinkedIn carousel.

Two clocks, one inventory

#

If you ship on Deno, you now have two separate projects.

Deploy customers have a hosting shutdown and a promised assist for paying migrations to Workers. Workers runs on V8 isolates with its own request and placement model. Shared JavaScript helps. It won’t auto-port every API assumption, dependency, or ops habit.

Runtime users have a year of announced bug-fix and security releases, then the original team’s exit. The MIT license grants broad rights to use and modify the code. It won’t staff an on-call rotation, triage security reports, or cut releases.

Treat this like any other critical dependency change:

1. Inventory runtime, Deploy, and JSR usage separately.
2. Price migration work against the six-month and one-year clocks.
3. Decide what evidence would make a successor maintainer trustworthy.
4. Put a human name on the decision before the welcome-mat paragraph becomes your release plan.

The code will be fine. Whether anyone keeps shipping it is a separate question, and the people who built it have published their end date. If your product depends on that runtime, write down an owner, a budget, and a date somewhere finance can find it.