On 5 August, Cloudflare open-sourced Cloudflare OS and the loudest criticism was immediate: the licence says Apache 2.0, but the thing only runs on Workers, Durable Objects and Cloudflare Access. Portability was theoretical. Days later, Deno published celld, an Apache 2.0 daemon that runs Cloudflare Workers and Durable Objects on your own machines, using exactly the same JavaScript APIs and the same Wrangler configuration.
That is a significant shift. Durable Objects have been the most interesting primitive in serverless computing for several years, and also the most locked-in. If celld holds up, the primitive survives the provider. For anyone making architecture decisions with a five-year horizon, that changes the risk calculation.
TL;DR
- celld is an open-source (Apache 2.0) daemon from Deno that runs Cloudflare Workers and Durable Objects on your own infrastructure, using the same APIs and Wrangler config.
- The stack is V8 + S3 + SQLite + LTX + Tokio. Every object is its own SQLite database, addressed by name and continuously replicated to an S3-compatible bucket you control.
- There is no control plane and no consensus service. Nodes coordinate purely through compare-and-swap leases on the bucket, so the only infrastructure dependency is object storage.
- Writes are durable before they are acknowledged (RPO of zero), idle cells hibernate to roughly their storage cost, and per-cell memory overhead is around 4 MB.
- Caveats are real: the compatibility surface is still evolving, peer traffic has no TLS termination so nodes need a private network or overlay, and self-hosting means you now own the operational burden Cloudflare was absorbing.
Why Durable Objects mattered in the first place
Serverless solved stateless compute properly and then stalled. The moment your application needs coordination, a shared counter, a collaborative document, a rate limiter, a queue with ordering guarantees, the stateless model starts leaking. You reach for Redis, then for a database with row locks, then for a distributed lock service, and before long you have rebuilt a small, badly specified distributed system inside your application layer.
Durable Objects took a different route. Each object is a single-threaded, addressable, strongly consistent unit of state with its own storage. There is exactly one instance of a given object anywhere in the world at a time, so concurrency inside it is trivially correct. You get coordination without a coordination service. It is a beautifully small idea, and it is why so many real-time and multi-tenant products ended up on Cloudflare whether or not their teams wanted to be there.
The cost was that the primitive existed in one place only. Choosing Durable Objects meant choosing a vendor for the lifetime of the architecture, because the model has no meaningful equivalent on AWS, Azure or GCP. That is an uncomfortable position for any business with data residency requirements or procurement rules about single-supplier dependency.
What celld actually does
celld embeds V8 in each node and executes Wrangler bundles directly. Every Durable Object, or “cell”, is its own small SQLite database, addressed by name, replicated continuously to an S3-compatible bucket. That bucket is the durable source of truth. Nodes are treated as replaceable.
The coordination design is the clever part. Rather than running Raft, etcd or a membership protocol, celld uses object-storage compare-and-swap to ensure exactly one node owns a cell at any moment. Ownership records, deployments and cell state all live in the bucket. Peer requests are HMAC-authenticated, clock-bounded and replay-protected using a fleet secret stored alongside them.
The practical consequence is that your dependency list is one line long: an S3-compatible bucket. AWS S3, Cloudflare R2, MinIO on your own hardware, anything that speaks the protocol. There is no cluster to bootstrap, no quorum to lose, and no control plane to page someone about at three in the morning.
The cost characteristics follow from the SQLite-per-object design. Because every object is its own database, applications shard by construction: the contention and blast radius problems of a single shared database are designed out rather than managed. Idle cells hibernate to close to nothing, so you pay storage rather than compute for the long tail. Deno claims an order of magnitude cheaper at scale, which is worth treating as directional rather than a benchmark until you have run your own workload.
What this changes commercially
Three things, and none of them are about saving money on hosting.
An exit route becomes real. The strongest argument against Durable Objects in technical due diligence was always the single-supplier dependency. An open implementation with API parity turns that from an architectural dead end into a migration project, and investors have started asking about exactly this kind of concentration.
Data residency becomes tractable. With the EU-US transfer framework under pressure again and Cyber Resilience Act reporting duties going live on 11 September 2026, running a stateful workload inside a jurisdiction you choose, on storage you control, is not an academic benefit. Pointing a compliance officer at a bucket in eu-west-1 is a much shorter conversation than explaining a global edge network.
Development and production stop diverging. Teams on Workers have long had a local development story that only approximates production. Running the same daemon locally, in CI and on staging removes a category of “works on the edge, fails in test” bugs that quietly eat sprint time.
The caveats, stated plainly
This is early software and the project says so. The runtime and compatibility surface are still evolving, public tests cover smoke paths, and only a documented subset of Wrangler configuration is supported. If your Worker leans on the wider Cloudflare product surface (KV, Queues, Vectorize, AI bindings) you are not lifting and shifting anything today.
The security posture needs care. Peer HTTP has no TLS termination, so nodes must run on a trusted private network or an encrypted overlay such as WireGuard or Tailscale. Public IP advertisement is rejected unless you explicitly pass an unsafe flag, which is the right default. Anyone holding the fleet secret and bucket credentials effectively holds fleet administrator access, so those belong in a secrets manager with rotation, not an environment file on a jump box.
Pressure shedding, the mechanism that limits resident cells by count, RSS and CPU, is opt-in while safe defaults are validated, so capacity planning is your problem for now. The project also takes patches by email rather than pull requests, which tells you how much community contribution to expect in the near term.
Most importantly: self-hosting moves the operational burden onto you. Cloudflare’s price includes a global anycast network, DDoS absorption, certificate management and an on-call team. Three boxes behind a load balancer do not. Do the total cost comparison honestly, engineering hours included.
Where it fits, and where it does not
Good candidates: real-time collaboration and presence, per-tenant state in multi-tenant SaaS, rate limiting and quota enforcement, workflow coordination, IoT device shadows, and anything where you have a shared Postgres table under lock contention that you know is a future incident.
Poor candidates: anything needing global low latency at the edge without an operations team behind it, workloads already bound to other Cloudflare services, and teams with no appetite to run stateful infrastructure. Managed Durable Objects remains the right answer for a great many products, and the existence of an escape hatch is itself a reason to feel better about choosing it.
What to do this quarter
- If you already run Durable Objects: stand up celld against a MinIO bucket and replay a non-critical object type through it. You are measuring compatibility, not performance. Document what breaks. That document is your exit plan.
- If you have been avoiding Durable Objects on lock-in grounds: revisit the decision, particularly for coordination problems you are currently solving with Redis plus optimistic locking.
- If you are designing something new: treat the object-per-entity model as a first-class option alongside the shared-database default. Sharding by construction is the real prize, and it is far easier to adopt at design time than to retrofit.
- Either way: add “which of our stateful primitives exist in only one vendor’s catalogue” to your architecture review. Celld is one answer. The question outlasts the answer.
The broader pattern
This is the third time in twelve months we have watched a proprietary infrastructure primitive acquire an open implementation, after durable execution (Temporal, Restate, Inngest, Microsoft’s pg_durable) and edge databases. The pattern is consistent: a cloud provider proves a primitive is valuable, the ecosystem reimplements it on commodity components, and the provider’s moat narrows to operations and network rather than the idea itself.
The lesson is not “self-host everything”. It is that the lock-in cost of adopting a novel primitive is falling, so the right time to evaluate one is earlier than it used to be. Waiting for a standard now means waiting longer than the competitive advantage lasts.
Need help with this?
We build and run stateful, distributed systems across development, DevOps and platform engineering, and we spend a lot of time helping teams work out which infrastructure bets are worth taking and which are worth deferring. If you are weighing up a serverless architecture, planning an exit from a single-vendor dependency, or working out whether an object-per-entity model fits your product, get in touch.
📷 Photo by Taylor Vick on Unsplash
