The part that got me is what celld doesn’t have. No control plane, no consensus service, no membership protocol, no failure detector, no join service. Nodes coordinate through an S3-compatible bucket using compare-and-swap on small ownership records, and that’s it. The bucket is the durable source of truth; nodes are replaceable. I have spent enough evenings babysitting a quorum to find that genuinely appealing.
The shape fits how I already build. Each object is its own SQLite database, addressed by name, replicated to a bucket I own — so sharding is structural rather than something I manage after the fact. Idle cells hibernate to nearly nothing, which matters when the box is a small always-on machine rather than someone else’s fleet. Point it at an R2 endpoint and the storage story stays familiar.
My caveat before anyone runs this on a boat’s LTE link: peer HTTP does not terminate TLS. Every advertised address belongs on a private network or a WireGuard/Tailscale overlay, and a literal public IP is rejected unless you pass --unsafe-public-advertise. Bucket credentials are fleet administrator access. I’d start with celld diagnose, read the limitations and security pages, and treat the whole thing as evolving — the README says so plainly.
The story — Deno Land has released celld, an open-source Apache-2.0 daemon that runs Cloudflare Workers and Durable Objects on your own machines. Each node embeds V8 and executes Wrangler bundles; the fleet shares an S3-compatible bucket holding deployments, cell state, and ownership leases. Pressure shedding is opt-in, pull requests are disabled in favour of emailed patches, and Linux x86-64 and ARM64 container images are published. (Source)