celld

Xicar uses celld as a stateful execution and coordination layer. It is not the canonical store for long-lived business records: PlanetScale Postgres remains the system of record for business data, while application-specific object storage remains the home for uploads and business blobs.

The celld fleet bucket is separate infrastructure storage. It holds celld deployment state, ownership metadata, LTX durability data, and runtime-managed objects.

Deployment profiles

Xicar standardizes on two celld deployment profiles.

Profile	Light	Fleet
Nodes	1	2 minimum, 3 preferred
Durability	`CELLD_DURABILITY=bucket`	`CELLD_DURABILITY=fleet`
Local state	Ephemeral is acceptable	Persistent local volume per node
Write acknowledgement	Bucket proof	Follower proof or bucket proof
R2 latency on write path	Yes	Usually avoided when followers are healthy
Best fit	Lower-write services	Write-heavy or latency-sensitive services

A service should normally start with the light profile when its write volume is modest and operational simplicity matters more than write latency. Graduate it to the fleet profile when R2 latency, Class A operation pressure, availability, or sustained write volume becomes material.

Data boundaries

Keep these responsibilities separate:

PlanetScale Postgres — canonical bookings, wallet ledgers, payouts, accounting records, and other long-lived business state.
Application object storage — uploads, images, exports, and business-owned blobs.
celld fleet bucket — celld runtime durability, ownership, deployments, and binding-managed state.
Node-local celld storage — warm SQLite state, caches, and, in fleet mode, follower log data used by the durability protocol.

See Deployment, Durability, Upgrades, and Operations for the production configuration and runbooks.