Celld: Self-hosted, distributed Durable Objects Uh oh! Ther | Coderz Club

Celld: Self-hosted, distributed Durable Objects Uh oh! There was an error while loading. Please reload this page. denoland / celld Public Notifications You must be signed in to change notification se

Celld: Self-hosted, distributed Durable Objects Uh oh! There was an error while loading. Please reload this page. denoland / celld Public Notifications You must be signed in to change notification se

By Coderz Club · 2026-08-06 · Tags: git

Celld: Self-hosted, distributed Durable Objects

Uh oh! There was an error while loading. Please reload this page. denoland / celld Public Notifications You must be signed in to change notification settings Fork 25 Star 1k mainBranchesTagsGo to fileCodeOpen more actions menuFolders and filesNameNameLast commit messageLast commit dateLatest commit History3 Commits3 Commits.github/workflows.github/workflows cratescrates docsdocs examplesexamples .gitignore.gitignore Cargo.lockCargo.lock Cargo.tomlCargo.toml DockerfileDockerfile LICENSELICENSE README.mdREADME.md View all filesRepository files navigationcelld Self-hosted, distributed Durable Objects. celld is an open-source daemon that runs Cloudflare Workers and Durable Objects on your own machines. Each object is its own SQLite database, addressed by name and replicated to an S3-compatible bucket you own; nodes coordinate through that bucket alone, with no control plane or consensus. Because every object is its own small database, applications shard by construction — the contention and blast-radius failures of one shared database are designed out, not managed. Idle cells hibernate to nearly nothing. Learn more at celld.dev or read the documentation. How it works Every celld node embeds V8 and executes Wrangler bundles. The fleet shares an S3-compatible bucket containing deployments, cell state, and small ownership records. Object-storage compare-and-swap ensures that exactly one node owns a cell at a time, without a membership protocol, failure detector, or consensus service. celld continuously replicates each cell's SQLite database to the bucket. When a cell moves or wakes up, its new owner restores that database and resumes execution. The bucket is the durable source of truth; nodes are replaceable. Install The installer downloads the celld binary (provenance is verifiable with gh attestation verify): curl -fsSL https://celld.dev/install.sh | sh Put ~/.local/bin on your PATH if the installer asks you to. Worker projects deployed with celld deploy need esbuild on PATH; asset-only projects do not. The installer keeps verified releases under ~/.local/lib/celld/releases and atomically switches one current pointer. To remove celld, use the guarded uninstaller: curl -fsSL https://celld.dev/uninstall.sh | sh Container The release image contains the celld binary and is published for Linux x86-64 and ARM64: docker run --rm ghcr.io/denoland/celld --version Persist the runtime's local state and pass the standard AWS credential environment through: docker volume create celld-state docker run --rm --network host \ -e AWS_ACCESS_KEY_ID \ -e AWS_SECRET_ACCESS_KEY \ -e AWS_SESSION_TOKEN \ -e CELLD_WATCH=/var/lib/celld/state \ -v celld-state:/var/lib/celld \ ghcr.io/denoland/celld \ --bucket s3://my-cells-bucket \ --endpoint https://ACCOUNT.r2.cloudflarestorage.com \ --region auto \ --listen 0.0.0.0:8080 \ --advertise node-a.internal:8080 Drop --endpoint/--region for real AWS S3. Behind a load balancer, give each node a distinct --advertise its peers can reach. Run it celld uses the standard AWS credential chain. Deploy to an S3-compatible bucket, then start celld against the same bucket: celld deploy . \ --bucket s3://my-cells-bucket celld \ --bucket s3://my-cells-bucket \ --listen 0.0.0.0:8080 \ --advertise 10.0.0.12:8080 Use --endpoint for another S3-compatible service and --region when it cannot be inferred. A fleet runs one application, and every node loads its latest successfully committed deployment from deploy/current.json. Run celld --help for the complete command line. Deployment objects use the documented types in crates/celld/protocol.rs. celld deploy invokes esbuild from PATH for Worker code, accepts the supported Wrangler config subset—including co-deployed or asset-only static assets—and writes those objects directly. Every node discovers owners and peers from bucket leases; there is no account or join service. Peer HTTP does not terminate TLS. Put every advertised address on a trusted private network or an encrypted overlay such as WireGuard or Tailscale; do not publish the peer port directly. A literal public IP is rejected unless --unsafe-public-advertise is supplied explicitly. The first current node creates fleet/peer-auth.json in the bucket. All peer requests are protocol-versioned, body-bound, HMAC-authenticated, clock-bounded, and replay-protected with that fleet secret. Treat access to the bucket and its credentials as fleet administrator access. Operate a fleet celld diagnose enumerates every node lease by default, then performs a signed direct probe of each live peer: celld diagnose --bucket s3://my-cells-bucket The report keeps checking after an individual failure and distinguishes expired records, malformed or unsafe advertise addresses, unreachable peers, and incompatible protocols. It also prints each node's coarse resident-cell, WebSocket, RSS, CPU, file-descriptor, pressure, and shedding sample. Pass one or more --peer NODE_ID options to rest

View this page on Coderz Club