Deno joins Cloudflare to make self-hosted Workers and Durable Objects first-class

Deno is joining Cloudflare

Cloudflare has announced that Deno, the company behind the JavaScript and TypeScript runtime of the same name, is joining it. According to the Cloudflare blog, Ryan Dahl and Bert Belder will lead a new effort to make self-hosting workerd, Cloudflare's open-source Workers runtime, a first-class, supported way to build and run applications. The plan involves merging code and ideas from celld, an open-source implementation of Workers and Durable Objects that the Deno team released in August, back into workerd. Cloudflare says further announcements will follow in the coming months.

A rebuttal of the lock-in critique

Cloudflare framed the announcement partly as an answer to a persistent criticism of Workers: that it works differently from other hosting platforms on purpose, so that applications become hard to move elsewhere. The blog rejects that theory. It argues that the platform's design, a programming model built around bindings and Durable Objects that can run cheaply across hundreds of locations, is simply a better way to build cloud software, and that those benefits could not have been achieved while staying fully compatible with traditional platforms.

As evidence that it is not trying to trap customers, the post points out that workerd, the Workers runtime, is open source, something Cloudflare says many people do not realise. The company says it took that step after pitching Workers for Platforms to customers such as Shopify in 2022 and being told they could not build on the platform unless the runtime was open. Workerd is described as the very code Cloudflare runs in production, not a parallel project, and the company acknowledges that former customers have used it to migrate away, a trade-off it accepts since those customers would not have signed on otherwise.

Why workerd never caught on for self-hosting

For all that, workerd has seen little self-hosting adoption, and the blog is unusually candid about why. Cloudflare admits it did a poor job of building out the surrounding services and tooling, having released the runtime and hoped the community would adapt it to every environment, which did not happen.

There is also a technical gap. According to the post, workerd's implementation of Durable Objects supports only a single instance, fine for local testing but not scalable. Cloudflare's own production implementation of Durable Object routing was built to serve hundreds of locations and leans on external services maintained by a dedicated reliability team, making it a poor fit for anyone self-hosting. The company says TODO comments about this date back to workerd's original release, and that an internal attempt at a fix last spring failed.

What the Deno team brings

That is the context in which Cloudflare says it welcomed celld. Deno's implementation was designed for compatibility with Workers and Durable Objects while staying self-hostable and scalable, the combination Cloudflare says it had wanted for years. The blog also leans on the team's pedigree: Ryan Dahl created Node.js, effectively inventing the idea of using JavaScript on the server, and with Bert Belder and the rest of the Deno Land crew later built Deno. In Cloudflare's telling, that team understands developer experience around a self-hosted runtime in a way Cloudflare never quite managed with workerd alone.

For now, Cloudflare notes that anyone can already self-host celld or workerd today, and the post's author says he intends to use the combined result to run an instance of Cloudflare OS at home. What the move means for the Deno runtime's own roadmap was not addressed in the announcement.

Why it matters

This is a notable consolidation in the JavaScript ecosystem: Deno, one of the best-known alternatives to Node.js, is being folded into one of the largest cloud providers, and the people who pioneered server-side JavaScript will now shape Cloudflare's runtime. For developers, the practical consequence is a credible, vendor-backed path to running Workers-style applications, Durable Objects included, on their own infrastructure. That undercuts the strongest version of the lock-in argument against building on Workers and may pressure other serverless platforms to offer clearer exit paths. Open questions remain, notably what becomes of Deno as a standalone product and how the merged workerd will relate to Deno's own runtime, but the stated direction is clear: the Workers programming model is being positioned as something developers can take with them.