README

celld

Self-hosted, distributed Durable Objects.

celld is an open-source daemon that runs a Cloudflare Workers application
on your own machines: Workers, Durable Objects, KV, Queues, D1, R2,
Workflows, Cron Triggers, and static assets, deployed from the
wrangler.json that you already have. Each object is a cell: a named
server with its own SQLite database. celld stores the long-term state in
your S3-compatible, Google Cloud Storage, or Azure Blob Storage bucket.
It needs no serving control plane or consensus service.
An inactive cell costs almost nothing. Learn more at
celld.dev or read the
documentation.

 How it works

A node is one celld process, and you run one on each machine. Every
node embeds V8 and executes Wrangler bundles. The nodes that share one
bucket are a fleet, and that bucket holds the deployments, the cell
state, and small ownership records. A conditional bucket write gives a node the
ownership of a cell, so exactly one node owns a cell at a time. The fleet
needs no membership protocol, failure detector, or consensus service. Signed
peer HTTP provides routing and replicated-log transport.

celld captures each committed SQLite write in the LTX replication format.
A single node proves the write durable by uploading that data to the bucket. A fleet of two or more nodes proves it
sooner: the owner sends the data to one or two other nodes, and the write
is durable as soon as they hold it on their disks. celld uploads the data
to the bucket afterwards. A single node has no other node to send to, so
each write waits for the bucket, and those writes are much slower.
Before a takeover restores a cell, celld recovers an open log from the
prior owner, so the bucket holds the long-term state and nodes stay
replaceable. See what celld guarantees for the
complete protocol.

 What runs on celld

celld runs the programmatic Workers platform: the runtime, and each binding
that Cloudflare builds on Workers and Durable Objects. A KV namespace, a
queue, a D1 database, and a Workflow are each a cell, so
they get the same lease, the same replication, and the same failover as a
Durable Object. R2 bindings read, write, and list objects directly in the
fleet bucket. Each row links to a project that deploys as-is:

| service | example |
| --- | --- |
| Workers: fetch handlers, service bindings, JS RPC, Node.js compat | hello |
| Durable Objects: SQLite storage, alarms, hibernating WebSockets | counter |
| KV: list, metadata, expiration, bulk import | kv |
| Queues: producers, batching consumers, retries, dead letters | queues |
| D1: SQL databases, batches, migrations | d1 |
| R2: reads, writes, lists, multipart uploads | r2 |
| Workflows: durable steps, sleeps, events, pause and restart | workflow |
| Cron Triggers: one run for each occurrence across the fleet | cron |
| Static assets: asset-only or with a Worker, _headers, _redirects | static-assets |
| Dynamic Workers: runtime-loaded code and Tail Worker observability | dynamic-worker-tails |
| Conta