Skip to content

Deno's Celld Breaks Durable Objects Out of Cloudflare

An S3 bucket replaces the control plane, and even the primitive's creator is cheering on the forks.

Ji-ho Choi
Ji-ho Choi
Security & Cloud Editor · Aug 6, 2026 · 5 min read
Deno's Celld Breaks Durable Objects Out of Cloudflare

For six years, Durable Objects have been the best argument for locking yourself into Cloudflare. The primitive — a single-threaded JavaScript class with its own strongly consistent storage, addressable by name from anywhere — turned out to be the right shape for chat rooms, collaborative documents, multiplayer state, and lately, AI agent sessions. But you could only run it on one company's network, at one company's prices.

That changed this week. Deno's team released celld, an Apache-2.0 daemon that runs unmodified Cloudflare Workers and Durable Objects on your own machines. Not a lookalike API: the same JavaScript classes, the same wrangler bundles, the same SQLite storage interface, alarms, RPC, and hibernatable WebSockets. The pitch, in Ryan Dahl's words, is V8 + S3 + SQLite + LTX + Tokio. The launch hit the Hacker News front page within hours, and the most telling comment came from Kenton Varda — the Cloudflare engineer who designed Durable Objects — who showed up not to object but to say he loves that multiple implementations now exist, and to point at his own in-flight pull request adding self-hostable clustering to workerd.

Read that again: the vendor that invented the primitive and the runtime team that spent years chasing it are now independently building open implementations of the same API. That's how the S3 protocol became a standard. It's happening to Durable Objects.

The bucket is the control plane

Celld's architecture is the interesting part. Each object is its own SQLite database, continuously replicated to an S3-compatible bucket as LTX segments — the transaction-log format from the Litestream lineage. Every node embeds V8 and executes Wrangler bundles. And coordination — which node owns which object, cluster membership, failover — happens entirely through compare-and-swap writes against that same bucket. No etcd, no ZooKeeper, no Raft, no control plane to operate. A node claims an object by winning an atomic lease write; if it dies, another node takes the lease and restores the SQLite file from the replica. Celld claims writes are durable in the bucket before they're acknowledged, so a failover — about 20 seconds, by their numbers — loses nothing.

This design was flatly impossible on plain S3 until recently. AWS only shipped conditional writes in August 2024 and ETag-based compare-and-swap that November, and those two features quietly spawned a generation of systems that outsource consensus to object storage — WarpStream did it for Kafka, SlateDB for LSM storage. Celld is the same wave reaching stateful compute. One HN commenter objected that the bucket is a control plane, just someone else's — true, and also the point. S3-compatible storage is the most operationally boring, universally available strongly consistent service in existence. Delegating your consensus to it beats running a quorum yourself, though it does mean your bucket needs real CAS semantics: AWS, R2, or MinIO qualify; a loosely consistent S3 clone will corrupt you.

The density numbers are what make the economics work. A hibernated cell costs roughly its S3 storage; a resident one takes about 4 MB of RAM, so an 8 GB node holds around 1,000 of them. Celld's own comparison — about $0.05 per resident cell-month on commodity VMs versus roughly $4.15 in Durable Objects duration billing, or $4,856 versus $415,000 a month at 100,000 cells — deserves a caveat they don't emphasize: Cloudflare only bills duration while an object is actually in memory, and hibernated objects bill nothing. If your fleet is bursty, you'll never see an 85× gap. If it's steady-state resident — long-lived agents, always-on game worlds, active collaboration sessions — the order-of-magnitude claim is credible arithmetic, not marketing.

What you'd actually be signing up for

Adoption is genuinely small: a 58 MB static binary or container per node, then

celld deploy . --bucket s3://my-cells-bucket

against your existing Workers project. The compatibility docs are refreshingly explicit about the boundary. You keep fetch handlers, service bindings, JS RPC with promise pipelining, DO alarms, and SQLite storage. You lose KV, R2, Queues, cron triggers, the Cache API, HTMLRewriter, and Workers AI — celld's docs are blunt that KV and R2 are different systems and not on the roadmap. Unsupported wrangler config keys fail loudly instead of silently, which is the right call.

The sharper trade-offs are architectural. Celld doesn't terminate TLS, and nodes talk HMAC-authenticated plaintext HTTP, so it assumes a trusted network — WireGuard, Tailscale, or a VPC — with your own proxy in front. There's no answer to Cloudflare's 300-plus points of presence; this is a system for running a stateful fleet in a region you control, not a global edge. Durable writes run about 90 ms region-local by celld's published numbers, fine for its use cases but worth measuring against your own. And the code is days old, with a public history of three commits and a contribution policy that disables pull requests entirely in favor of emailed git format-patch — an anti-AI-slop stance that tells you how the maintainers intend to guard quality, and also how early this is.

It's worth saying that none of this is a new idea. Microsoft's Orleans pioneered virtual actors in the early 2010s, and Durable Objects in 2020 were Varda's repackaging of that model into something a JavaScript developer would actually reach for. What's been missing since workerd was open-sourced in 2022 is the scheduler — workerd runs DOs with local-only storage on a single node, which is why self-hosting the model never worked. Rivet's open-source actors attacked the same gap with a new API. Celld is the first implementation where existing Workers code just moves.

Who should care

If you're happily under Cloudflare's free tier or your objects hibernate most of the time, nothing here changes your week. The people who should be running the numbers are teams with large, steadily resident object fleets — that's where the meter bites — and teams that ruled out Durable Objects entirely because of data residency, on-prem requirements, or vendor-risk policy. For them, the primitive is suddenly available anywhere a VM and a bucket exist.

I wouldn't move production traffic to a three-commit daemon this quarter. But direction matters more than maturity here. With celld shipping, workerd's cluster mode in review, and the API's own creator cheering on the forks, the Durable Objects programming model has stopped being a Cloudflare product and started being an open standard with multiple competing runtimes. The model won. The exclusivity lost.

Sources & further reading

  1. celld: self-hosted, distributed Durable Objects — github.com
  2. celld — official site and docs — celld.dev
  3. Celld: Self-hosted, distributed Durable Objects (discussion) — news.ycombinator.com
  4. workerd PR #6780: scalable self-hosted Durable Objects (cluster mode) — github.com
  5. Ryan Dahl: Introducing celld — x.com
Ji-ho Choi
Written by
Ji-ho Choi · Security & Cloud Editor

Ji-ho covers the increasingly tangled overlap between cloud architecture and security, drawing on a background as a penetration tester to keep his reporting grounded in real-world attack paths. He never lets a vendor claim go unquestioned and insists that every buzzword come with a proof of concept.

Discussion 1

Join the discussion

Sign in or create an account to comment and vote.

Paul Nguyen @pragmatic_paul · 1 week ago

sure, but "same" is doing a lot of work here. you're still managing a daemon, monitoring SQLite consistency across your own machines, handling your own backups. cloudflare's durable objects work because they handle all that invisibly. if you actually need to port to multiple clouds, just build on postgres with a boring state machine—been working fine for decades, way less lock-in than swapping one proprietary system for another.

Related Reading