Self-Hosting Cloudflare Workers: What celld and the Deno Deal Actually Run

If your team avoided Cloudflare Workers because of lock-in, the math changed on October 9, 2026, but not in the way the press release framing suggests. Two coordinated announcements, one from Cloudflare, one from Deno, say the entire Deno team is joining Cloudflare, and that celld, Deno’s open-source implementation of Workers and Durable Objects, will be merged into workerd as a first-class supported self-hosting path. The practical finding is this: you can self-host Workers workloads today, per Cloudflare’s post, but the supported, merged version of that path is an undated roadmap, and Durable Objects, the Workers feature with no obvious substitute elsewhere, is exactly the capability Cloudflare admits does not scale outside its own network. Treat this as an invitation, not a shipped exit door.

That distinction matters because everything in this story comes from the two parties to the acquisition. Neither announcement includes independent compatibility results, a published API coverage matrix, or a documented production celld deployment. What follows separates what runs today from what is promised, and prices the part of the deal the announcements leave unquantified: running a second runtime yourself.

What the announcements actually say

The deal itself is simple. “Today we’re announcing that the entire Deno team is joining Cloudflare to take that work further,” the Deno blog post states. Deno had released celld in August 2026, which Cloudflare’s post describes as an open-source implementation of Workers and Durable Objects, designed for compatibility with Cloudflare’s platform but focused on self-hostability and scalability.

The roadmap is also explicit. According to Cloudflare, “Ryan and Bert will be leading a new effort to make workerd self-hosting a first-class supported way to build and run apps using the Workers programming model. This will involve merging code and ideas from celld back into workerd.” That is Ryan Dahl and Bert Belder, Deno’s founders. No date is attached; Cloudflare promises “more announcements about this work in the coming months,” and adds: “But if you can’t wait, you can start self-hosting celld or workerd today.”

One piece of framing deserves scrutiny. Cloudflare’s post introduces celld by way of a lock-in theory it then disputes: “Under this theory, celld is a threat: as an open-source implementation of Workers and Durable Objects, it allows applications built on Workers to seamlessly migrate to other providers. No more trap!” The word “seamlessly” appears inside a rhetorical position the post argues against, not as a verified property of the software. Compatibility coverage remains a vendor characterization, and the announcements’ own admissions cut the other direction, as the next sections show.

What actually self-hosts today

workerd, the runtime Cloudflare open-sourced after Shopify’s 2022 Workers-for-Platforms evaluation made an open-source runtime a condition of building on Cloudflare, is the same code Cloudflare runs in production, not a parallel implementation. Former customers have migrated away from Cloudflare using it, according to Cloudflare’s account. That is a real, if narrow, track record.

But Cloudflare’s own telling is candid about adoption: “We released workerd genuinely intending for people to use it in production. A few have, but so far, not that many. Most people don’t seem to have any idea that this is even possible.” The surrounding tooling and services ecosystem the company expected to grow around self-hosted workerd never materialized. So “self-hostable today” describes a runtime binary and a gap where the platform used to be.

celld is the newer and less proven option. The vendors describe it as compatible and self-hostable; neither announcement includes license terms for the celld repositories, a compatibility matrix, or a third-party deployment. If celld is on your evaluation list, the first deliverable to demand is a published coverage matrix against the Workers and Durable Objects APIs you actually use, plus license terms. Without those, “portable” is a plan, not a property.

The Durable Objects gap

This is the decisive axis, because Durable Objects are the Workers feature with no obvious substitute elsewhere: stateful objects that also explain why teams feel locked in. And it is where Cloudflare’s announcement is most honest. “In the interest of transparency, I do have to admit that workerd has always had one big gap in its production-readiness: Durable Objects,” the post states. “Workerd implements them, but only in a single-instance way, good enough for local testing, but unable to scale.”

The reason is architectural. Cloudflare’s production Durable Object routing has numerous dependencies on external services operated by a site-reliability team, and the company says plainly it is not the implementation a self-hoster would want. In other words, the scalable version of the feature is entangled with Cloudflare’s network operations, and the open-source runtime ships the local-testing version.

celld is positioned to close exactly this gap, which is why the acquisition makes sense. Deno’s post says celld focuses on Durable Objects because they “bring together capabilities that are particularly useful for agent harnesses: inexpensive, serverless execution, persistent state, WebSockets, and a high-level JavaScript interface.” But neither announcement documents how celld’s self-hosted Durable Object storage behaves, consistency model, persistence guarantees, migration behavior, or demonstrates it under production load. If your Workers usage is Durable Objects-heavy, you are the target audience for the merged roadmap and simultaneously the team with the least verified ground to stand on today.

Runtime portability is not platform parity

A Workers application is not just handler code. It is handler code plus bindings: KV, R2, Queues, Workers-native rate limiting, service bindings, the dashboard tooling around all of it. A runtime that executes your fetch handler ports the first part and leaves the rest behind.

