Releases & Deployments

The runtime pillar — versioned components bundled into immutable releases, landing in deployment zones where instances run, with every landing journaled.

The contract says what an instance is entitled to. This pillar records what it runs: which versions of your product's building blocks, bundled into which release, landed in which zone, when. Four entities form one chain, and the instance hangs off its end.

Component — the versioned brick

A component is one building block of your product at one version — name plus version, unique together per organization. Versions chain through previousComponentId, so a component's history is a walk backwards: Kaiten Sushi Shop's Delivery Service went from 0.9.0 (dispatch, beta) to 1.0.0 (real-time positions), while Kitchen Display 1.2.0 has not moved. Updating a component that no release has picked up yet edits it in place; updating one that a release already bundles creates the next version instead, because the release must keep meaning what it meant.

Release — the immutable bundle

A release is a versioned set of components — the shippable unit. 2026.8.0, the release that introduces delivery tracking, bundles API and Web App at 2026.8.0, Kitchen Display 1.2.0, and Delivery Service 1.0.0, and succeeds 2026.7.0. Its component list is fixed at creation and there is no update endpoint: a release, once created, is a fact. Correcting one means creating a new release; deleting one is allowed only while it has never been deployed — as long as the journal names a release, it stays.

Deployment zone — where instances run

A zone is a logical execution environment: shared across many customers' instances, or dedicated to one. Kaiten Sushi Shop runs two shared zones (shared-eu, shared-apac) and one dedicated to Sakura Tokyo (sakura-dedicated). A zone carries a free-form type, its environment class — the console labels production, staging, and development, and targeting rules read it as __kaiten.deploymentZone.type; all three Kaiten Sushi Shop zones are production. Isolation is not an environment, so Kaiten Sushi Shop records it in typed metadata: dedicated is true on sakura-dedicated alone, which also carries compliance_profile: pci-dss. A zone's releaseId is the release it currently runs.

Deployment — the append-only journal

Kaiten records a deployment whenever a zone's current release changes — PUT /deployment-zones/{slug} with a new releaseId, or POST /deployment-zones with one from the start. Each change appends one entry: this release, this zone, this moment, this actor. A rollback to a release the zone already ran is another entry. Entries are never updated or deleted, so the journal is the history, per zone and per release. Each landing emits RELEASE_DEPLOYED. Kaiten Sushi Shop's journal holds five entries, dated relative to the moment the dataset is loaded: 2026.7.0 landing in all three zones, then, five weeks later, 2026.8.0 in shared-eu and, the next day, in shared-apac.

The instance linkage

An instance optionally points to one zone, and runs whatever that zone currently runs; assigning a zone or moving between zones is recorded (INSTANCE_DEPLOYED, INSTANCE_MIGRATED). Read the diagram through three of the instances: ninja-osaka-prod (in shared-apac) and demo-restaurant-prod (in shared-eu) already run 2026.8.0; sakura-tokyo-prod, in the dedicated zone still on 2026.7.0, does not — even though Sakura Tokyo's Premium License grants delivery-tracking. The contract and the runtime are two separate facts, and the model keeps both.

Release tracking lives in the commercial control plane because the contract already knows every instance, its customer, and what it is entitled to. Keeping "what runs where" beside "who bought what" makes a separate release-tracking tool redundant; the runners that ship your artifacts stay yours.

Where to go next

Components, zones, and the journal in depth, with the seeded rollout as the worked example: the Deployments deep-dive — Components & Releases, Deployment Zones, and Deployments & Lifecycle.

Exact reference: data model.