Run celld fleets on Kubernetes

Local storage requires the celld fork

If you use celld with persistent local storage (PersistentFleet), you must use the ewhauser/celld fork. It never counts an unreachable peer as holding no copy of a write, and it lets an idle leader stop depending on a departed member; stock upstream celld does neither. All runtime and recovery nodes must use a compatible fork. The fork is also required for Bucket fleets. See compatibility for the required release and image digest.

From a manifest to a working application

celld runs stateful JavaScript applications using durable cells. The operator manages the Kubernetes fleet that hosts them. You supply the cluster, an S3 bucket, runtime AWS permissions and a compatible fork image; the operator creates the workloads, Services, and network policies.

1. Prepare your cluster and its storage and permissions.
2. Install the operator and create a fleet.
3. Run your first application and check its response.

Already running a fleet?

I want to…	Start here
Add or remove replicas	Scale a fleet
Respond to changing demand	Enable capacity policy
Restart or upgrade	Restart a fleet · Upgrade the runtime
Check health or investigate a problem	Monitor a fleet · Troubleshoot
Stop a fleet and understand what remains	Delete a fleet

Choose storage for your workload

Bucket uses S3 for durable writes and temporary local disk. PersistentFleet adds retained CSI disks and peer-disk durability. The choice affects setup, maintenance, and recovery: compare the profiles before creating a fleet.

For configuration fields, see the Fleet API and Helm values. To work on the operator itself, start with Contribute.