One public project offers a concrete illustration. A production-oriented GA4 MCP server on GitHub runs the dual-runtime hedge in the wild: Cloudflare Workers host production while an Express adapter serves local and self-hosted use, sharing one controller so the code does not diverge. But the adapter’s own documentation notes: “The optional Express adapter skips rate limiting so local debugging stays frictionless—place it behind your own gateway if you need quotas in self-hosted environments.” The handler ported; the platform feature did not. One small project does not establish how often this happens, but it shows the mechanism: every binding you touch is a line item in your exit cost, and someone has to rebuild it behind “your own gateway.”

Here is the portability checklist as the evidence supports it today:

The bottom row is the one teams most often undercount. A compatibility matrix, when one appears, will tell you about runtime APIs. It will not tell you who operates your object storage now.

The operational bill for a second runtime

The acquisition converts the exit path from a rewrite into an operations commitment. Leaving no longer means reimplementing your application; it means staffing the runtime, its storage layer, and its tooling gaps yourself. That is cheaper than a rewrite and more expensive than the word “portable” implies.

Two independent sources help price this, by analogy rather than direct measurement. A pilot benchmark on a Raspberry Pi 5 ran 50 randomized runs per stack across equivalent SQLite-backed CRUD APIs in five language runtimes and found self-hosted costs dominated by memory footprint: Rust posted a weighted peak RSS of 7.36 MB with 310.25 req/s/MB throughput-to-RAM (pilot results), while Node.js 24 with Fastify sat in a 2,125–2,461 req/s raw-throughput cluster at far higher memory cost. The authors conclude that “right-sizing worker count to available RAM is a first-order optimization for self-hosted deployments, not merely a configuration detail.” This study measured Go, Rust, Python, Node, and .NET on a single small device, not workerd or celld, and it is an unreplicated pilot. Its value here is directional: when you self-host a runtime, footprint and process tuning become your problem at a level of detail a managed platform hides.

The second source frames the trade itself. A paper on enterprise AI platform adoption describes buying a managed platform as “buying the removal of friction the organization would otherwise finance itself.” Self-hosting Workers reverses that purchase. You get back control and exit optionality; you resume financing the friction: on-call for the runtime, capacity planning, the missing adjacent tooling Cloudflare itself says never grew around workerd. For a platform team already running Kubernetes and a storage stack, that may be a fine trade. For a team that chose Workers precisely to avoid operating infrastructure, the exit path now exists and leads somewhere they did not want to live.

Deadlines for Deno-dependent teams

If your stack touches Deno directly, the announcements carry hard dates independent of any Workers decision:

• Deno runtime: “We will support the Deno runtime for another year with monthly releases containing bug fixes and security updates. After that year we will end our development of the Deno runtime,” per the Deno post. The runtime stays open source and others may continue it.
• Deno Deploy: “Deno Deploy will continue operating for six months before shutting down. We will provide migration support for paying customers moving to Cloudflare Workers.”
• JSR: keeps operating, with infrastructure moving to Cloudflare.
• rusty_v8: support continues, with a stated goal of integrating it into workerd.

Deploy customers have the tighter window and the clearer path: Cloudflare Workers is the vendor-supported destination, and migration help exists for paying customers. Runtime users have roughly a year of patches to decide whether to follow the team to Workers, adopt workerd or celld themselves, or back whatever community continuation of Deno emerges.

Adopt, stay, or hedge

If you stayed off Workers over lock-in: the objection is weaker now but not gone. workerd is genuinely open and production-identical, and a credible merge effort with named leadership is underway. What is missing is the proof that the escape hatch works at production scale, starting with Durable Objects. Adopting Workers today on the strength of this announcement means trusting an undated roadmap from two coordinated sources. I would want the merged supported distribution, or at minimum a published celld compatibility matrix, before treating portability as settled.

If you are already on Workers: nothing forces a decision, and that is the point. Your exit cost dropped from “rewrite” to “operate a second runtime,” which is a budget line you can now estimate honestly: RAM footprint, worker sizing, replacement bindings, on-call. Run the checklist above against your actual API surface. If you are deep into Durable Objects, your exit still depends on the least-proven component, so the practical hedge is the one the GA4 MCP server demonstrates: keep business logic behind a shared controller, isolate bindings at the edges, and accept that platform features will need self-hosted replacements.

If you build agent infrastructure: Deno is betting that Durable Objects are the right substrate for agent harnesses, and celld’s focus there suggests the merged runtime will prioritize exactly those workloads. Worth watching, premature to build on.

The fair summary is Cloudflare’s own, read carefully. You can self-host celld or workerd today; “first-class supported” self-hosting is what Ryan Dahl and Bert Belder have been hired to build, and it does not exist yet. The lock-in argument has moved from architecture to operations. Before you count Workers as portable, ask for the three artifacts the announcements did not include: an API coverage matrix, self-hosted Durable Object storage semantics, and a license. What those documents say will determine whether this deal changed your decision or merely changed the conversation.

Frequently Asked Questions

Can I self-host Cloudflare Workers today?

But if you can’t wait, you can start self-hosting celld or workerd today.

When will Deno Deploy shut down?

Deno Deploy will continue operating for six months before shutting down. We will provide migration support for paying customers moving to Cloudflare Workers.