See what is running in production

The question “what is deployed right now?” has one authoritative answer on Runway: the Flux artifact your deployment project last pushed. Everything else, including what the cluster reports, follows from it within five minutes.

Today, on Runway

Runway’s Kubernetes runtime deploys through a dedicated deployment project, gitlab-com/gl-infra/platform/runway/deployments/<runway_service_id>. Your service’s release pipeline triggers it; it renders your Fairway chart into Flux manifests and pushes them as an OCI artifact that Flux reconciles on every cluster. Source: Kubernetes deployment overview.

1. Read the deployment project

Open the deployment project’s Pipelines page. The most recent successful pipeline with a green 📤 Upload Resource Manifests: production job is what production is running. The 🏗️ Generate Flux manifests: production job log prints the chart version it rendered, on a line starting Using chart version from Fairway:.

The artifact itself is in the deployment project’s Container Registry, tagged deploy:production and deploy:staging. Flux checks these tags every five minutes and reconciles any change ( deployment overview).

2. Confirm from the cluster

With the read-only kubeconfig from Set this up before you need it:

# Namespace is your runway_service_id. The image tag is the release tag.
kubectl -n <runway_service_id> get deploy -o wide
kubectl -n <runway_service_id> get pods -o wide

The image tag is the release tag: Fairway appends the chart’s appVersion to the image reference at templating time ( Fairway service owner guide), so what the cluster shows maps straight to Deploy → Releases in your service project.

3. Map a tag to a release

In your service project, Deploy → Releases lists the semantic-release tags. feat: and fix: commits release and deploy; chore: and docs: commits do not ( Runway Kubernetes getting started). If production runs a tag older than the latest release, check whether the production upload job is waiting on a manual play, see Roll a deployment.

On Cells

For the GitLab monolith, which does run per cell, the equivalent view is the rings page of Auto Deploy View, fed by ringctl rings export. Cells are tenant-model JSON files in tissue, rolled out ring by ring by Release Managers ( ADR 022). When modular services gain a per-cell path, expect it to surface there. Until then, ask in #g_cells_infrastructure.

Related

• Roll a deployment
• Roll back a deployment
• Read the release manifest, for which module versions shipped with a GitLab release
• Theseus and Cells: separation of concerns