Hangar

Docs · Tower

Tower mark

Tower

Release orchestration and operational intelligence for Backstage.

Tower is a Backstage plugin that brings visibility and control to cloud-native platforms built on Crossplane, ArgoCD, and Tekton. It provides release orchestration, promotion workflows, and operational dashboards for managing infrastructure-as-code deployments.

Part of the Hangar Internal Developer Platform ecosystem.

Highlights

  • It tells you what is wrong, in plain language. Each environment’s Deployments view opens with one sentence: the canary failed and why, the image cannot be pulled, a container ran out of memory, canary in progress, step 2 of 4, 50% traffic, each with what to try first. It reads live Argo CD, Argo Rollouts, pod and event signals, worst first, so a real failure is never hidden behind “in progress”. See Deployments.

  • Every action explains itself. A “Which one?” guide for the Argo CD actions, a one-line explanation on every Rollout action, confirmations that name what will happen (Force sync lists what it will recreate), and buttons you may not use say why.

  • Safe by design. Tower holds no stored Kubernetes credential.

    • Reads use the Backstage pod’s own rotating token.
    • Each write (a Tekton Re-run or Cancel, a release run, a break-glass step) mints a 10-minute token for that action.
    • Tekton writes go through glidepath-api, which authorizes and audits them and creates the run itself; Tower’s token can’t write a PipelineRun. Admission policies hold every write to Glidepath’s own shapes; see Cluster credentials.

    Changes are pull requests; Argo CD and Rollout actions are delegated through one narrowly scoped Argo CD account; owners act on their own apps and Flight (upper) environments need an admin for anything that bypasses review; every write is audited. See Security model.

  • Look inside a pod without exec. When logs and metrics are not enough, Debug opens a recorded, time-boxed shell in a hardened debug container: a copy of the pod or the live pod. Ground opens at once; Flight needs a second person, or an admin breaking the glass and a review afterwards. Every byte is recorded and plays back in Tower. See Break-glass debugging.

  • Roll back without guesswork. Abort a bad canary, then roll back to one of the environment’s last five healthy releases as an ordinary, gated release PR.

Features

Tabs, in the order of a change’s lifecycle: Overview, Pull requests, Pipelines, Deployments, Releases, Topology, Airspace, Images, SLOs, Notifications, Configure (sub-tabs Environments, Shared values, Pipeline). Plus a fleet-wide dashboard and the fleet Airspace page (Map, Contracts, Drift).

  • Release Records: structured release history, persisted as git commits, with compare and export; every release gets a tree name (ASPEN, BIRCH…), and a live Next release draft shows scope, open PRs, linked issues, candidate images and readiness before anything reaches Flight, with release notes the team writes; release modes (Hand-flown, Assisted) with a sign-off on the production release PR; each record’s outcome (clean, rolled back) written back, a changelog, opt-in GitHub Releases, scheduled releases with milestones and Jira links, and a fleet release calendar
  • Release matrix: which release is live in which environment, along the app’s real promotion order
  • Deployments (“Ground Control”): plain-language troubleshooting, the six-step delivery path per environment, Argo CD Refresh, Sync, Force sync and Terminate, Rollout controls (resume, pause, abort, retry, restart, promote), Roll back
  • Pull requests and checks: the PRs in flight and their gates
  • Configure (Environments, Shared values, Pipeline): edit an app’s environment values and cicd.yaml through a real GitOps PR, never a direct commit
  • SLOs, topology, images: burn rate, live objects, artifact catalog
  • Airspace: who an app talks to, from traces (the OpenTelemetry collector’s service graph), its values file (declared peers) and its components, with drift between them; a fleet map, the catalog’s API contracts and fleet drift. See Airspace
  • Fleet dashboards: Fleet Grid and Ops Wall
  • Hangar sign-in page: the branded first screen (mark, product family, one sign-in box), light and dark, installed with one line; see Installation
  • Airspace — dependencies, API contracts and drift: what is read, from where, and what is phase 2
  • Deployments — the troubleshooting banner, the delivery path, and every control explained
  • Security model — who may do what, and the guardrails behind each action
  • Cluster credentials — how Tower reaches clusters with no stored token: identities, trust, policies, operations
  • Break-glass debugging — recorded debug sessions: user guide, walkthroughs, guardrails; and the admin guide
  • Installation Guide — Getting Tower running in your Backstage instance
  • Architecture — How Tower is structured and designed
  • Components Reference — Details on each major component
  • Brand — the mark and its files
  • Mounted tabs — the Agent and Clearance tabs come from the Autopilot and Clearance plugins: the contract
  • Hangar — IDP core platform
  • Glidepath — CI/CD engine (Tekton, PaC, cosign)
  • Airframe — Crossplane XRDs and Compositions
  • Autopilot — runs AI agent workloads with bounded authority; its Backstage plugin mounts the Agent tab
  • Clearance — the MCP gateway every agent call goes through; its Backstage plugin mounts the Clearance tab