Compatibility with celld

celld (denoland/celld) runs Cloudflare Workers projects on a fleet of servers that share one bucket. CellB answers the same requests the same way, and stores cells the same way, so one cell can be served by celld, then by CellB in Node or a browser, then by celld again. This page lists what is identical, how it is checked, and where the two still differ. The pinned celld version is 0.6.3.

Features at a glance

The same request gets the same answer

A project that runs on celld (wrangler.jsonc plus its main) loads unchanged with loadNodeProject or browserProjectRuntime. The conformance corpus runs every project on both and compares transcripts and user logs (conformance.md). Behaviours that only show in those transcripts, and that CellB matches:

• An uncaught error answers 500, content-type: application/json, body Worker failed: rejected: <name>: <message>. A handler returning something other than a Response is sent as its text with status 200.
• An inbound request has request.cf set to {}.
• A promise the Worker leaves rejected is the Worker’s affair, never the host’s: celld ignores it, workerd logs it. On Node, where the Worker shares the host’s process, CellB sends it to onUnhandledRejection (default: one line on stderr, outside the Worker’s console) instead of the process’s unhandledRejection listeners.
• A Durable Object stub.fetch() whose handler throws rejects with rejected: <name>: <message>; RPC errors keep their name, message and own properties such as code.
• SQL refusals use celld’s authorizer wording (not authorized, access to _cf_KV.scope is prohibited); sql.exec() with several statements sums rowsWritten.
• D1 sessions return the bookmark celld:primary; ATTACH, TEMP objects and VACUUM are refused as by celld. There is no Durable Object bookmark API, as on celld.
• KV, Queues and R2 errors carry celld’s messages and limits (KV_ERROR: …, QUEUE_ERROR: …, R2 <op> (binding <NAME>): …).
• Either end of a WebSocketPair may send() before accept() (celld queues the frame; workerd refuses).
• WebSocketPair ends start with binaryType "blob" when the project sets websocket_standard_binary_type, "arraybuffer" otherwise (loaded Workers always get the latter). webSocketMessage() of a hibernatable socket always receives an ArrayBuffer.

The same cell is stored the same way

ADR 0001 records why this is CellB’s only format.

Bindings keep celld’s storage

e2e/p11f-celld-one-bucket.test.ts moves each binding’s data celld → CellB → celld through one bucket. A single Workflow instance takes the whole trip: its first step runs on celld, the step after its sleep on CellB, the step after its event on celld again, and none runs twice. R2 objects written by put and by multipart upload cross both ways with their metadata.

Without a fleet bucket, R2 keeps its objects in the project’s FilesApi. Queues default max_concurrency to celld’s ceiling, 250.

ADR 0002 records why the vendored code is not rewritten.

A mixed fleet: CellB as a celld peer (Node)

celld nodes reach a cell’s owner through celld’s peer protocol (version 5). CellB implements both sides on Node:

• startCelldPeerServer({ runtime, store, node }) serves GET /peer/tunnel (Upgrade: celld-tunnel, kinds do and rpc) and /peer/probe. Requests are checked with the fleet’s HMAC-SHA-256 secret (fleet/peer-auth.json), within ±30 s, against a nonce replay cache, for this node. A node that does not own the cell answers 409 with x-cells-route-error: stale-owner.
• bucket.advertise(addr) puts the server’s address in the node record, so celld routes requests for CellB’s cells to it. The probe key is an Ed25519 key; celld diagnose --peer <node> reports the CellB node as a signed direct probe.
• celldPeers({ store, node }), passed as peers, routes a CellB Worker’s calls for a celld-owned cell through the tunnel, fetch, RPC (V8-serialized) and WebSockets alike.

CellB is never a log follower and does not accept capacity hand-off (/peer/handoff): it acknowledges a write only once it is in the bucket, and its node record reports zero placement weight, so it owns only the cells requested through it.

Where celld is followed, and where it is not

CellB follows celld, including its deviations from Cloudflare, with these exceptions:

A Durable Object that keeps out of _cf_ names sees no difference in the stricter rows.

What breaks

• celld reports ltx file corrupted on files another writer produced with header flags 0 and zero rolling checksums. CellB writes NO_CHECKSUM whenever both checksums are 0; a writer that does not cannot hand cells to celld.
• celld takes over a cell a live CellB node owns. That happens only when the node record has no address or misses a field celld decodes; celld then treats the owner as dead. CellB always writes a complete record with an address.
• celld logs celld ownership record lost, and CellB throws OwnershipRecordLostError: see ownership-and-durability.md. celld dev with a lost record reports it and never becomes ready.
• An R2 multipart upload opened on one runtime cannot be finished on the other. celld keeps an open upload in its node’s memory and answers R2 multipart upload <id> is not open on this node: celld can resume an upload within the node that created it, not across nodes or restarts; CellB answers completeMultipartUpload: The specified multipart upload does not exist. (10024) for an upload celld opened. Complete an upload on the runtime that opened it; the finished object then reads on both.
• Renaming the project’s name makes every Durable Object start empty. Ids derive from the script name. The old cells are still in the bucket, under their old keys.
• Node’s HTTP server rejects celld’s inner RPC requests with 400: they carry no Host header. startCelldPeerServer accepts them; another server in front must too.
• celld diagnose --peer reports the probe as failed on a platform whose WebCrypto lacks Ed25519: the node record then carries a random key that cannot sign.