A bucket holds the fleet's state and authority
celld v0.5.0 runs Wrangler bundles on machines you control and gives stateful objects their own SQLite databases. The same cell model backs Durable Objects, KV, Queues, D1, R2, Workflows, and Cron Triggers. A bucket stores deployments, cell history, leases, and peer authentication material. That removes the need for a separate membership or consensus service, but it makes object storage the source of authority for the entire fleet.
One celld process runs on each node. A conditional bucket write assigns one owner to a cell, and an ownership epoch keeps a former owner from changing the current lineage. Committed SQLite changes travel as LTX data. The design is attractive because nodes remain replaceable and an idle cell does not need a permanent server. It also means correctness depends on storage semantics that many S3-compatible services do not provide.
The startup probe rejects unsafe object storage
celld requires 4 storage behaviors: conditional create, conditional overwrite, read-after-write consistency, and ranged reads. Its startup probe checks those properties and stops when a store ignores a condition or returns the wrong bytes. The guarantees document qualifies Amazon S3, Cloudflare R2, Tigris, Google Cloud Storage, and Azure Blob Storage. It explicitly says Backblaze B2, Hetzner Object Storage, and DigitalOcean Spaces cannot safely own cells because their conditional writes do not meet the contract.
A fleet with 2 running nodes can acknowledge through a follower that has synced the write to disk. With only 1 node, celld remains correct by waiting for the bucket proof, which adds a storage round trip. Operators also need a supervisor that restarts a process after it fences itself. That combination is sensible engineering, though it shifts the work from a managed platform into bucket qualification, restart policy, failure drills, and capacity planning.
What happened when we ran it
Our sandbox installed 423 Rust packages in 13 seconds. Building commit 12d5b63 succeeded in 445 seconds on the supplied 3 CPUs and 12 GB of RAM. The repository itself was 5.9 MB with 228 files and roughly 141,855 lines of source. Those figures make the dependency setup look easy and the compile step look expensive.
cargo test then succeeded in 55 seconds while reporting 0 passed, 0 failed, and 0 total tests. That result proves the command exited cleanly, not that behavior was exercised. Our scan found 1 CI workflow, a Dockerfile, and no tests directory. For a runtime that owns SQLite state and coordinates failover, zero discovered cases is a material gap in the evidence available from our run.
The internal network is part of the security boundary
celld opens 2 HTTP listeners. The public side serves the Worker, while the internal side carries peer traffic and operator controls. The project does not terminate TLS on either one. Its security guide requires a proxy or load balancer for public TLS and a private network or encrypted overlay for the internal route. Several internal operator endpoints do not authenticate requests, and the fleet HMAC authenticates selected peer operations without encrypting their traffic.
The default public request-body limit is 1 GiB, which is another value an operator should reduce where the application does not need it. Bucket credentials deserve tighter treatment still: the bucket contains deployments, state, leases, and the shared peer secret, so those credentials confer fleet control. celld is candid that application code, nodes, and operators are trusted together. It should not host customers who are meant to be isolated from each other.
One application per fleet is a hard alpha limit
Version v0.5.0 covers a wide portion of the Workers programming model, yet the compatibility document lists exact departures. A fleet serves 1 application and has no account service, multi-tenant scheduler, managed ingress, or Cloudflare edge metadata. wrangler.toml is rejected. Cache operations validate calls but store nothing, BroadcastChannel throws, and Node.js compatibility is partial. Products that rely on an undocumented corner need a focused migration test before committing state to the bucket.
Operations are young as well. Open issue 181 requests first-party listing, rollback, preview, and pruning for stored deployment versions. Issue 175 asks for permanent deletion of one cell and its replicated history. An open v0.5.0 report, issue 207, describes accepted cross-request work being discarded during event retirement, while carefully noting that the application stall link remains an inference and no standalone Worker reproduction exists. That report is a reason to test the relevant workflow, not proof that every asynchronous job will stall.
v0.5.0 is actively maintained and still alpha
Release v0.5.0 shipped on September 15, 2026, with fixes for cell recovery, database compaction, unfinished SQL writes, alarms, and WebSocket closing. GitHub showed 4,737 stars, 16 open issues, and a last source push on September 15 when fetched. Recent issues were also being closed within hours or days. That is active maintenance, although a fast repair cycle does not turn an alpha storage protocol into a settled production default.
The contribution path is another deliberate filter. The README asks contributors to email a focused git format-patch instead of opening pull requests, and our API check found 0 open PRs. That may protect maintainer attention, but it raises the effort for outside contributors. A team adopting celld should be ready to diagnose its own fleet and communicate at the level the project's detailed protocol documents expect.
A 445-second build is the smaller production cost
The long compile is inconvenient. The larger cost is accepting responsibility for 2 listeners, bucket correctness, node fencing, full-fleet upgrades, and compatibility testing. celld earns a serious trial when a trusted team wants one Workers application on its own infrastructure and can rehearse those failures. If the requirement is merely to run a Worker without managing distributed SQLite state, use the managed platform or a narrower runtime and leave the fleet protocol out of your incident queue.

