What celld is

celld is a stateful distributed system that runs server-side JavaScript on your machines and keeps all of its shared state in an S3-compatible, Google Cloud Storage, or Azure Blob bucket that you own. It is V8 + SQLite + LTX: the Cloudflare Workers runtime with Durable Objects as the stateful core, with the placement layer replaced by an object store. The JavaScript API it exposes is the same API that Workers and Durable Objects supply, so code written for one side generally runs on the other. celld's conformance tests run programs on workerd (the binary Cloudflare operates in production) and on celld, on identical bytes, and require equal output.

The founding idea is worth stating plainly. The Durable Objects model, a single-threaded object with its own storage, addressed by name, is one of the best primitives distributed systems has been handed in years. celld does not contest that. It moves placement, state, and operational evidence out of a shared vendor platform and into infrastructure you choose. The docs are explicit that self-hosting is not automatically more reliable; it makes the failure domain explicit and inspectable: your nodes, your bucket provider, and your operational choices.

If Durable Objects, actors, or durable execution are new to you, read Chapter 1 first: Actors, Durable Objects, and Durable Execution covers the platform and the ideas this part takes for granted.

This book describes celld v0.6.0 (released 2026·09·26), the first release celld calls a beta rather than an alpha. Where behavior changed between releases, the body states the current behavior and Appendix C records the change once, next to the upgrade rules.

TL;DR

Durable Objects is a strong programming model. celld keeps the model—a named object, one thread, its own SQLite—while moving the scheduler, the storage, and the failure domain onto your machines and your bucket.

Tip

Scope rule · as of v0.6.0

The compatibility line is: if Cloudflare builds a function on Durable Objects, celld can carry it. The compatibility page marks Workers, Durable Objects, facets, static assets, cron, Dynamic Workers, KV, Queues, D1, Workflows, and R2 all Yes, listing only the remaining differences, and marks Containers Experimental. Each service has its own page at celld.dev/docs/services, with a narrative, a worked example, and a short differences list. Out of scope is the platform surface that is not a Durable-Object building block: Workers AI (the experimental HTTP adapter was removed), Vectorize, Hyperdrive, Browser Rendering, Email, Python Workers, and BroadcastChannel. A configuration or binding that is not available must fail loudly, at deploy or first use; a silent gap is a bug.

Sources

This chapter draws on: celld: documentation at v0.6.0 (9 entries) · celld: release notes (5 entries) · Cloudflare documentation (4 entries). The full entries are in the Bibliography.