Deno joins Cloudflare to make Workers and Durable Objects self-hostable
Cloudflare is absorbing Ryan Dahl’s Deno team and merging the workerd runtime with celld, Deno’s open-source implementation of Workers and Durable Objects released in August. If you want to run Worker-style apps on your own infrastructure, celld is now the path to watch.
9 October 2026. Cloudflare announces that the Deno team, led by Ryan Dahl, is joining the company to merge the open-source workerd runtime with celld, Deno’s open implementation of Workers and Durable Objects published in August 2026. 9 October 2026. Kenton Varda, the architect behind Workers, co-signs the post. 9 October 2026. The New Stack frames it as the acquisition of the Node.js creator’s startup. Why it matters: the Workers programming model, until now inseparable from Cloudflare’s network, becomes something you can run on your own hardware — and the “lock-in” accusation Cloudflare has carried for years loses its technical footing in a single day.
celld, the missing piece for workerd
workerd is the open-source engine that executes Workers: a sandboxed JavaScript/Wasm runtime, released under an open licence. But there is a catch, and Ryan Dahl states it himself: Durable Objects support in workerd is limited to a single instance. Yet the abstraction’s power comes precisely from distribution — one Durable Object per chat channel, per queue, per slice of application state, spread across machines, with placement, routing and durable storage handled by the platform.
celld fills that gap. It is a single binary, written in Rust, whose only external service dependency is an object storage bucket. Running celld means operating several instances of the binary and one storage bucket. An application can then bundle compute, relational databases, queues and real-time channels without spinning up a separate infrastructure project per service. For Ryan Dahl, this is a return to the simplicity he was chasing back in 2009, when he demoed Node.js with a five-hundred-line IRC server in a Berlin warehouse.
Why Durable Objects is more than a cache
A Durable Object looks, from a distance, like a key-value store. Up close it is something else: a distributed singleton with a local SQLite database, single-threaded JavaScript that is easy to reason about, and WebSocket connections addressed directly to it. Each object is a unit of state and logic you can place, replicate and route independently.
The consequence for developers runs deep. In a classic three-tier architecture, state lives in a shared database and compute in stateless instances; making two users collaborate in real time means wiring together a pub/sub, a cache and a database — three systems to operate and reconcile. With Durable Objects, the channel and its state live in the same object: you shard from the start by giving one object per room, per document or per session, and everything else follows.
It is this density — compute, state, real-time and persistence in a single abstraction — that celld exports beyond Cloudflare’s network. And it is this, more than the runtime itself, that makes the offering hard for competitors to copy.
The “lock-in” theory collapses on its own
For years a theory has circulated: Cloudflare made Workers deliberately different to trap its customers. Apps built on Durable Objects are not just written differently, they are architected differently — and therefore, so the argument went, impossible to migrate. Under that theory, celld was a threat: an open-source implementation that let Workers applications move to another provider.
Kenton Varda answers head-on. Workers is different, he concedes, but because it is better: deploying an application to hundreds of points of presence at negligible cost, with bindings that make access to external resources more secure, has no equivalent anywhere else. And “lock-in” hurts Cloudflare, not the reverse: if no escape hatch existed, its largest customers would never have signed up. Opening celld flips the posture — instead of defending a moat, Cloudflare opens the door voluntarily and bets the model will win on merit.
A battle of programming models, not of market share
The stakes go beyond Cloudflare. The edge-computing market long fought over the runtime: Vercel, Netlify, Fly.io, Deno Deploy each offered their own flavour of serverless-at-the-edge. Cloudflare picked a different battlefield — the programming model. Durable Objects are not one more function type; they are a different way to design an application, where state and compute live in the same place.
Opening that model is a risky but coherent bet: if the Workers model becomes a standard you can run anywhere, the value shifts from the network to the ecosystem, the tooling and the expertise. It is the same play Amazon won with AWS, and Google attempted with Kubernetes: win the standard, monetise around it. The difference here is that the standard in question was, until now, Cloudflare’s private property.
What it changes for self-hosting
Concretely, merging workerd and celld has one stated goal: making the Workers model “radically easy to build and operate on your own infrastructure”. The use cases write themselves — data sovereignty, on-premise deployment, local development environments faithful to production, or a plain preference for self-hosting.
The tipping point is Durable Objects. Each Durable Object is a small, individually addressable server with its own SQLite database, single-threaded JavaScript that is easy to reason about, and synchronous access to its local database. That is the abstraction that lets you shard data and WebSocket connections from day one — and it is what celld finally makes distributable outside Cloudflare. Deno Deploy had already taught Ryan Dahl the complexity he wanted to escape: multiple public clouds, multiple databases, deeply entangled services. celld is the antidote.
Take a team building a real-time collaboration app. Today it faces a binary choice: deploy on Cloudflare’s network and inherit Durable Objects, or stay on its own infrastructure and rebuild pub/sub, state and persistence by hand. The workerd/celld merge promises to remove that choice, letting the same application run interchangeably on Cloudflare or on a self-hosted cluster behind a single object-storage bucket.
One more point in the merge’s favour: workerd and celld were already neighbours. Both are Rust-based, both target the same Web-platform APIs, and both descend from the V8 isolates model. That proximity is why the convergence is credible at all — and why the risk of it becoming vapourware is lower than in a typical acquisition.
What the deal does not change
The announcement does not kill Deno. The Deno runtime continues to exist and evolve — Ryan Dahl points to the Deno blog for the details of the runtime’s future and the team’s other efforts. For Deno Deploy users, nothing is announced as an immediate shutdown; but the strategic direction is unambiguous — the team’s energy now goes toward the workerd/celld convergence inside Cloudflare.
One classic uncertainty remains: the timeline. No general-availability date is given for the merge. celld, published in August 2026, is still young; converging two runtimes, even neighbouring ones, is a multi-month project. Caution is warranted for anyone who would build production on it today.
Verdict
If you build on Workers and worry about Cloudflare dependence, watch the workerd/celld merge: it is the first real exit toward self-hosting, but it is not yet production-ready. If you operate your own infrastructure and the Durable Objects model appeals to you, evaluate celld in a test environment — it is today the most credible way to get distributed Durable Objects without Cloudflare’s network. If you are on Deno Deploy, change nothing immediately, but plan ahead: the team’s trajectory points at Cloudflare, and your medium-term architecture choices should reflect that.