Deno Team Joins Cloudflare and Sets Final Deadline for Standalone Runtime

On October 9, 2026, Ryan Dahl, creator of Deno, announced on the project's official blog that the entire Deno team is joining Cloudflare. The news marks the end of Deno's trajectory as an independent company and runtime, a project Dahl created after years of work simplifying server software.

The announcement is not a simple sponsorship deal. It is a team merger, with the team now working inside Cloudflare, integrating the work already being done on Deno Deploy with that of the Workers and Durable Objects teams. Dahl writes that the ambition was always bigger than the runtime: to bring computation, storage, and communication together in a single platform, so that each application doesn't need to build its own infrastructure from scratch.

What Changes, Deadline by Deadline

The post details four concrete changes affecting anyone already using Deno today, whether the standalone runtime, Deno Deploy, or the JSR registry:

• Deno runtime: support maintained for one more year, with monthly releases for bug fixes and security. After that, development by the original team ends. The project remains open source, and Cloudflare says it welcomes anyone who wants to continue its development.
• Deno Deploy: continues operating for six months before being shut down. Paying customers receive migration support to Cloudflare Workers.
• JSR: the package registry continues to work, but its infrastructure will now run on Cloudflare.
• rusty_v8: the Rust binding for the V8 engine used by Deno remains maintained, with work underway to integrate it into workerd, the open-source runtime that powers Cloudflare Workers.

We will support the Deno runtime for another year with monthly releases containing bug fixes and security updates. After that year we will end our development of the Deno runtime. Deno will remain open source, and we welcome others who want to continue its development.

Ryan Dahl, creator of Deno

From Deno to celld: The Logic Behind the Merger

Dahl describes the change as the natural continuation of a progression: Deno, then Deno Deploy, now a new project called celld. Built on Cloudflare Workers' programming model, celld lets developers build distributed applications from the start, with scale built into the programming model itself instead of depending on infrastructure that each team has to build on its own.

The post links this choice directly to AI agents. According to Dahl, Durable Objects, Cloudflare Workers' persistent state mechanism, combines features that are particularly useful for running agent harnesses: cheap serverless execution, persistent state, WebSockets, and a high-level JavaScript interface. That's why, he writes, celld focuses specifically on Durable Objects. Dahl and Kenton Varda, from Cloudflare, published a joint post on the Cloudflare blog with more details on the subject.

What Changes for Those Running Secure TypeScript at the Edge

Part of Deno's historical appeal was always its explicit permissions model (--allow-net, --allow-read, --allow-env), designed to run third-party code with less risk. The announced integration of rusty_v8 into workerd is the point that matters most to anyone who takes edge security seriously: it suggests that part of Deno's bindings and tooling work around V8 will now feed directly into the runtime that already powers Workers, instead of living in two parallel projects.

In practice, this is my own reading, not a Cloudflare promise: teams that currently maintain a deno.json, use imports via jsr:@std/..., or publish packages on JSR don't need to rewrite anything immediately, since the registry remains in place. The real point of attention is different: anyone in production on Deno Deploy has a six-month window to migrate, and anyone running the standalone runtime (on their own server, CI, or CLI) has one year of guaranteed maintenance before having to decide between adopting a community fork or migrating to another stack.

For teams that currently compare Deno with Node.js and Bun purely on runtime security criteria, the announcement changes the calculation: Cloudflare's long-term bet is no longer the "Deno runtime + Deno Deploy" as a closed product, but rather a programming model (celld) running on top of Workers and Durable Objects, with or without Cloudflare as the host.

What Remains Open

Dahl's post does not detail who, in practice, will maintain the community fork of the runtime after the year of official support, nor what happens to enterprise contracts signed with Deno Inc. before the merger. There is also no public detail on pricing or SLA for the migration from Deno Deploy to Cloudflare Workers beyond the promise of "migration support for paying customers." These points should become clearer in the joint technical post by Dahl and Varda on the Cloudflare blog, referenced in the announcement itself.

For anyone deciding on a stack today, the most concrete signal is the timeline: one year for the runtime, six months for Deploy. This gives time to plan a migration without panic, but it also makes clear that Deno, as an independent project, is on a countdown.