Logic Registry & Deploy
What it is
Section titled “What it is”Every compute cell you deploy lives in a system-managed registry inside the catalog, alongside your tables. You don’t build a container image, push to a registry, update a manifest, or wait for a rolling update — you run a single SQL statement and the new logic is live or staged atomically, with versioning baked in.
The registry tracks the compiled WebAssembly bytes, a content hash, the input
and output schemas, the list of tables the cell may access, who deployed it, and
how traffic should split across versions. Because the registry is a catalog
object, every change is transactional and historically queryable — you can ask
what version 3 of calculate_tax looked like last Tuesday the same way you’d ask
a historical question of any table.
Why it matters
Section titled “Why it matters”The traditional path from “I edited a function” to “it’s running in production” is several tools and minutes of partial unavailability. The cell registry makes it one statement and a few milliseconds.
- Zero-downtime promotion — staged versions go live atomically; in-flight requests on the old version finish cleanly.
- Instant rollback — reverting to a prior version is a pointer swap, not a redeploy.
- Schema-safe by construction — a deploy is rejected if the cell’s declared types don’t match the table’s actual columns.
- Canary traffic splitting — route 5%, 25%, or 100% to a new version with one statement.
- Auditable — every deploy, promote, and rollback is recorded in catalog history.
flowchart LR classDef s fill:#1f2640,stroke:#9ca3af,color:#e8eaf0 classDef a fill:#1f2640,stroke:#7c5cff,color:#e8eaf0 classDef g fill:#1f2640,stroke:#4ade80,color:#4ade80 DEPLOY[DEPLOY CELL] --> STAGED[staged]:::s STAGED -->|PROMOTE| ACTIVE[active]:::g STAGED -->|ROUTE WEIGHT n| CANARY[canary<br/>n% traffic]:::a ACTIVE -->|PROMOTE newer| RETIRED[retired]:::s CANARY -->|ROUTE WEIGHT 100| ACTIVE ACTIVE -->|ROLLBACK| RETIRED RETIRED -->|ROLLBACK TO| ACTIVE
How you use it
Section titled “How you use it”A typical workflow: deploy a new version as staged, send a slice of traffic to it as a canary, then promote it when confident — or roll back instantly if something looks wrong.
-- 1. Push a new version. Status begins as 'staged'.-- Each DEPLOY of the same name allocates the next version number.DEPLOY CELL calculate_tax FROM '/build/calculate_tax_v2.wasm' INPUTS (subtotal, region_id) ACCESS orders;
-- 1b. Or deploy straight from a pinned Git commit, so the deployed-- version traces back to an exact point in your history.DEPLOY CELL calculate_tax FROM GIT 'https://github.com/acme/cells.git' AT COMMIT 'a1b2c3d4e5f60718293a4b5c6d7e8f9012345678' INPUTS (subtotal, region_id) ACCESS orders;
-- 2. Send 10% of invocations to v2, keep 90% on v1.ROUTE CELL calculate_tax VERSION 2 WEIGHT 10;
-- 3. Watch dashboards. Looks healthy? Cut all traffic over.PROMOTE CELL calculate_tax VERSION 2;
-- 4. Something wrong? Instant revert.ROLLBACK CELL calculate_tax VERSION 1;
-- 5. Remove every version of the cell.DROP CELL calculate_tax;Note the schema-coupling guarantee: when a cell declares INPUTS (...), those
column names are resolved against the tables it was granted, and a deploy whose
declared inputs don’t match the table’s actual columns is rejected with an error
pointing at the mismatch. Logic and schema can never silently drift apart.
Lifecycle states
Section titled “Lifecycle states”| State | Meaning |
|---|---|
| Staged | Deployed but not yet receiving traffic — useful for warm-up or pre-promotion checks. |
| Active | Receiving all (or the bulk of) production traffic for that cell name. |
| Canary | A staged version receiving a fractional share of traffic via ROUTE … WEIGHT. |
| Retired | A prior version, no longer active but still in the registry — available for instant rollback. |
Each version also records a table grant (the explicit list of tables it may read or write, enforced at call time) and a signature (its input/output types so SDKs can call it without code generation).