A Deployment Is a Transaction, Not a Command

A green build is the beginning

A release starts with the exact source revision. A repository-scoped runner acquires the platform’s single capacity lease, tests that revision, and records an attestation. The privileged gateway independently retrieves a clean archive of the same revision before it builds. A developer’s working directory is not the release input.

Admit, back up, and migrate deliberately

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.

The successful release path

Health and revision checks happen before the release is recorded. Failure recovery depends on the service’s schema and backup contract.

flowchart TD
    Tested[Test exact revision] --> Build[Build clean source]
    Build --> Backup[Admission and backups]
    Backup --> Migrate[One-shot migration]
    Migrate --> Replace[Replace the service]
    Replace --> Verify[Verify health and revision]
    Verify --> Record[Record the release]

Prove the replacement before recording it

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.