Deno ships celld, a self-hosted alternative to Cloudflare Durable Objects

Deno Land Inc. has released celld, an open-source daemon that runs Cloudflare Workers and Durable Objects on machines the operator controls, rather than on Cloudflare's own hosted infrastructure. Each Durable Object becomes its own SQLite database, addressed by name and continuously replicated to an S3-compatible bucket the operator owns; nodes coordinate through that bucket alone, with no separate control plane or consensus service. Because every object is a separate small database rather than a shared one, the documentation states that applications shard by construction, so the contention and blast-radius failures of a single shared database are avoided rather than merely managed. Idle cells, the project's term for a Durable Object instance, hibernate down to close to nothing.

Every node in a celld fleet embeds the V8 JavaScript engine and executes Wrangler bundles, the deployment format produced by Cloudflare's own Workers tooling. The fleet shares one S3-compatible bucket holding deployments, cell state and small ownership records; object-storage compare-and-swap operations against that bucket ensure that exactly one node owns a given cell at any time, without any membership protocol, failure detector or consensus service. Each cell's SQLite database is continuously replicated to the bucket, so when a cell moves to a new node or wakes from hibernation, the new owner restores that database from the bucket and resumes execution; the bucket, not any individual node, is the durable source of truth.

To install celld, an operator runs a curl script hosted at celld.dev, whose binary provenance can be verified with gh attestation verify, or pulls the published container image, ghcr.io/denoland/celld, built for Linux on x86-64 and ARM64. Deploying Worker code requires esbuild on PATH, though asset-only projects do not need it. The daemon uses the standard AWS credential environment variables and works against real AWS S3 or any S3-compatible service reached through --endpoint and --region, which the documentation illustrates with a Cloudflare R2 bucket. Running celld deploy publishes an application to the shared bucket, after which each node starts against that same bucket with its own --advertise address; a fleet runs exactly one application, and every node loads the latest committed deployment from a deploy/current.json file in the bucket. Nodes discover cell owners and peers purely from bucket leases, with no separate account or join service. The text names no license and no price.

An operator can run celld diagnose to enumerate every node lease in the bucket and perform a signed, direct probe of each live peer; the report distinguishes expired records, malformed or unsafe advertise addresses, unreachable peers and incompatible protocol versions, and it prints each node's resident-cell count together with WebSocket, RSS, CPU, file-descriptor, pressure and shedding figures. Pressure shedding, which lets an overloaded node hand its idle cells off to others once configured watermarks are crossed, is opt-in; the documentation's own example sets a high watermark of 1000 resident cells and a low watermark of 800 through the CELLD_MAX_RESIDENT_CELLS and CELLD_RESIDENT_LOW_WATER variables, with separate memory and CPU watermarks available on Linux, but it is explicit that these are illustrative, since the first release's safe default watermarks are still being measured. Under pressure, celld durably replicates and fences its least-recently-used idle cells, publishes them as unowned without resetting their epoch, and refuses to reacquire new unowned cells until the low watermark is reached again; a spare node receives no proactive assignment and instead acquires released cells through the same bucket protocol once ordinary traffic reaches it, and cells with active work or live host WebSockets are never shed.

Peer-to-peer HTTP traffic in celld does not terminate TLS, so the documentation instructs operators to put every advertised node address on a trusted private network or an encrypted overlay such as WireGuard or Tailscale, and not to publish the peer port directly; a literal public IP address is rejected as an advertise address unless the operator explicitly passes --unsafe-public-advertise. The first node to come up creates a fleet/peer-auth.json file in the bucket, and every peer request afterward is protocol-versioned, bound to its body, HMAC-authenticated, clock-bounded and replay-protected using that shared fleet secret. The documentation states plainly that access to the bucket and its credentials should be treated as equivalent to fleet administrator access.

The project describes its runtime and compatibility surface as still evolving. It is built and tested with cargo, including a locked clippy lint pass, and its versioned object-storage protocol lives in a file called crates/celld/protocol.rs, both signs the daemon is implemented in Rust. Its public automated tests are said to cover only the standalone engine's smoke path, while conformance against Workers and Durable Objects reference behavior and a deterministic fault-injection simulation of the distributed protocol are described as running before each release, without the text stating whether those two runs are part of the public suite. The project has also disabled pull requests, stating that coding agents make it too easy to submit large, low-context changes that cost maintainers more time than they save; contributions are instead accepted as git-format patches emailed to ry@deno.com, under a contributor agreement that assigns Deno Land Inc. the contributor's rights in the patch or, where a right cannot be assigned, grants the company a perpetual, irrevocable, worldwide, royalty-free, transferable and sublicensable license to use, modify, combine, relicense, redistribute or publish it, with or without attribution. No individual person is named in the text as celld's author, creator or maintainer; the address ry@deno.com and the company name Deno Land Inc. are the only identifiers given.

Key facts

