Roll a deployment

On Runway you do not “roll” a deployment by hand. A release commit starts a chain that ends with Flux applying new manifests. Your levers are which commits release, whether production waits for a human, and the change lock.

Today, on Runway

1. Make a release

A commit on the default branch whose message starts feat: or fix: (or carries a breaking-change footer) is released by semantic-release. Fairway builds and pushes the chart, then the 📦 Trigger deployment pipeline job starts the deployment project’s pipeline with the new chart and app versions. chore: and docs: commits do not release and so do not deploy. Source: Runway Kubernetes getting started.

2. Watch it land

In the deployment project, the pipeline runs 🚧 Preflight Check, ⌚ Change Lock Check, then renders and uploads manifests for staging and production. By default production deploys automatically once staging succeeds. Flux picks up the new deploy:production artifact within five minutes. Follow with See what is running.

3. Hold production for a human

Set runway_manual_production_deploy: true in your release-platform CI inputs. The production 📤 Upload Resource Manifests job then needs a manual play; staging is unaffected. Source: the release-platform template README in common-ci-tasks and Runway Kubernetes getting started.

# .gitlab-ci.yml, in your release-platform include
inputs:
  runway_manual_production_deploy: true

To promote, play that job. There is no separate soak or canary step on the Kubernetes runtime; staging-before-production and this manual play are the only gates. See Roll out new code safely.

4. Re-deploy the same version

Unverified. Retrying the deployment project’s pipeline re-renders and re-pushes the same artifact, which forces Flux to reconcile. This is what the CI definitions do, but it is not documented as a supported action. Confirm with the Runway team in #g_runway before relying on it during an incident.

5. Stop deploys

runway_manual_production_deploy: true (section 3) is the one hold the Kubernetes v2 deployment pipeline honours. Merge it as a chore: commit so the change does not itself release; every later production upload then waits for a manual play ( deployment template).
The ⌚ Change Lock Check job enforces the Production Change Lock. Override only with CHANGE_LOCK_OVERRIDE and Senior Director approval ( Production change lock).
For a hard stop on a running service, ask Runway in #g_runway to suspend the Flux kustomization ( incident response).

Unverified. Runway’s disaster recovery page names RUNWAY_DEPLOYMENT_ACTION=manual and a GitLab Deploy Freeze as ways to pause deploys. At the time of writing both are implemented only in the Cloud Run deployment template; the Kubernetes v2 template reads neither. Do not rely on them for a Kubernetes service until Runway confirms otherwise in #g_runway.

On Cells

Rolling out to cells is Release Managers’ work, not yours. Cells are organised in rings: ring 0 is the QA cell, ring 1 the first user cells, ring -1 quarantine. “Release Managers own continuous deployment to rings 0 and 1” ( ADR 022), driven by ringctl against the tenant model in tissue, through Amp and Instrumentor ( Cells deployments design). A package cannot proceed to the next ring until it has installed in the current one.

Not yet available. That machinery rolls the GitLab monolith. The path for a modular service’s chart to ride it is unresolved. Tracked in Delivery work item 22155. Owner: Delivery and Cells Infrastructure. Theseus deliberately does not own rollout policy, see What Theseus deliberately does not do.