Run Cloudflare Workers on your own server without the cloud
Until now, using Cloudflare Workers required relying on the Cloudflare network. Now, installing celld on your computer or server lets you run Workers and Durable Objects locally using your existing wrangler.json configuration. celld is a daemon that maintains applications by having distributed nodes synchronize state with each other, requiring only S3-compatible storage and no central cloud management server.
Distributed structure without a central server
Each node embeds the V8 engine to execute Wrangler bundles directly. Nodes share a single bucket where they store deployment information, cell state, and ownership records. When a specific node writes a conditional record to the bucket, it gains ownership of that cell, ensuring that only one node owns a cell at a time. This eliminates the need for complex infrastructure like membership protocols or consensus services. Routing between nodes and log transmission are handled via signed peer HTTP.
Data persistence and replication
Celld captures SQLite committed write operations in LTX replication format. On a single node, writes are only considered complete after data is uploaded to the bucket, which is slow. However, with two or more nodes, the owning node sends data to one or two other nodes, and the write is considered complete once those nodes save it to disk. A backup is then uploaded to the bucket. If a node is replaced, long-term state remains in the bucket, and the previous owner's open logs are recovered, allowing cells to be restored without data loss.
Supported service scope
Celld supports the programmatic runtime and bindings of the Cloudflare Workers platform. KV namespaces, queues, D1 databases, and workflows are all treated as cells, providing the same lease, replication, and failover capabilities. R2 bindings read and write objects directly from the fleet bucket. Static assets, cron triggers, dynamic workers, containers (experimental), and sandboxes are also supported. However, products requiring the Cloudflare network, GPU, or browser farms are not supported.
Installation and execution
Running the installation script downloads the celld binary, and you can verify its origin using gh attestation verify. Local development starts with the celld dev command and operates with local object storage, without Docker or cloud buckets. For production deployment, upload to the bucket with celld deploy and then run the celld daemon. It supports S3, Google Cloud Storage, and Azure Blob Storage, using the AWS credential chain as standard. Container images are provided for Linux x86-64 and ARM64.
Operational considerations
If write latency is critical, you must run two or more nodes. The second node discovers other nodes via the bucket without additional configuration. When memory pressure reaches 80%, Celld replicates and releases the oldest idle cell to free up memory. The V8 heap limit is 128MB by default, and exceeding it causes new hibernatable WebSockets to be rejected. Peer HTTP and the operator API use internal listeners, so advertised addresses must be placed on an encrypted overlay like WireGuard or Tailscale, or a trusted private network. Using a public IP requires the --unsafe-public-advertise flag. Bucket access permissions are equivalent to fleet administrator privileges, so credentials must be managed strictly.
