mrkeyoor.com_
Thu 17 Sept 17:41 UTC
Self-Hostedevaluationupdated 17 Sept 2026

celld review

celld is a self-hosted runtime for running Cloudflare Workers applications and stateful Durable Objects on your own machines. It also implements services such as KV, Queues, D1, R2, Workflows, and Cron Triggers, storing durable state in a bucket you control.

Verdict

Our celld build took 445 seconds, and its 55-second cargo test run discovered 0 tests, so v0.5.0 asks operators to assess a young distributed-state system without executed test coverage from our run. Try it for a controlled single-application fleet when Cloudflare compatibility is valuable and your team can own the bucket, proxy, private network, and recovery drills. Do not use this alpha as a hostile multi-tenant boundary or assume its API surface matches Cloudflare in every detail.

We ran it

Lab card: what happened when we ran celldScreenshot of celld (celld.dev)
Install✓ · 13s423 packages
Build✓ · 445s
Tests✓ · 55s0 passed · 0 failed of 0 (cargo test)
Repo228 files~141,855 lines of source · 5.9 MB · 1 CI workflows · Dockerfile

Answers from our run

Does celld build from source?

Dependencies installed in 13 seconds (423 packages), and the build succeeded in 445 seconds. We cloned commit 12d5b63 into a clean Debian container with 3 CPUs and no project-specific setup.

Do celld's tests pass?

Yes: 0 of 0 passed when we ran the project's own test command (cargo test). Some failures need services or credentials a bare container does not have.

Who should not use celld?

Hosts running mutually untrusted customer code: the security guide says the alpha is unsafe for hostile multi-tenant use and trusts the application.

What are the alternatives to celld?

workerd, Workers SDK, Spin. Our celld build took 445 seconds, and its 55-second cargo test run discovered 0 tests, so v0.

Setup2/513-second install, 445-second build, and substantial fleet work
Docs5/5Guarantees, security boundaries, and API gaps are unusually clear
Community3/54,737 stars and active issues, but patches use an email workflow
Maturity2/5v0.5.0 is alpha, and our cargo test run found zero tests

Who it’s for

Teams with an existing Wrangler application that need to run it outside Cloudflare's managed network.
Infrastructure engineers comfortable operating object storage, private service networks, proxies, and restart supervisors.
Developers who want local Durable Objects work through celld dev without starting Docker or creating a cloud bucket.
Organizations that can dedicate one trusted fleet to one application and test every Cloudflare API their code uses.

Who it’s NOT for

Hosts running mutually untrusted customer code: the security guide says the alpha is unsafe for hostile multi-tenant use and trusts the application.
Teams seeking a drop-in copy of Cloudflare's full platform: wrangler.toml and routes are rejected, Cache always misses, and several runtime APIs are partial or unavailable.
Operators who cannot isolate the internal listener on a trusted or encrypted network: peer traffic is plaintext HTTP, and several operator routes have no request authentication.
Windows users or Intel Mac users expecting a supplied binary: releases cover Linux x86-64, Linux ARM64, and Apple Silicon, while Windows is unsupported.
Products that require a supported permanent purge for one Durable Object today: open issue 175 says replicated cell history has no complete deletion path.
Teams that need a painless rolling upgrade from v0.4.1: the v0.5.0 instructions require stopping every old node, and mixed versions cannot serve one fleet.

Setup reality

Our sandbox installed 423 Rust packages in 13 seconds. The build succeeded in 445 seconds, then cargo test completed in 55 seconds with 0 passed and 0 failed out of 0. The checkout held 228 files, about 141,855 source lines, and 5.9 MB. It had 1 CI workflow, a Dockerfile, and no tests directory.

Local development can use celld dev without Docker or a cloud bucket, though Worker deployment needs esbuild on PATH. A serving fleet needs S3-compatible storage, Google Cloud Storage, or Azure Blob Storage plus credentials. Production also needs a load balancer or proxy, TLS termination, private routing, and a supervisor that restarts fenced nodes.

One node waits for the bucket before acknowledging writes. Two or more nodes can use follower durability. The internal listener must stay off the public internet, and bucket credentials amount to fleet administrator access. Version v0.5.0 is an alpha and cannot share a fleet with older binaries during its required stop-all-nodes upgrade.

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.

Alternatives

ProjectWhat it isPick it when
workerdCloudflare's open-source JavaScript and WebAssembly runtime for Workers.pick this instead when you need the underlying Workers runtime and will build your own storage and distribution layer.
Workers SDKThe repository for Wrangler and Cloudflare's local Workers development tools.pick this instead when official local development and managed Cloudflare deployment matter more than self-hosting.
SpinA serverless WebAssembly framework for building and running portable applications.pick this instead when portable WebAssembly services matter more than Workers and Durable Objects compatibility.

What people are saying

  1. [github-trending] denoland/celld

Sources

  1. celld README
  2. What celld guarantees
  3. celld security guide
  4. celld limitations
  5. Cloudflare compatibility
  6. celld v0.5.0 release
  7. Open issue 207 on cross-request work
  8. Open issue 181 on deployment lifecycle

More self-hosted reviews

EchoMuse · versitygw · Octop · newsnow · forem · octo-server · the whole board →