Deno Land, led by Ryan Dahl, the creator of Node.js and Deno, has released "celld," an open-source foundation that runs Cloudflare Workers and Durable Objects code on a self-managed fleet of servers. Version v0.1.0, dated August 5, 2026, gives each object a V8 execution environment and SQLite, and even handles ownership transfer across multiple nodes. This means that the stateful computation model, which was previously tightly coupled with Cloudflare's managed infrastructure, has now emerged as an Apache-2.0 implementation available externally. However, celld hasn't eliminated the inherent difficulty of distributed systems. It has simply shifted the authority that determines placement and durability from Cloudflare's internal infrastructure to the user's own object storage and operational practices.
Filling the Gap Left by workerd
Cloudflare has already open-sourced "workerd," the execution engine for Workers. Using workerd, you can run Workers-targeted JavaScript or WebAssembly on your own machine, and even experiment with Durable Objects on local disk. However, the official README explains that this remains a single-node implementation where Durable Objects run on the same machine as the requester, and that distributed placement—determining which of multiple machines should host an object with a given name—is not implemented.
This is precisely the operational layer that celld fills. Applications divide entities such as users, documents, chat rooms, or AI agents into named units called "cells." Each cell runs its code in a single-threaded V8 isolate and has its own dedicated SQLite database. Since all processing for a given cell converges on a single owning node at any time, applications don't need to build locking mechanisms or handle contention on a shared database each time.
The idea is to achieve both fast read/write performance and manageable distributed behavior by drawing boundaries at the cell level. An active cell reads its SQLite database synchronously as a local library, and it's evicted from memory once dormant. According to official fixed-host measurements, requests to an active cell had a median latency of about 1.1 milliseconds and a 99th percentile of about 7 milliseconds. Meanwhile, persisted state is replicated to a shared bucket in LTX (Lite Transaction File) format. Even if a node is lost, another node can restore the same cell.
S3 Determines Ownership
The most distinctive aspect of celld's design is that, rather than deploying a dedicated consensus service or a fixed membership table, it uses an Amazon S3 (Simple Storage Service)-compatible or Google Cloud Storage bucket as the coordination mechanism. For each cell, a single ownership record is stored; if the record doesn't exist, it's created conditionally, and if it does exist, it's acquired via CAS (compare-and-swap) against the previous value. Since only one conditional write can succeed, this prevents two nodes from acquiring the same cell simultaneously. Merely being labeled "S3-compatible" isn't sufficient, however. celld requires the bucket to support conditional creation and conditional overwrite, as well as read-after-write consistency that returns the same value immediately after a write. The official documentation lists Amazon S3, Cloudflare R2, Google Cloud Storage, Azure Blob Storage, and Tigris as qualifying. MinIO Community, Backblaze B2, Hetzner Object Storage, and DigitalOcean Spaces do not meet the conditional-write requirement and cannot be used in distributed configurations.
Ownership is tagged with an epoch (generation number). When a cell moves to a different node, the epoch advances, and the new owner writes LTX segments under a new prefix. Even if an old node keeps running due to a network partition, its writes remain under the old epoch and don't corrupt the new lineage. Furthermore, during recovery, a marker called an "epoch seal" fixes the last readable transaction, ensuring that a node that lost ownership can't later resurrect unacknowledged data it added afterward.
There's also a safeguard on responses returned to clients. celld replicates SQLite updates to the shared bucket and re-verifies that the ownership record still points to the same node and epoch before returning a success response. This mechanism, called the "output gate," is enabled by default, and when using a bucket that satisfies the conditions described above, it aims to achieve an RPO (Recovery Point Objective) of 0—meaning acknowledged writes won't be lost even if a node fails. The tradeoff is that the minimum latency for durable writes becomes one round trip to the bucket. The roughly 90-millisecond intra-region latency featured on the official homepage is orders of magnitude slower than local SQLite reads.
Cloudflare's own platform likewise keeps SQLite locally while shipping change logs elsewhere, though the durability path differs. Cloudflare's Storage Relay Service sends each transaction to five follower nodes and releases the response after three acknowledgments. Transfers to object storage are batched at a maximum of 10 seconds or 16MB. celld doesn't use a Cloudflare-scale follower network; instead, it conditions responses on reaching a bucket chosen by the user. The price paid for this operational simplification shows up as write latency and dependency on bucket quality.
The $415 vs. $48 Premise
celld claims to be "dramatically cheaper at scale." The comparison starts from Cloudflare's official pricing example of running 100 Durable Objects continuously for a month. Under a condition of receiving one WebSocket message per second, this comes to $416.51 per month. On celld's side, the project cites its own measurement claiming that up to 2,500 lightweight cells can be placed on a single $48-per-month 8GB DigitalOcean node. At full capacity, that works out to roughly $0.0192 per cell per month—displayed as approximately $0.02. However, while the official homepage states 2,500 cells, the comprehensive documentation states 1,000 cells for the same 8GB node, at roughly $0.05 per cell per month. Even within the project's own documentation, the density figures don't agree.
| Condition | Cloudflare Durable Objects | celld |
|---|---|---|
| 100 objects running continuously all month | $416.51/month | Base cost is $48/month node |
| Only 100 cells hosted on an 8GB node | No equivalent example | Roughly $0.48/month per cell |
| 2,500 cells filling an 8GB node | Billed based on execution time | Roughly $0.0192/month per cell |
| Official example using WebSocket Hibernation while dormant | 100 objects, 100 connections each: $10.00/month | Claims near-zero bucket operations for inactive cells |
What this table reveals is that the price difference flips depending on utilization rate and density. celld's $48/month base cost is incurred upfront whether you have 100 or 2,500 cells, with networking, write, and bucket fees added on top. In response to The Register, Cloudflare noted that the $415 figure applies only when all objects run continuously, and that letting them go dormant brings the estimate down to $20.65. Cloudflare's public pricing page also includes an example where 100 objects each maintain 100 hibernation-capable WebSocket connections, with each client sending once per minute, resulting in $10.00 per month.
Therefore, celld's strength lies in environments where many cells are kept continuously in memory and node capacity is utilized at a high rate. For services with sparse access patterns and long dormancy periods, Cloudflare's usage-based billing combined with WebSocket hibernation may well undercut the base server cost. Furthermore, celld's claimed density of 2,500 cells was measured using lightweight cells on Apple M-series hardware, and capacity will decrease as an application's memory footprint grows. Given the 1,000-versus-2,500 discrepancy even within the official documentation, this capacity figure shouldn't be treated as a guaranteed value. Before consulting the pricing table, one needs to measure actual utilization rate and per-cell memory usage.
Operational Boundaries to Check Before Compatibility
celld is not a product that replicates the entire Cloudflare platform. At present, Module Workers and fetch work, along with JavaScript RPC and service bindings. On the Durable Object side, it supports static assets, SQLite, the alarm API, and hibernation-capable incoming WebSockets. D1, Workflows, and Queues are still in the planning stage. KV, R2 bindings, and the Cache API are out of scope, and Workers AI, Vectorize, and Hyperdrive are not included either. Cron jobs, custom domains, and TLS termination must all be handled independently.
Seams also remain in API compatibility. Response.redirect(), ReadableStream.from(), setInterval, and HTMLRewriter are not implemented, and some Node.js modules and TCP sockets can be imported but exist only as stubs that perform no actual processing. Wrangler configuration is limited to JSON or JSONC—TOML is not accepted. While the official documentation states a policy of stopping with an explicit error whenever an unsupported setting is encountered, it also lists known areas that silently fail to work. The extent to which existing code can be moved "as-is" can only be determined by cross-checking the bindings and execution APIs actually in use.
The scope of security responsibility borne by operators is also substantial. celld is in alpha and is not safe for multi-tenant use cases involving co-located adversarial code. Inter-node communication includes HMAC and body signatures along with time restrictions and replay prevention, but it does not terminate TLS. Some internal listeners expose unauthenticated operational APIs, so a closed network or an encrypted overlay such as WireGuard or Tailscale is assumed as a prerequisite. Operators must also provide their own authentication for external users, public TLS, and an ingress proxy.
The credentials for the shared bucket carry more weight than a mere backup key. They hold deployment artifacts and SQLite replicas, along with ownership records, node leases, and peer-authentication private keys. Whoever holds these credentials can control the entire cluster, so celld recommends scoping permissions to a single cluster only. Additionally, one cluster runs exactly one application—there is no central placement controller and no automatic rebalancing. The sovereignty gained through self-hosting comes with the corresponding responsibility for capacity planning, monitoring, key rotation, and recovery drills.
Who Should Choose celld?
Regarding fault tolerance, celld has published a three-tier testing approach: matching input/output comparisons against workerd, deterministic simulations injecting clock skew and contention, and fault injection on real clusters. In an official test, 10 nodes with 4 vCPUs and 8GB of memory each hosted 10,000 cells and 20,000 WebSocket connections; after stopping two nodes, with spare capacity available, even the slowest cell reportedly became reachable from another node within about 11 seconds. While this supports the soundness of the design, it is not a guaranteed figure reproduced by a third party under production workloads.
celld is likely best suited for teams that want to control the location of their data and failure domains themselves, and who want to directly inspect SQLite files and ownership records. If you're already operating virtual machines, object storage, and a closed network, and you're running many persistent AI agents or chat rooms at high density, you can control both cost and placement while retaining Cloudflare-compatible code. On the other hand, for services with sparse access patterns, or for organizations that want a small team to hand off worldwide ingress and TLS, multi-tenant isolation, and monitoring to a managed provider, Cloudflare's managed Durable Objects remains the more sensible choice.