Deno Is Joining Cloudflare. The Real News Is What Happens to Durable Objects.

On October 9, 2026, Cloudflare announced that the Deno team is joining the company. That’s Ryan Dahl, who created both Node.js and Deno, and Bert Belder, Deno’s co-creator. The announcement was co-authored by Kenton Varda, one of the original architects of Cloudflare’s Workers Runtime. When the person who built Node and the person who helped build Workers write a joint blog post, it’s worth fifteen minutes of your attention, even if you’ve never touched Deno.

The headline detail: Deno’s open-source project celld is merging into workerd, Cloudflare’s own open-source Workers Runtime. That’s not a partnership announcement or a vague “collaboration.” It’s a codebase merging into another codebase, with a stated goal I haven’t seen Cloudflare commit to this plainly before: making Workers and Durable Objects self-hostable, outside Cloudflare’s platform, for the first time.

What celld actually solves

Durable Objects are Cloudflare’s model for stateful serverless compute — a single-instance object that holds state and gets routed to consistently, instead of the usual stateless-function-plus-external-database pattern. They’re genuinely useful. They’re also, today, tied to Cloudflare’s own infrastructure. workerd already runs Durable Objects, but only as single-instance: one Durable Object maps to one machine. There’s no production-ready way to run a distributed fleet of them on hardware you control.

celld is Dahl’s answer to a version of that same problem, built independently at Deno. He describes it as one binary, written in Rust, with object storage as its only external service dependency. It implements distributed Durable Objects across multiple machines, with automatic placement and routing. First released in August 2024, so this isn’t a napkin sketch — it’s had two years to mature as its own project before anyone talked about merging it anywhere.

Put those two facts side by side and the shape of the plan is obvious. workerd knows how to run a single Durable Object well. celld knows how to run many of them, distributed, with just a storage bucket behind it. Merge the second capability into the first, and you get a Workers Runtime that can plausibly run outside Cloudflare’s own data centers — managed by whoever’s running it, on whatever infrastructure they choose.

Dahl’s own framing of the end state, quoted directly in the announcement: you would “manage many instances of celld and a single object storage bucket.” That’s the whole operational model, at least as described so far. No orchestration platform to stand up, no separate control plane to run — just celld processes and a bucket. His stated goal is to make it “radically easy to build and operate distributed applications on your own infrastructure.” That’s a real quote, and it’s a good one. It’s also, right now, a sentence describing intent rather than a thing you can download.

Why this matters, if you’ve ever been blocked by it

Picture a hypothetical team — I’m making this up as an illustration, not citing a real case — running real-time collaborative state in Durable Objects: shared documents, live cursors, that kind of thing. The product works. Then a customer in the EU asks where the data physically lives, and the honest answer is “wherever Cloudflare’s Durable Objects infrastructure puts it,” which is not an answer that survives a GDPR data-residency review. Today, that team’s options are limited: rearchitect around a different stateful-compute model, or tell the customer no. Durable Objects being locked to Cloudflare’s platform has been exactly this kind of adoption blocker for teams with compliance, data-residency, or multi-cloud requirements that aren’t negotiable.

If workerd genuinely picks up celld’s distributed-placement logic, that scenario changes. The same Workers code, the same Durable Objects programming model, but running on infrastructure the team controls — in the EU, on-prem, wherever the requirement points. That’s the pitch, and it’s a believable one, because celld isn’t vaporware. It’s existed for two years as an independent project solving a version of this exact problem. This isn’t someone promising to build distributed state management from scratch next quarter.

But believable and shipped are different words. I’d be careful about the gap between them here.

What I’d actually want answered first

Cloudflare’s own language is “more detail in the coming months.” No GA date. No pricing. No migration tooling. If you’re a technical lead and someone on your team is already sketching a Q4 migration plan around this, slow them down. “Coming months” is not a date you build a quarter around.

Before I’d trust self-hosted Durable Objects with anything that matters, here’s what I’d want to see, and none of these are answered yet — they’re open questions, not criticisms of the plan:

What are the consistency guarantees once a Durable Object’s state is spread across machines you’re running instead of one Cloudflare-managed instance? Single-instance Durable Objects have a simple consistency story almost by construction — there’s one copy. Distributed placement means thinking hard about what happens during a network partition, a slow node, a crashed celld process mid-write. celld presumably has answers; I haven’t seen them published in detail yet.

What’s the actual operational burden of running celld instances yourself, day to day, versus letting Cloudflare run the equivalent for you? “Manage many instances of celld and a single object storage bucket” is a clean sentence. Running anything stateful in production, with on-call rotations and failure modes at 3 a.m., rarely stays that clean. I want to know what breaks, how it’s debugged, and whether that debugging requires expertise most teams don’t have sitting around.

And if you already have Durable Objects running on Cloudflare’s platform today, what happens to that data if you ever want to move it to a self-hosted celld deployment? Is there a migration path, or are you starting from zero? Nothing in the announcement addresses this, which makes sense — there’s no shipped product yet to have a migration story for. But it’s the first question I’d ask Cloudflare directly once more detail lands.

None of this is a reason to dismiss the announcement. Hiring the creator of Node and Deno, and merging a two-year-old Rust project with real distributed-state capability directly into your production runtime’s open-source codebase, is a specific, technical, checkable kind of commitment — not a vague partnership press release. It’s a good sign that the people involved understand exactly what problem they’re solving and have already built a working version of part of the answer.

I’m just not going to plan around a timeline that doesn’t exist yet. I’ll read Cloudflare’s announcement again when the next update lands, and I’d suggest doing the same before anyone commits a roadmap item to it.