Deno Is Joining Cloudflare, and Self-Hosted Workers Might Finally Grow Up

On October 9, Ryan Dahl announced that the entire Deno team is joining Cloudflare. Dahl is the programmer who created Node.js and later Deno, so when he moves an entire company onto someone else's platform, it is worth paying attention. But the headline that matters most to people who run their own infrastructure is buried in the details: the new team's first big job is to make the Workers programming model something you can run well on your own servers, not just on Cloudflare's network.

The plan is to merge two open-source projects. The first is workerd, Cloudflare's open-source runtime for Workers, the same code that runs in production across Cloudflare's network. The second is celld, a project the Deno team released in August that implements the Workers and Durable Objects model for running on infrastructure you operate yourself. Dahl and Bert Belder, Deno's co-creator, will lead the effort, with the goal of making self-hosting a fully supported way to build and run applications on the Workers model.

What was actually announced

Both companies published joint posts on October 9, and the timeline of changes is unusually specific for this kind of announcement. The standalone Deno runtime will receive monthly bug and security releases for one more year, after which Deno's own development of the runtime ends. The runtime stays open source, so the community can fork or maintain it, but the company behind it is done. Deno Deploy, the hosted service, shuts down in six months, and paying customers will get migration support to Cloudflare Workers. JSR, the JavaScript and TypeScript package registry Deno built, keeps running, with its infrastructure moving to Cloudflare. Work on rusty_v8, the Rust bindings that power Deno's V8 integration, continues, and the team plans to integrate them into workerd.

The posts describe the arrangement as "joining," and neither disclosed a price or deal structure, though Cloudflare's blog page carries an "Acquisitions" tag. No release date was announced for the merged celld and workerd work. Cloudflare's Kenton Varda wrote that more announcements will follow in the coming months.

Why self-hosting Workers was half finished until now

Here is the gap this effort is meant to close. Workerd has been open source for years, and you can already run it yourself. But its support for Durable Objects is limited: objects run within a single instance and cannot scale across multiple servers. Cloudflare describes that implementation as sufficient for local testing, while acknowledging that only a handful of people have ever run workerd in production.

That limitation matters because Durable Objects are the stateful half of the Workers model. They give an application a way to attach code to persistent state: each object can handle requests and WebSocket connections while accessing its own SQLite database. That is what makes features like real-time collaboration, chat rooms, and per-user consistency practical without bolting on an external database and a coordination layer. But a single-instance object store is a dead end for anyone who wants redundancy or horizontal scale on their own hardware.

Cloudflare has been unusually candid about why it has not solved this before. The company says its own production routing for Durable Objects is unsuitable for self-hosters because it serves hundreds of locations and depends on external services maintained by site reliability engineers. It also acknowledges that it has done too little to develop the tooling and services needed around workerd deployments.

The interesting work was never the runtime binary. It was the programming model: compute, storage, and communication designed together, instead of each application assembling its own stack.

What celld brings to the table

Celld was Deno's answer to the operational side of this problem. Released in August, it implements the Workers and Durable Objects programming model so that applications run across multiple instances against a single object store, on infrastructure the developer controls. In his announcement, Dahl argued that the progression from Deno to Deno Deploy to celld is exactly why the move makes sense: running a hosting service taught the team how much complexity hides underneath the developer experience, and celld was their attempt to make distributed applications simple to operate from the start.

The joint post describes celld as designed for compatibility with Cloudflare's implementation while focused on being self-hostable and scalable. Cloudflare, in its own post, said it was happy about celld rather than threatened by it, because it was the implementation the company had wanted to build for a while: Workers and Durable Objects, fully compatible with its own, with scaling built into the programming model rather than assembled as infrastructure by each application.

What it means for your homelab

For self-hosters, the practical reading is cautious optimism. The Workers programming model is genuinely attractive for home infrastructure: tiny isolates instead of containers or VMs, sub-millisecond startup, and a storage model where each object carries its own SQLite database instead of requiring a separate database server. If workerd becomes something you can deploy in a cluster with durable state that survives node failures, it could sit alongside the usual homelab stack of containers and hypervisors as a lighter way to run small services.

But everything on that side of the ledger is a stated plan, not a shipped product. The six-month Deno Deploy shutdown is real and immediate; the merged self-hosting story is promised for "the coming months" with no date. Anyone running workloads on Deno Deploy should be planning a migration today, not waiting for the future platform. And Deno users with long-term plans for the standalone runtime should note that the clock is now ticking: one year of monthly releases, then the company stops, and the community takes over or it fades.

There is also a broader signal worth noting. Cloudflare spent years as a company you built on top of; this move, along with the admission that self-hosting deserves first-class support, suggests it now sees the exit path as a feature. The ability to take a Workers application off Cloudflare's network and run it on your own machines, or move between providers, lowers the commitment anxiety that keeps some teams from adopting the platform at all. For the self-hosting world, the best outcome is not that Cloudflare wins more customers. It is that the Workers model becomes genuinely portable, so the code you write this year still runs wherever you want it to run five years from now.