The terms this book uses, each defined once and used the same way in all six parts. The last column names the section that explains it.
Tbl. 1
| Term | Meaning | See |
|---|---|---|
| Actor | A unit of computation with private state that interacts only by asynchronous messages. In response to a message it can send messages, create actors, and choose its behavior for the next message. | Chapter 1 § 04 |
| Binding | A permission and an API in one object on env, through which a Worker reaches a platform resource with no credential in its code. | Chapter 1 § 02 |
| Bucket proof | The durability proof with one node: the write waits for one storage round trip to the bucket before it is acknowledged. | Chapter 3 |
| Cell | A Durable Object instance: a small server with a name and a private SQLite database. One per user, document, room, or agent. | Chapter 2 |
| Durability mode | CELLD_DURABILITY: fleet (the default) acknowledges on a fleet proof, bucket on a bucket proof. A single node falls back to bucket proof. | Chapter 3 |
| Durable execution | Code that survives crashes: each step's result is recorded in a persistent log, and after a failure the code is replayed with recorded steps answered from the log. | Chapter 1 § 05 |
| Ensemble | A cell's owner together with the followers it sends each write to. | Chapter 3 |
| Entity | A named unit whose state persists indefinitely, such as a user, room, or document. A cell is an entity; contrast process. | Chapter 1 § 06 |
| Epoch | The fencing number in an ownership record. Every activation advances it, and replicated data is written under an epoch prefix, cells/<cell>/ltx/e<epoch>/. | Chapter 4 |
| Facet | A child object attached to a Durable Object through ctx.facets, with its own SQLite database and replication stream, sharing the root's ownership record and epoch. | Chapter 6 |
| Fleet | The set of nodes sharing one fleet bucket. | Chapter 3 |
| Fleet bucket | The object-storage bucket a fleet shares. It holds deployments, cell state, ownership records, node leases, and R2 objects, and it is the root of authority. | Chapter 3 |
| Fleet proof | The durability proof with two or more nodes: the write is acknowledged once every follower has it on disk, and the bucket upload finishes afterwards. | Chapter 3 |
| Follower | A node, never the owner itself, that receives a cell's writes for a fleet proof. The owner picks one or two. | Chapter 3 |
| Hibernated | A cell evicted from memory whose hibernatable WebSocket clients stay connected and which stays on its node. Balancing moves only hibernated cells. | Chapter 2 |
| Inactive | A cell no node holds: only an object in the bucket. Every cell starts inactive. | Chapter 2 |
| Input gate | Cloudflare's rule that no new event reaches an object while one of its storage operations is in flight. celld gets the same effect from synchronous storage calls. | Chapter 1 § 03 |
| Internal listener | The node listener for the peer protocol and the operator API (--internal-listen). It must stay on a private network or encrypted overlay. | Chapter 8 |
| Isolate | A V8 sandbox with its own memory and variables. One runtime process hosts many isolates, which is what makes Workers start fast. | Chapter 1 § 02 |
| Local store | The on-disk store celld dev uses, in .celld/dev under the project. Fleet nodes cannot select it; fleets require a qualified cloud bucket. | Chapter 5 |
| LTX segment | Litestream's replica format, in which celld ships each cell's SQLite state to the bucket. | Chapter 3 |
| Node | One celld process. | Chapter 3 |
| Node lease | A node's record in the bucket with an expiry (CELLD_TTL_MS), renewed after one third of its lifetime. A node that cannot renew it fences itself. | Chapter 4 |
| Output gate | The rule that holds each write response until a durability proof covers it, applied in one order across responses, outbound calls, Queue deliveries, and WebSocket sends. | Chapter 4 |
| Owner | The node session an ownership record names: the only one that may run the cell. | Chapter 4 |
| Ownership balancing | How the fleet evens out ownership without a coordinator: the node with the most owned cells per unit of weight hands hibernated cells to the peer furthest below its share. | Chapter 5 |
| Ownership record | The one record per cell in the bucket that names its owner and epoch, acquired with a conditional write. | Chapter 4 |
| Paged restore | Restoring a large cell page by page through a fault-in SQLite VFS that reads each page from the bucket on first use. | Chapter 3 |
| Peer tunnel | The versioned plain-HTTP tunnel that carries every proxied cell call (fetch, RPC, WebSocket) from the node that took the request to the owner. | Chapter 4 |
| Process | A sequence of steps that starts, runs, and finishes, such as an order pipeline. A workflow is a process; contrast entity. | Chapter 1 § 06 |
| Replay | Re-running durable code from the start, answering each completed step from the log. It requires deterministic control flow and idempotent steps. | Chapter 1 § 05 |
| Resident | A cell in memory: active while it does work, idle while it waits. | Chapter 2 |
| RPO=0 | No acknowledged write is lost: celld does not answer a write until the data survives a failure. | Chapter 3 |
| Self-fence | A node whose lease expiry passes stops its cells, fails incomplete requests, logs SELF-FENCE:, and exits with code 3. | Chapter 4 |
| Virtual actor | An actor that always exists logically, is activated on demand and deactivated when idle, and is addressed by identity rather than location (an Orleans grain). A Durable Object is one. | Chapter 1 § 04 |
Sources
This chapter draws on: celld: documentation at v0.6.0 (9 entries) · celld: release notes (5 entries) · Cloudflare documentation (4 entries). The full entries are in the Bibliography.