⏱️ Reading time: 10 min
Cloudflare is bringing on the creators of one of the most influential JavaScript runtimes of the last decade. Ryan Dahl, co-creator of Node.js and founder of Deno, announced on October 9, 2026 that the entire Deno team is joining Cloudflare to build Cloudflare celld, a platform designed so that scaling a distributed application doesn’t depend on infrastructure hand built by each team.
📑 En este artículo
The announcement comes with concrete dates: Deno Deploy shuts down in six months, and Cloudflare’s own development of the Deno runtime ends in a year. JSR, Deno’s package registry, remains active but changes infrastructure.
TL;DR
- Cloudflare is bringing on the entire Deno team to build Cloudflare celld, its new distributed platform.
- Deno Deploy will operate for six more months and then shut down; paying customers will migrate to Cloudflare Workers.
- The Deno runtime gets a year of monthly patches before Cloudflare stops its own development.
- JSR remains active, but its infrastructure moves to Cloudflare’s servers.
- rusty_v8 will continue to be maintained and will be integrated into Cloudflare Workers’ workerd runtime.
What Is Cloudflare celld
Cloudflare celld is the distributed platform the Deno team is building inside Cloudflare on top of the Workers programming model, combining serverless execution, persistent state, and real time communication so that scaling an application doesn’t depend on extra infrastructure built by each team.
The bet grows out of an idea Dahl has repeated since his post JavaScript Containers: compute, storage, and communication should work together without every application building its own infrastructure. At Cloudflare, that idea rests on the Workers and Durable Objects teams, which now add the Deno engineers to their ranks.
What Happened
Dahl published the announcement on Deno’s official blog under the title “Deno is joining Cloudflare”. In the post, he thanks everyone who contributed code, built businesses on top of Deno, and reported bugs over the last eight years, since he first presented the project in 2018.
The letter details four concrete changes. The Deno runtime will get monthly releases with security patches for a year; after that, Cloudflare stops developing it and the project stays open for the community to carry forward. Deno Deploy, the edge hosting service, will operate for six more months before shutting down, with migration support for paying customers moving to Cloudflare Workers.
JSR, the package registry Deno launched as an alternative to npm, keeps running, but its infrastructure moves to Cloudflare’s servers. And rusty_v8, the Rust bindings over the V8 engine that Deno uses internally, will continue to be maintained with the goal of integrating them into Cloudflare Workers’ open source workerd runtime.
| Product | What Happens | Timeline | Who It Affects |
|---|---|---|---|
| Deno runtime | Monthly patches, then end of official development | 1 year | Those running Deno in production |
| Deno Deploy | Stops operating; assisted migration to Cloudflare Workers | 6 months | Paying Deploy customers |
| JSR | Remains active; infrastructure moves to Cloudflare | No shutdown date | JSR package publishers |
| rusty_v8 | Ongoing maintenance and future integration into workerd | No fixed date | Teams embedding V8 via Rust |
Context and History
Dahl didn’t arrive at this by chance. He created Node.js in 2009 and handed it over to the community years later. In 2018, he took the stage at JSConf EU to give the talk 10 Things I Regret About Node.js, where he pointed out security and design flaws in the very project he had written. Deno was born that same night as a response: a runtime with explicit permissions, native TypeScript support, and URL based module imports instead of a centralized package manager.
📌 Note: The year of support isn’t indefinite: Cloudflare confirms monthly security patches, but doesn’t promise new features for the Deno runtime during that time.
Deno 1.0 shipped in 2020. The company behind it, also called Deno, later added Deno Deploy to host those applications at the edge and JSR as a package registry meant to fix npm’s design mistakes, like the lack of types and ambiguous version resolution. Deno 2.0 later took a pragmatic turn: it added near complete compatibility with Node.js and npm, something Dahl had initially avoided as a matter of ideology.
The progression Dahl describes in his announcement goes from Deno to Deno Deploy and from there to Cloudflare celld. Each step simplified a layer: the runtime solved what code runs, Deploy solved where it runs, and the celld platform aims to solve how it scales without the developer having to assemble that infrastructure piece by piece.
Technical Details
The mechanism behind Cloudflare Workers explains why Dahl is betting on this model instead of keeping Deno Deploy alive. A Worker doesn’t start a process or a container: it runs code inside a V8 isolate, the same isolation mechanism Chrome uses between tabs. Since the process hosting the isolates is already running, there’s no operating system boot to wait for on each request.
Durable Objects add state to that model. Each object has a unique identifier, and Cloudflare guarantees that only one active instance of that object exists at a time across its entire network, with access to persistent storage and long lived WebSocket connections. That combination of cheap execution, consistent state, WebSockets, and a high level JavaScript interface is, according to the announcement itself, what makes agent harnesses viable: AI processes that need to stay alive and remember context for hours, not just for the duration of an HTTP request.
flowchart TD
A["Client"] --> B["Cloudflare Worker"]
B --> C["Durable Object (unique id)"]
C --> D[("Persistent storage")]
subgraph S1["Cloudflare celld"]
B
C
D
end
Here’s what a Durable Object looks like today in Cloudflare Workers, the building block the celld platform is built on:
export class ContadorAgente {
constructor(state, env) {
this.state = state;
}
async fetch(request) {
let valor = (await this.state.storage.get("valor")) || 0;
valor++;
await this.state.storage.put("valor", valor);
return new Response(String(valor));
}
}
export default {
async fetch(request, env) {
const id = env.CONTADOR.idFromName("sesion-demo");
const stub = env.CONTADOR.get(id);
return stub.fetch(request);
}
};
Every call to idFromName("sesion-demo") returns the same object, so the counter climbs consistently even if requests hit different points in Cloudflare’s network. To confirm it, just call the endpoint twice in a row: the first response is 1 and the second is 2, with no reset of state between the two. There’s no way to inspect that state from outside without adding your own endpoint to expose it: Durable Objects doesn’t publish a public debugging panel.
💡 Tip: To tell an infrastructure bug apart from a bug in your own code in a Worker with Durable Objects, repeat the same request with the same id: if the value doesn’t persist between calls, the problem is in how you set up the binding, not in Cloudflare’s network.
[[durable_objects.bindings]]
name = "CONTADOR"
class_name = "ContadorAgente"
That wrangler.toml file is the only thing that declares the relationship between the Worker and the object. There’s no load balancer to configure or external database to stand up: the object and its storage travel together.
Impact and Analysis
For Cloudflare, bringing on the Deno team reinforces its bet on Workers and Durable Objects right as demand for AI agent infrastructure grows. The announcement itself says it plainly: Durable Objects turn out to be particularly useful for agent harnesses because they combine cheap execution with persistent memory, something an agent running for hours needs and that a traditional container doesn’t offer without extra work.
The move doesn’t happen in a vacuum. In 2026, several JavaScript tooling projects ended up under the roof of AI labs or big clouds: Bun joined Anthropic months earlier. Deno, with Cloudflare, follows that same pattern: development infrastructure is concentrating in the hands of whoever operates the data centers and trains the models.
The fine print carries a real cost for those who chose Deno Deploy precisely to avoid depending on a single cloud provider. The Deno-Cloudflare merger solves that problem by swapping it for another one: the alternative to the big providers now sits, itself, inside one of the big providers. Six months isn’t much time to rewrite an app built for a different runtime, especially if it uses Deno APIs that Cloudflare Workers doesn’t replicate in the same way.
What’s Next
Over the next twelve months, Deno will keep getting monthly releases with security patches, but with no new feature development from Cloudflare. The announcement leaves the door open for the community to carry the project forward once that year ends, since the code remains open source.
Paying Deno Deploy customers have six months to migrate, with direct support from the team that now works at Cloudflare. JSR has no shutdown date: it keeps operating while its infrastructure moves, transparently for package publishers, to Cloudflare’s servers.
Dahl closes the letter with a specific invitation: anyone building agents at scale who wants to run them on their own infrastructure can write directly to the email address published in the announcement. It’s a signal of where the real interest behind the Deno-Cloudflare merger points: less toward traditional hosting, more toward infrastructure for AI agents that need state and a long lifespan.
If you’re running something on Deno Deploy today, try spinning up that same endpoint as a Worker with a Durable Object in the Cloudflare dashboard before the six months from the announcement run out.
Frequently Asked Questions
Does the celld platform replace Deno Deploy?
In practice, yes. Deno Deploy stops operating in six months, and Cloudflare offers assisted migration to Workers and Durable Objects, the foundation the celld platform is built on.
Does Deno stop being open source after joining Cloudflare?
No. The runtime remains open source, and Cloudflare invites the community to continue its development once the year of official support with monthly patches ends.
What happens to JSR after the Deno-Cloudflare merger?
JSR keeps operating with no shutdown date. The only thing that changes is the infrastructure: it moves to run on Cloudflare’s servers.
Should I migrate my Deno Deploy apps right now?
There’s no immediate deadline, but the clock is running: Deno Deploy stops operating six months after the October 9, 2026 announcement, and Cloudflare only offers migration support to paying customers.
Is rusty_v8 still maintained after the Cloudflare deal?
Yes. Cloudflare confirmed it will keep supporting rusty_v8 and will work to integrate it into the open source workerd runtime.
References
- Deno: Ryan Dahl’s official announcement about the merger with Cloudflare.
- Cloudflare Blog: joint post by Ryan Dahl and Kenton Varda about celld and Durable Objects.
- Cloudflare Docs: official Durable Objects documentation.
- Cloudflare Docs: official Cloudflare Workers documentation.
- GitHub: rusty_v8 repository, the Rust bindings over V8.
- JSR: package registry that keeps operating after the merger.
📱 Enjoying this content? Follow @programacion on Telegram for daily tech content in Spanish: quick summaries, fresh content every day.
Featured image: Foto de Taylor Vick en Unsplash
Did it work for you? Got a different error? Say so below: questions get answered and help the next reader.
Leave a comment
0 Comments