{h.name}
+{h.engine}
+cells/Agent:review/
+own.json {"{ node: \"tab-7f\", epoch: 3 }"}
+ltx/e1/… celld · ltx/e2/… node-a · ltx/e3/… browser
+value
+0
++ Every tab can increment. Only the owner tab writes; the + others forward a request to it. Close the owner tab and another tab takes the lock and + continues from the stored value. +
++ cellb has one runtime core that does not know where it runs, plus an adapter for each + platform. The same core runs a cell in a tab, in a Node process, or as one node of a celld + fleet. +
+ ++ The core reaches the platform only through a small set of ports. Each platform supplies its own + implementation: +
+| Port | What it is | Implementations |
|---|---|---|
OpenCellSql | A synchronous SQLite database per cell | node:sqlite, SQLite WASM on OPFS, SQLite WASM in memory |
CellStorage | Durability, backup, ownership and R2 objects | celldBucket, filesApiLtxLog, filesApiChangeLog |
Lease | Per-cell ownership with an epoch and a "lost" signal | celldBucket(…).ownership |
ObjectStore | A bucket with conditional writes | S3, celld dev's SQLite store, memory, OPFS |
+ The SQL port is synchronous on purpose. ctx.storage.sql.exec() returns rows at
+ once, as on Cloudflare, and both drivers are synchronous underneath.
+
| Deployment | Unit owned | Mechanism |
|---|---|---|
| One process | nothing to share | none needed |
| A browser origin, sharded | a shard | one Web Lock per shard, held by one shard worker |
| A fleet bucket (celld, cellb, browsers) | a cell | celld's own.json per cell, a node lease per node, epochs and self-fencing |
+ With an LTX log (celldBucket or filesApiLtxLog) every acknowledged
+ write is restorable: the RPO is 0. The first commit of a generation is a snapshot, and later
+ commits carry only the changed pages. In a browser, SQLite WASM reports those pages through a
+ hook on its database file. A periodic backup alone is cheaper, but it can lose up to one
+ interval of writes.
+
+ A Worker Loader binding runs each loaded Worker in its own isolate: a worker thread in Node, a
+ Dedicated Worker in a browser. Plain values in its env are copied, and bindings
+ become stubs back to the parent. This is how a host runs plugin or agent-written code apart
+ from its own globals.
+
+ cellb (@statewalker/cellb) is a Durable Objects runtime written in TypeScript. It
+ runs the same Workers code in a browser and in Node. A Worker module and its Durable Object
+ classes get synchronous SQLite storage, input and output gates, stubs with
+ fetch and RPC, alarms, WebSockets, Worker Loaders and facets, all without
+ modification.
+
+ The package lives in the cellb.dev monorepo and has no build step yet. Its
+ entry points are TypeScript sources, so import them through a bundler, Vite or vitest. Node
+ 22.13 or later is needed for node:sqlite.
+
Callers differ by platform, so the package is split by platform:
+| Import | What it gives |
|---|---|
@statewalker/cellb | The isomorphic runtime: createCellRuntime, createProjectRuntime, DurableObject, WorkerEntrypoint, celldBucket, the object stores, links over ports, CellRouter |
@statewalker/cellb/node | nodeSqliteOpener, sqliteObjectStore, loadNodeProject, D1 migrations, and celld's peer protocol |
@statewalker/cellb/browser | browserProjectRuntime, sahpoolOpener, createProjectSite, serviceWorkerConnector |
+ A runtime is a plain (Request) ⇒ Response handler. Mount
+ runtime.fetch on node:http, a ServiceWorker or a test, and call
+ runtime.close() when you are done. Closing takes final backups and closes every
+ database.
+
+ In a browser, cells live in SQLite WASM on OPFS inside a Dedicated Worker, and requests arrive + through a ServiceWorker. +
+
+ Give the runtime a celldBucket and it becomes a node of a celld fleet. It uses the
+ same bucket layout, ownership records and LTX log, so a cell can move between celld and cellb
+ with no conversion.
+
+ cellb runs Workers and Durable Objects unchanged in a browser tab, in Node, and + alongside celld on one shared bucket. It is an architecture for rich, isomorphic + applications built for people and for AI agents. +
+// the architecture
++ A cell is a named object with its own code, its own SQLite database and exactly one owner + at a time. Build an application from cells, such as users, documents, rooms, workspaces and + agents, and the same program can run entirely in a tab, entirely on servers, or across + both, with each cell running where it is needed. +
+{p.body}
+// where it runs
++ The runtime core knows nothing about its platform. Ports supply SQLite, storage, leases + and clocks; the package has one entry point per platform. +
+{h.tag}
+ // use cases
++ IDE-class tools, agent platforms and collaborative apps all need the same thing: many + small stateful services that run close to whoever uses them, human or machine. +
+{u.body}
+// the code
+
+ A runtime is a plain (Request) ⇒ Response
+ handler. Mount it on node:http, a ServiceWorker
+ or a test. Wrangler projects load from the configuration celld deploys, and anything
+ cellb does not support is listed in unsupported
+ instead of being silently ignored.
+
ctx.storage.sql, as on Cloudflare// next to celld
++ celld's examples, cellb's own probe projects and workerd's Durable Object tests run on the + real celld and are recorded. The recordings are then replayed against cellb in Node and in + Chromium on every pull request. That is 70 scenarios: 5 are judged by workerd instead, + and 6 are known differences. +
+{n}
+{label}
+| Feature | +celld 0.6.3 | +cellb · Node | +cellb · browsers | +How cellb is checked | +
|---|---|---|---|---|
| {r.feature} | + {[r.celld, r.node, r.browser].map((v) => ( ++ + + {v} + + | + ))} +{r.check} | +
// life of a cell
++ A cell is safe when only one runtime writes it at a time and every acknowledged write + can be restored somewhere else. On a fleet bucket, cellb uses celld's own ownership + protocol to guarantee both. +
+{l.body}
+// try it
++ In a browser, cellb places cells in shards, and each shard is owned through one Web Lock. + This small demo uses the same primitive. Open the page in a second tab, press increment + in both, then close the owner tab and watch the other one take over. +
+ + The four browser topologiesStart from a Worker you have, run it in Node or a tab, and join a celld fleet when you need servers.
+