Bye bye, Deno!

it’s so over

Ladies and gentlemen, Deno is over.

Not “over” like a framework whose GitHub went quiet and everyone slowly pretends they never starred it. Over like there’s a date on it. Over like the hospice nurse has already been briefed.

On October 9, 2026, the entire Deno team announced they’re joining Cloudflare. Big news. Exciting. Handshakes. Rocket emojis. And if you only read the Cloudflare blog post, that’s the whole story: two great teams, one shared vision, the future of the web, etc.

But if you go to the Deno blog and scroll down past the part where everyone is thanked for their service, you find the bullet points. And the bullet points are where the bodies are buried.

The fine print

Here’s what actually happens:

• The Deno runtime gets one more year of monthly releases. Bug fixes and security patches only. After that, the Deno team stops developing it. It stays open source, and anyone who wants to keep it alive is “welcome” to. That’s the software equivalent of leaving a puppy on a doorstep with a note.
• Deno Deploy gets six months. Then it shuts down. Paying customers get migration help — to Cloudflare Workers, naturally.
• JSR, the package registry, survives. Its infrastructure moves to Cloudflare.
• rusty_v8 stays supported, and they’re working on folding it into workerd.

So to recap: the registry lives, the V8 bindings live, the hosting dies in six months, and the actual thing called Deno — the runtime, the reason any of us knew this company existed — gets twelve months of life support.

The Cloudflare post, meanwhile, handles the runtime situation by politely linking to the Deno post. Which is a very corporate way of saying “we’ll let him tell you.”

So what did Cloudflare actually buy?

Not the runtime. Obviously. You don’t buy a car and immediately announce a 12-month countdown to scrapping it.

They bought celld.

You’ve probably never heard of celld. That’s fine. Deno shipped it in August, and it’s the most important thing they’ve made since Deno itself. To understand why, you need about thirty seconds of Durable Objects.

Durable Objects in thirty seconds

A Durable Object is basically a tiny server with its own SQLite database, and you talk to it by name. Single-threaded, handles WebSockets, synchronous access to its own database. Easy to reason about.

The classic example is a chat app: one Durable Object per channel. Every channel is its own little server with its own data. More channels? More objects, spread across more machines. You didn’t write a scaling layer. You didn’t configure a sharding strategy. The scaling is the programming model.

And this is where it gets weirdly emotional, because this is the thing Ryan Dahl has wanted for over fifteen years.

The very first Node.js demo — Berlin, a warehouse, live audience — was a chat server. About 500 lines. And Ryan says it always bothered him that it ran on one server, on one thread. It could handle a lot of connections, but scaling it for real meant spreading channels across machines, storing history, managing users. All the stuff the demo conveniently skipped.

Durable Objects were the answer he’d been looking for. There was just one problem.

The thing Cloudflare couldn’t build

Durable Objects only really worked on Cloudflare.

Yes, workerd, the Workers runtime, is open source. It’s literally the same code Cloudflare runs in production. But its Durable Objects support is single-instance. Great for local testing. Useless for actually scaling anything.

And Cloudflare knew. Kenton Varda, who co-wrote the Cloudflare half of the announcement, admits there have been TODO comments about this since the original release. Their production Durable Objects routing is a monster designed for hundreds of data centers and a team of SREs — not something you’d want to run in your basement. Kenton even tried to build the self-hostable version himself last spring. In his own words: “embarrassingly, it didn’t work.”

Respect for saying that in a public blog post, honestly.

Then Deno shows up with celld. One Rust binary. One object storage bucket as its only external dependency. Your existing Workers app, Durable Objects and all, running and scaling on your own machines.

Deno built the thing Cloudflare couldn’t. So Cloudflare did the only reasonable thing.

They brought them in.

Now Ryan Dahl and Bert Belder lead a new effort to merge celld into workerd and make self-hosting Workers a first-class option. Kenton says he’ll personally use it to host Cloudflare OS at home, which is the most engineer sentence ever written.

“But that’s just lock-in with extra steps”

Here’s the funny part. Why would Cloudflare want it to be easier to leave Cloudflare?

The internet has a popular theory: Workers is deliberately weird so you can’t move your app anywhere else. Under that theory, celld should be a threat. An open-source, scalable Workers clone? That’s the escape hatch!

Kenton’s answer is that the theory is backwards. Back in 2022, when Cloudflare pitched Workers for Platforms to Shopify, Shopify basically said: open-source the runtime or we’re not building on you. So they open-sourced workerd. Some customers have actually used it to leave. And Cloudflare is fine with that, because the escape hatch is what got the big customers to sign in the first place.

Is that also very convenient PR? Sure. But it’s the kind of convenient PR that’s backed by code you can actually download, so I’ll allow it.

And yes, because it’s 2026, there’s an AI angle. Ryan points out that Durable Objects are a great fit for agent harnesses: cheap serverless execution, persistent state, WebSockets, nice JS interface. That’s why celld focuses on them. Of course it is. Everything is an agent harness now. My toaster is an agent harness.

Who’s holding the bag

If you built on Deno, you now have a one-year clock. Congratulations.

And it’s not just people running deno run on a VPS. Supabase Edge Functions run on a Deno-based runtime. Netlify Edge Functions too. Neither has said much yet, but somewhere in both companies there’s a Slack channel that got very busy on Friday afternoon.

And Deno Deploy users? Six months. That’s not a migration window, that’s a sprint planning nightmare.

The bigger picture

This is the season of JavaScript tooling getting absorbed by bigger companies. Bun joined Anthropic last December. Now Deno joins Cloudflare.

The difference? Bun keeps going. Deno doesn’t.

And that stings a little, because Deno was good. It questioned everything Node got wrong — permissions, modules, tooling, TypeScript as a first-class citizen. It forced Node to get better. It was the runtime that said “what if we just… did it properly this time,” and then actually did.

It just turned out the runtime was never the destination. Ryan said it himself: Deno, then Deno Deploy, then celld. Each step was him trying to simplify the layer underneath. Deno was a chapter, not the book.

The verdict

For the Workers model? This is a big win. Self-hosted, scalable Durable Objects with Cloudflare officially behind them takes most of the lock-in argument off the table. If you’ve been avoiding Workers because you’re scared of being trapped, that excuse is about to expire.

For Deno? It’s a one-year clock on a runtime people genuinely liked. Somebody might fork it. Somebody might keep the lights on. But the team that built it has moved on to the thing they apparently wanted to build all along.

Deno didn’t lose. It graduated. And then it got left at the old school with a note saying “open source, welcome to continue development.”

Rest easy, little dinosaur. You were too good for us.

Sources: Deno is joining Cloudflare — Deno blog · Deno is joining Cloudflare — Cloudflare blog