celld
Self-hosted, distributed Durable Objects
- Your Cloudflare app runs unchanged: Workers, Durable Objects, KV, Queues, D1, R2, Workflows, Cron, static assets (supported APIs →)
- Your data lives in a bucket you own
- Orders of magnitude cheaper at scale
Get it
$ curl -fsSL celld.dev/install.sh | sh$ docker run ghcr.io/denoland/celld❯ create a distributed chat app with vite, use celld.dev and exe.dev, 2 VMsKey characteristics
| Durability | ||
|---|---|---|
| Writers per cell (epoch-fenced) | 1 | |
| Acknowledged writes lost on kill | 0 | RPO=0 |
| Durable write latency (one node, region-local) | ~90 | ms |
| Failover after node loss, 0 lost | ~20 | s |
| Speed (warm) | ||
| Stateless request p50 / p99 | 0.2 / 0.3 | ms |
| Stateless throughput / worker thread | ~94k | req/s |
| Wake a hibernated cell | ~4 | ms |
| Density & cost | ||
| RAM per resident cell | 0.47 | MB |
| Resident cells / 8 GB node | 2,500 | cells |
| Inactive cell cost | ~0 | bucket ops |
| $ / resident cell-month | ~$0.02 | |
| Compatibility | ||
| Supported services and APIs | docs → | |
- Speed and density: one node, trivial cells, an Apple M-series laptop over loopback. The measured 2 vCPU fleet node had a slower activation p50 of 35.9 ms.
- Durability: a fleet of 4 vCPU / 8 GB nodes and a bucket in the same region. We test failover by stopping a loaded node with SIGKILL and verifying every room after recovery. How this is measured →
Monthly cost vs resident fleet size
- Durable Objects: Workers Paid, $5/mo plus $4.15 per resident cell-month; the free plan covers small workloads.
- celld: whole $48 / 8 GB nodes (DigitalOcean us-east list), capped at 2,500 resident cells each; capacity is added in steps.
- These base costs exclude the compute and bucket usage from application traffic and writes. Click a dot for a cost breakdown.
Supported services
| Service | What it is | Status | Example |
|---|---|---|---|
| Workers | stateless request handlers | Supported | examples/hello → |
| Durable Objects / Cells | single-threaded actors with durable storage | Supported | examples/counter → |
| Durable Object Facets | child objects inside a Durable Object | Supported | examples/facets → |
| KV | key-value store | Supported | examples/kv → |
| Queues | message queue | Supported | examples/queues → |
| D1 | SQL database | Supported | examples/d1 → |
| R2 | S3-style object storage | Supported | examples/r2 → |
| Workflows | durable multi-step execution | Supported | examples/workflow → |
| Cron Triggers | scheduled handlers | Supported | examples/cron → |
| Static assets | files served from a directory | Supported | examples/static-assets → |
| Dynamic Workers | Workers loaded at runtime | Supported | examples/dynamic-worker-tails → |
| Containers | a container supervised by a Durable Object | Experimental | examples/container → |
celld deployreads your existingwrangler.jsonand stops on an unknown key instead of ignoring it.- Each KV namespace, D1 database, queue, and Workflow is a cell, with the same lease, SQLite database, LTX replication, and failover as a Durable Object. R2 bindings read and write objects directly in your bucket.
- A KV namespace and a queue each have one writer. Add namespaces or queues for write capacity.
- Out of scope: anything that needs Cloudflare's network, its GPUs, or a browser farm. Known gaps and differences are listed on the compatibility page →
How it works
Workers handle requests. Durable Objects, KV, Queues, D1, and Workflows keep their state in cells, each with its own SQLite database. Nodes share a bucket for durable storage, and a conditional bucket write assigns cell ownership. The fleet needs no membership protocol, failure detector, or consensus service.
One fleet, one bucket
celld instance A
JavaScript + SQLite per cell
- cell 1
- cell 2
- cell 3
- cell 4
- cell 5
& write replication
celld instance B
JavaScript + SQLite per cell
- cell 6
- cell 7
- cell 8
- cell 9
- cell 10
Any number of celld instances
Your shared bucket
Durable state for every cell
- cell 1
- cell 2
- cell 3
- cell 4
- cell 5
- cell 6
- cell 7
- cell 8
- cell 9
- cell 10
SQLite + LTX · ownership · deployments
S3-compatible · Google Cloud Storage · Azure Blob Storage
Reliability
celld keeps the Durable Objects programming model and gives you control over where cells run, how their state is stored, and how you investigate failures.
A review and an incident record about Durable Objects from July 2026.
The Orange Cloud Report scores Durable Objects 2 out of 10 for reliability
“technically impressive, operationally terrifying. Should have stayed an internal primitive.”
Cloudflare status: Durable Objects increased errors, major impact
What self-hosting changes:
Cells survive node loss
A cell belongs to whichever node holds its lease in your bucket. If that node fails, another acquires the lease through compare-and-swap and restores the cell from your storage in seconds.
A failure domain you choose
Your fleet still depends on its machines, network, and bucket provider. Cell scheduling and placement run within your fleet, separate from other customers' Durable Objects workloads.
Failures you can investigate
You can investigate a cell's failures through its ownership record, SQLite and LTX files, and logs, using tools like sqlite3 and grep.
Self-hosting puts you in charge of your nodes, bucket provider, and operations, but it doesn't guarantee reliability.
We love Cloudflare, and this very page runs on a Cloudflare Worker. The Durable Objects model is one of the best primitives distributed systems has gained in years: a single-threaded object with its own storage, addressed by name. That design belongs to Kenton Varda and the Cloudflare Workers team.
celld is a love letter to their idea; a primitive this good deserves to run anywhere.
A stateful distributed system built on S3.
LTX is Litestream's replica format, from Ben Johnson
