celld is an open source, self-hosted implementation of Cloudflare Workers and Durable Objects created by Ryan Dahl, released as version 0.1.0 under Apache 2.0. It runs on your own VMs using V8 for JavaScript execution, one SQLite database per Durable Object (called a 'cell'), LTX for SQLite replication, and an S3-compatible bucket as both storage and coordination layer — eliminating the need for a separate control plane, Raft cluster, or consensus service. Key performance benchmarks include ~4 MB RAM per resident cell, ~1,000 resident cells on an 8 GB node, ~4 ms cell wake time, ~90 ms durable write latency, and ~20 second failover. The post provides a thorough architectural breakdown, code examples using the familiar Durable Objects API, an honest cost comparison with Cloudflare's managed offering, and a candid assessment of current alpha limitations including missing APIs (KV, R2 bindings, Queues, Cron Triggers) and security constraints around multi-tenant workloads.
Table of contents
First, what is a Durable Object?What is a cell?The complete architectureWhat happens during a request?Why celld does not need a control planeHibernation changes the cost modelThe cost claim needs contextA tiny celld applicationWhat runs unchanged?This is not Cloudflare on your own serverThe architecture I find most interestingI could rebuild Events Logger around cellsFactory Log could gain optional private syncWaiting Lists could isolate every listSitebase is almost designed for this modelI would not rebuild everything with celldHow I would test celldWhat I like about the projectWhat would stop me from using it todayA very good architecture experimentQuestions this post answers
How does celld handle distributed coordination without a Raft cluster or control plane?
celld uses an S3-compatible object storage bucket as both storage and coordinator. Nodes write leases to the bucket and discover peers through it. Cell ownership is a conditional compare-and-swap write in the bucket — whichever node wins the write owns the cell. If a node disappears, its lease expires and another node claims the cell, restores the SQLite state from the bucket, and continues. No separate membership system or consensus service is needed. Developers building distributed stateful systems without managed infrastructure track architectural patterns like this on daily.dev.
What are the performance benchmarks for celld 0.1.0?
celld 0.1.0 reports approximately 4 MB of RAM per resident trivial cell, around 1,000 resident cells on a single 8 GB node, about 4 ms to wake a hibernated cell on a local benchmark machine, around 90 ms for a durable region-local write, and roughly 20 seconds for failover after killing a node. A separate test with ten 4-vCPU/8 GB nodes held 10,000 resident cells and 20,000 WebSocket connections, recovering all cell data in about 11 seconds after two nodes failed. Engineers evaluating self-hosted stateful runtimes find benchmark comparisons like these worth following on daily.dev.
What Cloudflare Workers APIs does celld support and what is out of scope?
celld supports module Workers with fetch, Durable Objects with SQLite storage, alarms, inbound and outbound WebSockets, service bindings, JavaScript RPC, static assets, common Web Platform APIs, part of Web Crypto, and part of the Node.js compatibility layer. Out of scope are KV, R2 bindings, Cache API, Workers AI, Vectorize, Hyperdrive, Browser Rendering, Email, Cron Triggers, custom domains, and TLS termination. wrangler.toml is also unsupported; only wrangler.json and wrangler.jsonc are accepted. Developers migrating Workers projects off Cloudflare watch compatibility gaps like these on daily.dev.