celld is an open-source daemon that runs Cloudflare Workers and Durable Objects on your own machines. Each object — called a cell — is a small server with a name and its own private SQLite database. celld addresses a cell by name and continuously replicates its database to a bucket that you own. That bucket can be an S3-compatible store (from the list of qualified providers) or Google Cloud Storage. Nodes coordinate through the bucket alone — there is no control plane, no membership protocol, and no consensus service. Because every cell is its own isolated database, your application shards by construction: contention and cascading failures from a single shared store are designed out from the start, not managed after the fact.Documentation Index
Fetch the complete documentation index at: https://mintlify.com/denoland/celld/llms.txt
Use this file to discover all available pages before exploring further.
celld is currently in alpha. Before operating a public fleet, review the
known limitations.
How it works
Every celld node embeds V8 and executes Wrangler bundles. All nodes in a fleet share one bucket, which contains deployments, cell state, and small ownership records. Bucket-based coordination. The bucket is the sole coordinator. A node claims ownership of a cell by performing an atomic, conditional write (a compare-and-swap) against the ownership record in the bucket. This guarantees exactly one owner at a time without any membership protocol, failure detector, or consensus service. Every node discovers peers and ownership records through leases stored in the bucket. To add a node, you simply point it at the same bucket — there is no join command. Durable replication with RPO=0. celld continuously replicates each cell’s SQLite database to the bucket and does not acknowledge a write until the data is durably stored. The loss of a node therefore cannot lose an acknowledged write. When a cell moves or an inactive cell activates, its new owner downloads the database from the bucket and resumes execution. The bucket is the durable source of truth; individual nodes are fully replaceable. No control plane. There is no separate controller, scheduler, or account service. Conditional writes — the same primitive that object stores expose for safe multi-writer access — give a node ownership of a cell. The store must provide conditional writes and read-after-write consistency for the ownership protocol to hold.Cell lifecycle
A cell passes through well-defined states as traffic and memory pressure change:| State | Description |
|---|---|
| Resident | The cell is in memory on a node. This is the umbrella state that covers both active and idle. |
| Active | The cell is in memory and doing work — handling a request, running an alarm, or serving a WebSocket message. |
| Idle | The cell is in memory but waiting. celld removes an idle cell from memory. |
| Hibernated | The cell has left memory but retains its hibernatable WebSocket connections and stays assigned to its node. The constructor runs again on the next event, exactly as a cold start does, but the WebSocket clients remain connected. |
| Inactive | No node holds the cell. It exists only as an object in the bucket and costs almost nothing. Every cell starts in this state and returns to it when it is shed under memory pressure or when its node stops. |
What you can build
Cells are a natural fit for any workload that divides into named, stateful units. Each cell holds all the state for one entity in its own SQLite database, and an idle cell hibernates to the bucket at near-zero cost.Real-time applications
A multiplayer game, a chat room, or a collaborative document lives in one
cell. The cell holds the WebSocket connections and the shared state for one
room, so the room needs no external lock and no message bus.
AI agents
Each AI agent is one cell. The cell stores the agent’s memory, schedule,
and inbox in its own SQLite database. An idle agent hibernates to the
bucket, so a large agent fleet costs nearly nothing between events.
Sharded web applications
One cell per user, tenant, or device shards the application from the
start. Because no shared database exists, the contention and blast-radius
failures of a single shared store simply do not appear.
Supported storage backends
The store must provide conditional writes and read-after-write consistency — the ownership and fencing protocol depends on both. Qualified stores:- Amazon S3
- Cloudflare R2
- Google Cloud Storage
- Azure Blob Storage
- Tigris
gs:// bucket prefix. celld uses the Cloud
Storage XML API with generation preconditions. Authentication uses Application
Default Credentials, or you can point GOOGLE_APPLICATION_CREDENTIALS at a
service-account key. A gs:// bucket takes no S3_ENDPOINT and no AWS_*
credentials.
Stores that do not qualify: MinIO (community edition), Backblaze B2,
Hetzner, and DigitalOcean Spaces do not provide the required
conditional-write semantics.
A bucket value can include a key prefix — for example,
s3://YOUR-BUCKET/PREFIX — so two fleets can share a single bucket without
their objects colliding.