celld is an open-source daemon that runs a Cloudflare Workers application on machines you own: Workers, Durable Objects, KV, Queues, D1, R2, Workflows, Cron triggers and static assets, deployed from the wrangler.json you already have. It comes from the Deno project, is Apache 2.0, and has picked up around five thousand stars since it appeared.
The architecture is the argument
Each object is a cell: a named server with its own SQLite database. The fleet coordinates through a bucket you provide, S3-compatible or Google Cloud Storage or Azure Blob, rather than through a control plane or a consensus service. A conditional write to that bucket grants a node ownership of a cell, so exactly one node owns each cell at a time, and that is the entire coordination story: no membership protocol, no failure detector, nothing to keep alive. Signed peer HTTP carries routing and replication, and committed SQLite writes are captured in the LTX replication format.
Durability follows the same shape. A single node proves a write durable by waiting for the bucket, which the documentation admits is much slower. A fleet of two or more nodes proves it sooner: the owner hands the write to one or two peers, and it is durable as soon as they hold it on disk, with the bucket upload following. When a node takes over a cell, it first recovers the open log from the previous owner, so the bucket holds the long-term state and nodes stay replaceable. An inactive cell costs almost nothing, which is the economics you want for a fleet of small objects.
What runs, and what does not
The supported surface is the programmatic Workers platform: fetch handlers, service bindings, JavaScript RPC and Node compatibility; Durable Objects with SQLite storage, alarms and hibernating WebSockets; KV, Queues with dead letters, D1 with migrations, R2 with multipart uploads; Workflows with durable steps; and Cron triggers that fire once per occurrence across the whole fleet. Containers and the Sandbox SDK are marked experimental. Out of scope, by the project’s own list: anything that needs Cloudflare’s network, a GPU, or a browser farm. The compatibility page lists every gap honestly, which is more than most reimplementation projects manage.
Installation is a script whose provenance can be verified against its GitHub attestation, or a container image for x86-64 and ARM64. Deploys need esbuild on the path; releases live under a versions directory behind a single symlink.
My read
The interesting move is where the coordination went: the bucket is the only shared state, so there is no cluster to operate and no quorum to babysit, and idle cells are nearly free. That is a genuinely different shape from the usual self-hosted control plane, and it fits the Workers model well. The open question is compatibility, because imitating a fast-moving platform is a long road, and the docs are candid about the distance left. For anyone who likes the Workers programming model and does not want the vendor attached, this is the closest middle path yet.
Source: the repository.