The place I'd want to look first

What you're watching

It starts with the fleet. Every app, every environment, one glance. I care about this view more than any other, because it's the one people leave open on a second screen. If it's calm, you can get on with your day. If something's amber, it tells you which app and where.

Then one app, in the order a change lives. The tabs run from pull request to pipeline, to deployment, to release, 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. 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.

Every prod release leaves a record. Once a release reaches prod, Tower writes it up: the pull requests that went in, the pipeline runs that built and tested it, every gate it passed and when it moved between environments. The confidence score shows its working. Then there's the part only people can add: a plain summary, how risky it felt, how it was checked and who signed off. That's committed through a PR as well, and the whole thing exports as a PDF or HTML page for whoever asks later.

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 owncicd.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.