The place I'd want to look first

What you're watching

It starts before there's anything to deploy. A new service is a request, then a Crossplane XR, then repos, a pipeline namespace, secrets and a first build. In the video, checkin-api is ten minutes into that. Tower lists every step, from the request PR to a healthy pod in dev, and times each one against the last few provisions, so you can tell a slow step from a stuck one without asking anybody.

Then the whole fleet, on one screen. The Ops Wall is the view people leave open on a second monitor, and in October it got a full rebuild. It answers a short list of questions: what's running, what's deploying, what's waiting on a review, and what needs a person right now. That last list is ranked, so a paused canary in prod sits above a failed build from last night. DORA sits underneath, from the same queries as Glidepath's Grafana dashboards, so the two never disagree. If it's calm, you can get on with your day.

Then one app, in the order a change lives. The tabs run from pull request to pipeline, to deployment, to release, to its environments, to where it's running and how it's performing afterwards. You shouldn't have to remember Tekton, ArgoCD and Prometheus are three different systems. Tower stitches them to the same commit and the same image, so the story reads top to bottom.

A canary should feel like a conversation, not a mystery. In the video, flight-api's prod rollout is paused at 40% traffic while a background analysis watches the error rate. Tower says so in plain words, shows the ramp and the measurements, and draws the stable and canary ReplicaSets splitting traffic. The owners can resume, promote or abort it from the same screen, within what their tier allows. Nobody has to decode a "Suspended" status at 5pm on a Friday.

Promoting should be boring. The release matrix reads two ways: down a column for what's live in an environment, across a row for one release's journey. There's only ever one place a release can go next, and that's where the promote button lives. For staging that's a direct commit to the app's config. For prod it's always a reviewed pull request. Either way it goes through Git, so ArgoCD deploys it and Tower never touches a cluster.

Environments are a list you can edit. Each one is Ground, which deploys on every push, or Flight, which only takes an approved release. Adding one is a short form: a name, a tier and a deploy step in the pipeline. Changes stage beside the table and go out together as one pull request, because an environment is config like anything else.

Every release leaves a record, and it starts early. The next release has a named draft from the moment the last one ships: the pull requests merged since, the builds that could carry them, a readiness check and the notes its owner writes as the work lands. Sign-off happens on the release PR, before the merge. Once the release is healthy in Flight, Tower seals the record into the app's GitOps repo through a PR, with the evidence it shipped with frozen in, and a week later adds how it went. The whole thing exports as a PDF or HTML page for whoever asks later. I wrote about why in an essay on the release record.

The evidence travels with the release. Provenance, SBOM, signature and the transparency log entry sit right beside the deployment they vouch for, not in a separate security tool nobody opens.

And every change is a pull request. Editing an environment's config, or the pipeline's own cicd.yaml, is a friendly form, but it never writes to a cluster. It opens a reviewed GitOps PR, which is the principle I hold most firmly.

How it's built

Tower is a Backstage frontend plugin. It reads each cluster through Backstage's Kubernetes proxy, gets pipeline runs straight from Tekton, asks ArgoCD for sync and health, and leaves the writing to Glidepath's backend, which only ever opens pull requests. Backstage itself holds no cluster credentials. There's more on how the pieces fit on the platform page, and the code is in the tower repo.