Deno Land Inc. has released celld, an open-source, self-hosted daemon that runs Cloudflare Workers and Durable Objects on machines the operator controls; each Durable Object is its own SQLite database, replicated to an S3-compatible bucket the operator owns.
Nodes coordinate only through that shared bucket: object-storage compare-and-swap operations guarantee that exactly one node owns a given cell at a time, with no control plane, membership protocol, failure detector or consensus service.
Release images are published for Linux on x86-64 and ARM64 at ghcr.io/denoland/celld, and the daemon works against any S3-compatible bucket, including Cloudflare R2, reached through its --endpoint and --region flags.
Peer traffic does not terminate TLS, so the documentation requires every advertised node address to sit on a trusted private network or an encrypted overlay such as WireGuard or Tailscale; a literal public IP is rejected unless the operator explicitly passes --unsafe-public-advertise.
The project has disabled pull requests, citing the cost of reviewing large, low-context changes produced by coding agents; contributions are instead accepted only as git-format patches emailed to ry@deno.com under a CLA that assigns Deno Land Inc. the contributor's rights in the patch.

Why it matters

The stated goal of celld is to run the same Cloudflare Workers and Durable Objects programming model developers already use, but on infrastructure the operator controls rather than on Cloudflare's own hosted platform: compute nodes execute the code, and an S3-compatible bucket the operator owns holds all deployments and state, with nothing beyond that bucket coordinating the fleet. The design is presented as more than a thin wrapper: because each Durable Object is its own small database rather than rows in a shared one, the documentation states that applications shard by construction, avoiding rather than merely managing the contention and blast-radius failures a single shared database would carry.

Who it affects

Backend and infrastructure engineers already building on Cloudflare Workers and Durable Objects, who want to run the same code on machines they operate rather than exclusively on Cloudflare's hosted platform, are the direct audience; so are teams running multi-node fleets who want a coordination layer without standing up a separate consensus service. Deno Land Inc., the company that publishes celld, is also the entity named in the project's contributor agreement as receiving rights over any patch that gets emailed in.

How to use it

An operator installs celld with a curl script from celld.dev, whose binary provenance can be verified with gh attestation verify, or by pulling the published container image, ghcr.io/denoland/celld, built for Linux on x86-64 and ARM64. Deploying Worker code needs esbuild on PATH; asset-only projects do not. Setup uses the standard AWS credential environment variables and works against real AWS S3 or any S3-compatible service specified through --endpoint and --region, which the documentation demonstrates against a Cloudflare R2 bucket. Running celld deploy publishes an application to the shared bucket, after which each node starts against that same bucket with its own --advertise address; a fleet runs one application at a time, and every node loads the latest committed deployment from the bucket's deploy/current.json file. The text names no license and no price.

How solid is it

The documentation itself calls the runtime and its compatibility surface still evolving. The codebase is built and tested with cargo (cargo build --locked, cargo test --locked, cargo clippy --all-targets --locked), and its versioned object-storage protocol lives in crates/celld/protocol.rs, both signs the daemon is implemented in Rust; small example Wrangler projects under an examples directory exercise the supported Worker and Durable Object surface. Test coverage is described in layers: public automated tests cover only the standalone engine's smoke path, while conformance against Workers and Durable Objects reference behavior, plus a deterministic fault-injection simulation of the distributed protocol, are said to run before each release, without the text stating whether those two runs are part of the public suite. Operators get a live diagnostic view through celld diagnose, which probes every peer directly and distinguishes expired leases, malformed or unsafe advertise addresses, unreachable peers and incompatible protocol versions, alongside each node's resident-cell count, WebSocket, RSS, CPU, file-descriptor, pressure and shedding figures. The text gives no performance benchmarks, no cost figures and no adoption numbers, and it draws no direct comparison between celld and Cloudflare's own hosted Durable Objects.

Risks and caveats

Peer HTTP traffic does not terminate TLS, so the documentation requires every advertised node address to sit on a trusted private network or an encrypted overlay such as WireGuard or Tailscale, and it rejects a literal public IP as an advertise address unless the operator explicitly passes --unsafe-public-advertise. Every peer request is authenticated with a per-fleet HMAC secret that the first node writes to the bucket as fleet/peer-auth.json, and the documentation is explicit that access to the bucket and its credentials should be treated as fleet administrator access. Pressure shedding, which lets an overloaded node hand idle cells to others once resident-cell (or, on Linux, memory and CPU) watermarks are crossed, is opt-in: the documentation's own example sets a high watermark of 1000 resident cells and a low watermark of 800, but says plainly that the first release's safe default watermarks are still being measured, not fixed. Pull requests are disabled: the project states that coding agents make it too easy to submit large, low-context changes that cost maintainers more time than they save, and it accepts contributions only as emailed git-format patches under a CLA that assigns Deno Land Inc. the contributor's rights in the patch, or, where a right cannot be assigned, a perpetual, irrevocable, worldwide, royalty-free, transferable, sublicensable license to use, modify, relicense and redistribute it.

“Pull requests are disabled. Coding agents make it too easy to send a large, low-context change that costs maintainers more time than it saves.”

— the celld README