Why Celld
Celld combines application code, SQLite, and durable background work in one runtime, backed by object storage you own.
Start with a cell
A cell is a small server addressed by name, with its own code and database. A chat application might use one cell per room. Its messages, connections, and timers stay together; requests reach one active owner, and database reads happen beside the code.
Cloudflare calls this a Durable Object. Celld brings that model to machines you run. An idle cell can leave memory and later restore its stored state. “Durable” means confirmed database writes survive a server failure. Ordinary in-memory variables still disappear on restart. Celld's introduction.
One bucket underneath
“S3 is all you need” describes the shared storage dependency. Compute still runs on servers. The bucket holds database history, deployments, and ownership records. A conditional write, accepted only if the previous value still matches, lets one server claim a cell. Celld builds routing and takeover on that guarantee, removing the need for a separate coordination cluster. How Celld works.
Database durability is automatic: Celld handles SQLite replication and confirms writes only after they are protected against server failure. A replacement owner can recover that history. Replication preserves writes; recovering an accidental deletion still requires backups. Durability guarantees.
Fewer services to connect
A conventional application might assemble the following stack. Celld supplies these capabilities within the same runtime:
| Need | Conventional choice | With Celld |
|---|---|---|
| Store application records | PostgreSQL plus its replication setup | Private SQLite per cell, with replication handled by Celld |
| Coordinate work on one entity | Redis locks or shared coordination state | One active cell owner and local transactions |
| Resume a job after a crash | Temporal or another workflow service | Workflows with saved steps, retries, sleeps, and events |
| Deliver background jobs | SQS or RabbitMQ | Queues with batching, retries, and dead letters |
| Run scheduled work | A separate scheduler | Cron Triggers for fleet schedules; alarms for one cell's deadlines |
KV stores, queues, and workflow instances are themselves cells. They reuse one persistence and recovery mechanism, reducing the services to provision, connect, monitor, and restore. These are capability comparisons; the supported APIs define exact behavior.
Portable compute, scalable cells
Celld is open source: choose your machines and a compatible storage provider without requiring Cloudflare's hosted runtime. Portability follows the Workers API and Celld's storage requirements, including conditional writes and consistent reads.
Add capacity by starting more Celld servers against the same bucket. Independent cells can run on different servers; inactive cells need no resident process. A busy cell still has one writer, so scale by dividing independent state into cells. Adding nodes.
How OncoBrain uses it
OncoBrain pins Celld v0.4.1 and keeps one organization in OrganizationCell("primary"). Drizzle manages its tables. Native Workflows track background execution; Cron repairs pending work and performs scheduled cleanup. We do not currently define Queue bindings or cell alarms.
The architecture diagram shows two storage paths: Celld → fleet bucket for database and runtime state, and app → Files SDK → object store for immutable documents. Credentials are separate. Eve executes AI tasks outside Celld.
The app still owns access checks and clinical decisions. Workflow retries can repeat external calls, so the app records receipts to recognize completed effects. Our organization database remains one writer. Celld is still alpha; see deployment for recovery and operating requirements.
- Runtime and version:
apps/oncobrain/src/config/celld.ts - Cell and schedules:
apps/celld-gateway/src/organization-cell.tsandapps/celld-gateway/src/worker.ts - Durable execution:
apps/celld-gateway/src/native-effect-workflow.ts