What I believe about platforms

Everything else on this page follows from this one. A platform team exists so that the people building the business can spend their day on the business. That means a small, friendly contract on their side and a lot of careful engineering on ours, never the other way round.

In Glidepath, that contract is a single file, cicd.yaml. Developers never have to read or write Tekton YAML, and when they get something wrong the schema tells them what, in plain words, before anything runs. New apps get that file scaffolded for them, so their very first push already runs a pipeline. The docs are written for two audiences (the people using the platform and the people running it), and the rough edges are written down in public, the way a product team keeps a backlog.

This is the thread that runs through my whole career. At Best Buy Canada it meant moving roughly 500 applications across 9 clusters from hand-run kubectl apply to a declarative, git-driven model. In Hangar it goes further: no cluster holds credentials for another cluster, no component calls across a cluster boundary, and the only thing that ever crosses one is a merged pull request.

It sounds strict, and it is, but it buys a lot. Every change has an author, a reviewer and a history. Rolling back is a revert. Backstage holds no Kubernetes credentials at all, so even "create me a new service" is a commit someone can read. And when AI agents arrive, they fit straight in: an agent is just one more author of pull requests.

A platform built from scripts and tickets can only be driven by people. A platform built as a control plane (declared intent, typed APIs, and controllers that keep nudging reality back towards it) can be driven by a person, a portal, a pipeline or an AI agent, all through the same front door. That is the idea behind Upbound's intelligent control plane, and it is the shape Hangar takes.

Crossplane is the control plane and Airframe is its API. What a well-behaved service is (its app, its environments, its Redis, its SLOs) is defined once, and Backstage's catalog is generated from those definitions rather than written beside them. The intelligence lives in the control plane too: when a rollout degrades, a Composition Function asks for a diagnosis and comes back with a fix PR. Autopilot takes the next step and makes an agent run just another claim, typed, bounded and cleaned up like anything else.

A golden path is good advice: here is how we recommend you do it. A paved road goes further. The recommended way is also the easiest one, the checks run whether anyone remembers them or not, and leaving the road is possible but deliberate. Security belongs in the road itself, not in a review at the end of it.

I learned this the practical way, building PCI-driven supply-chain controls into pipelines rather than around them. In Hangar, every service gets the same secure defaults from one chart. Images are built without privilege and signed without long-lived keys. Release policy checks what the build really did, not just who signed it. Secrets come from the cluster's own identity, so there are no stored credentials to leak, and admission policy closes the gaps RBAC can't express. For agents, the paved road is the only road: every tool call goes through one gateway.

Coupling is what makes platforms brittle, and a direct call from one system into another is the tightest coupling there is. So Hangar's parts talk in events instead: a stage finished, a sync succeeded, a rollout degraded. Anything that cares can subscribe, and nothing has to know who is listening.

Glidepath chains its pipeline stages through a shared CDEvents broker. Upper clusters report back to dev as events, never by reaching in. DORA metrics aren't a separate integration, just one more listener on the same stream. And Autopilot's event-shaped agents start from the same kind of signal: in the Skyport demo, a delayed flight becomes a draft, a small team of agents and, finally, a human decision.

The most dangerous thing a platform can do is look finished when it isn't. A security gate that always passes is worse than no gate, because people trust it. A metric that quietly drifts is worse than no metric, because people act on it.

So Hangar is honest on purpose. Every design claim is labelled Built, Draft or Proposal. A governance gate that isn't real yet says "stub" everywhere it appears. MTTR is shown as experimental because I know where its blind spot is. When the docs and the source code disagree, the source wins, and the finding gets written down. And the problems I find using my own platform go on a public known-gaps list with their evidence. It is a small habit, and I think it matters more than almost anything else here.

I like beautiful tools, and I don't think that's vanity. Engineers forgive an ugly tool, but they rarely love one, and they don't adopt what they don't love. A good interface is also where a platform's honesty shows up: what's live, what's failing, and what's waiting on a person.

Tower is Hangar's single pane of glass, a Backstage plugin that follows a change through its whole life: pull requests, pipelines, deployments, releases, topology, images and SLOs, plus fleet views and a release matrix that shows which version is live where. Every configuration change it makes is a pull request. The same care goes into everything else people read: a brand with one mark per product and a "calm cockpit" colour rule, a shared notification style, and the diagrams you'll find across this site.