The deployment lane begins before a build. A repository-scoped runner acquires the platform's single capacity lease, tests the exact source revision, and records an attestation. The privileged gateway then independently retrieves a clean archive of that same revision; it does not trust a developer workspace or expose the production control plane to workflow code.

Before changing a running service, the gateway performs resource admission and creates the backups declared by that service. Database migrations run once from the candidate image, separate from web-process startup. Only the reviewed service is replaced, leaving unrelated applications and shared infrastructure untouched.

Acceptance happens after replacement. The candidate must report the expected revision and satisfy its readiness and route checks. If it does not, the gateway can restore the previous runtime image when the schema remains compatible; migration designs that require quiescence must carry their own explicit recovery path.

Finally, the platform records the immutable image identity, source revision, previous release, and associated restore points. That ledger turns rollback from “try the old tag” into a defined relationship among source, runtime, schema, and data. Treating deployment as a transaction makes failure behavior a designed feature rather than an emergency improvisation.