Hangar

Log

Hangar is never finished

Hangar is where I try things, so it keeps changing as I learn. These are the milestones so far, newest first, each linked to the place where I wrote down what happened and why.

  1. A CI/CD engine you can call

    A new Architecture essay on glidepath-api, the HTTP API Glidepath grew in the last week of October: 30 operations for runs, logs, evidence, tests, releases and events, decided by the cluster's own identity and RBAC, measured with two SLOs and traces that start in Tower, and since today open to people who sign in with people-dex over a Gateway route. Why a CI/CD engine should be an API rather than a portal's backend, how Tower moved onto it one group of routes at a time, the security bug the move turned up, and what's still open. Three new API diagrams go with it.

  2. The rules Hangar plays by

    Hangar keeps one document with every rule it applies to people, releases and clusters: 137 of them, from who may sign in to what a release has to prove and what the clusters refuse. Each says how strongly it holds, from enforced by a system to only written down, and what holds it. That document now has a page of its own in the Docs, rebuilt from the Hangar repo every time the site builds, so the site can never say something the rules don't. You can search it and filter by strength, and the rules that are weaker than they read have their own list.

  3. The release record, and the users I haven't met

    A new Architecture essay on Tower's release record: a release followed from its draft to its outcome, with every decision written into the app's GitOps repo. It covers the problem it tries to fix, how it works, why its history lives in git and what stays on the cluster, and the assumptions underneath it, since Hangar has no users but me. Three new Release record diagrams go with it, and the release record and the check ride join the glossary.

  4. Paving the cloud

    A new Architecture essay on APIs and IDPs as paved roads to the cloud, not just to Kubernetes. Airframe can now give an app a queue, object storage or a managed PostgreSQL database on AWS or Azure, private, encrypted and TLS-only with no field to turn that off, and a Lambda function gets access through a grant on its own role, never a key. The essay covers what a road like that is made of, why it has to be an API, and three weeks of the last essay's wish list, with three new Paving diagrams. The spec behind it, with the live run of October 24, is a new paper in the Library.

  5. The scorecard moves to 89.5

    A fresh run of the Airframe scorecard: 89.5 out of 100, up from 86.6, and 11 of the 14 A+ checks pass. Three new XRDs came with it, cross-field rules on 22 of the 23, and env entries that name their dependencies through fromComponent instead of hard-coding them (two literals left, of 78). That is past M3's target of 88 on score alone; the airframe.* tools that M3 is really about are still not built, which keeps Interaction surface at an F. The tool needed two fixes for this run, both noted on the page: it now reads the renamed dev cluster repo, and it accepts a docs block that holds more than one YAML document.

  6. Every decision on the CI/CD page

    The CI/CD page now tells all of Glidepath's settled decisions, not just the first seventeen: environments as data, release pins, rollout facts in place of hooks, the per-app chart, the cluster taxonomy and GitHub-signed merges among them. Secure and govern now names every release gate, which ones only advise, and the one that is still a stub, admission-policy validation. The Testkube essay gets a short update on tests becoming signed evidence.

  7. Four more papers in the Library

    Glidepath's test contract and the QA gate that reads it, the move from Kaniko to BuildKit, Apron's next shape, and Hangar Airspace join the shelf, each with where it stands today. Three are built. Apron's is half done: the CLI is, and the move onto kubara hasn't started.

  8. Airspace: who a change will reach

    Tower gets Airspace, a map of how Skyport's services really talk to each other, drawn from OpenTelemetry traces with no code changes and checked against what each environment declares. Each image now carries its signed API spec, so a release check can say which callers a breaking change would reach before it ships.

  9. Tests become evidence

    A test run is now something a release can prove. Glidepath records what each test step was given and what it found, signs the result onto the image, and the qa gate reads that check ride before a promotion goes ahead. Tower shows the results on the release record.

  10. The lab, rebuilt with Apron

    Both clusters were rebuilt from scratch with the new Apron CLI, which renders each cluster's repo from one cluster.yaml: Traefik with Gateway API at the edge, Cilium on dev and Calico on prod. That same week Glidepath swapped Kaniko for rootless BuildKit, and ECS deploys joined Lambda with no stored AWS key.

  11. No stored AWS key for cloud deploys

    Crossplane and every Lambda deploy used to reach AWS with access keys that never expired. Now the dev cluster publishes the keys that sign its pods' identity tokens, and AWS trades a token for an hour in one IAM role: Crossplane's own, or a deploy role made for a single function. A ceiling on every role Crossplane creates closes a way it could have minted an administrator, and admission policies decide which pods may hold the deploy identity. The switch deleted a test function for six minutes; the new paper in the Library explains all of it, the incident included. The old keys go next, then the same for Azure.

  12. Any forge, any registry

    A new plan in the Library: what it would take to run Hangar on GitLab and Bitbucket as well as GitHub, and to publish images to any registry, not just GHCR. GitHub turns out to be wired in at about a hundred small places and three load-bearing ones. The plan puts two Hangar contracts in front of them, moves the GitHub path onto them first with nothing visible changing, then proves it on GitLab. Six new diagrams come with it. Nothing is built yet.

  13. Chasing squirrels

    A Field note from a walk with Riley: a Stoic line about living in accordance with reality, a conversation with ChatGPT about it, and what nine years of watching him chase squirrels he never catches says about enjoying the chase. Not much Kubernetes in this one.

  14. A new tour of Tower

    The three-minute Tower video is re-recorded, because a lot has changed since September. It now opens on a new service being provisioned step by step, then the rebuilt Ops Wall, and walks through the Pull Requests tab, the new Environments tab, the canary controls and the release record. Same dark theme, same made-up Skyport data.

  15. Breaking the glass

    An essay on Tower's break-glass terminal: how it keeps the ability to look inside a production pod while removing exec, with a debug container, just-in-time access, a second person on Flight, six admission policies and recordings you can verify. With a walkthrough video, seven new Break-glass diagrams, and an honest security grade.

  16. More in the flight bag

    Six more papers in the Library, each restyled to match and illustrated: both Tower field reports, where I sat in an app owner's seat and asked whether Tower could be my only console, four weeks apart; a review of Glidepath against the everyday software lifecycle and the roadmap that answers it; and two architecture maps, Autopilot drawn as Kubernetes resources and Airframe's service catalog as it stood in September. The maps get a shelf of their own, and the Library's two shelves now work the same way: each opens its own page.

  17. A library for the paperwork

    Diagrams and the architecture review now share one tab, the Library. Beside the charts sits every review, report and spec I've written about Hangar, each with where it stands today: what a review led to, what a report showed, whether a spec is built. Six of them get illustrated pages of their own, among them the Airframe review that led to fifteen fixes in two days, the pipeline report that took a build from thirteen pods to four, and the specs behind Tower's break-glass and its short-lived cluster credentials.

  18. The scorecard moves to 84

    A new run of the Airframe scorecard: 84 out of 100, up from 72, and 10 of the 14 A+ checks now pass. Most of the gain came from fixes the architecture review asked for: an owner and a risk class on every values field, AGENTS.md on every component, and status conditions and reason codes on almost every XRD. That clears the M2 target of 75. The first run today said 82, because the tool had lost track of a folder rename; I fixed the tool and said so on the page.

  19. A service catalog that grows with the company

    An essay on taking Hangar's catalog past Kubernetes: Lambda functions, Azure Functions and three cloud deploy targets, added across Glidepath, Airframe and Tower on October 3 and 4. Why an API is the right front door to the cloud, how architecture and security policy can live inside a Crossplane XR as code, and an honest note on what isn't built yet. Three new diagrams go with it.

  20. Why Hangar runs its tests in Testkube

    An essay on choosing Testkube: the proof of concept with a team of test engineers that sold me on it, how it works, why tests as Kubernetes resources fit an API-driven control plane, and what running the free tier taught me. Three new Testing diagrams go with it, and Testkube and TestWorkflow join the glossary.

  21. How Hangar started

    A Field note on where Hangar came from: rebuilding my home lab while learning to build with AI, the five mockups that became my first Backstage plugin, how Radar shaped the look, and how Glidepath, Tower and Hangar got their names. With a second note, a shout-out to the diagram-design skill behind every diagram here.

  22. Hangar at a glance

    The home page gets its own architecture diagram: one road from intent to production, with a reviewed commit as the only thing that crosses into a cluster. It plays through once, and every box opens the page behind it. Four more high-level views join it in the diagrams, all wearing the product marks.

  23. The parachute sentence, spelled out

    Several pages and diagrams leaned on "the parachute sentence" without ever saying what it was. It is the one request Autopilot is built to pass: an agent asked to provision a new Python app named parachute, with four environments, a canary step and an env var. It is now quoted where it first appears, in the glossary, and in the diagrams that name it.

  24. Why a platform still needs a service catalog

    An essay on why Airframe sits at the centre of Hangar: the difference between a catalog's menu and its inventory, why the contract matters more than the list once agents are reading it, build versus buy now that AI writes code, and the discovery-first plan I'd bring to a platform team. Five new diagrams go with it.

  25. Field notes, and a shout-out to Radar

    A new section for shorter posts. The first one is about Radar, the open source Kubernetes UI from Skyhook: the people behind it, and the Tekton and Argo Rollouts features I added while learning to build with AI.

  26. Building Airframe, part 1

    The first of a series on building Airframe with Crossplane: the secret store I never got to prototype, what "ready" really means, three ways I emptied GitHub's API budget, and the day rendering nothing deleted two apps' secrets. Four new diagrams go with it.

  27. The Airframe scorecard, over time

    The scorecard gets its own page, with every committed run on one chart: 27 at the baseline, 41 after M0, and 72 now that M1 and M2 are closed, with 7 of the 14 A+ checks passing. The first run today said 58, because the tool was looking for things where they were first planned to live, not where they ended up. I fixed the tool and said so on the page.

  28. Plain words, and honest labels

    A glossary of the jargon, with a short explainer on the first mention of each term on every page, and a status on each product card, so Autopilot no longer looks as finished as Glidepath.

  29. An Architecture section

    A home for pointed opinions, argued from what Hangar does and what it has cost. The first essay is about the bill for running this platform, and where Crossplane should stop.

  30. Zero to running, twice, for real

    Two new services taken from nothing to production and recorded: gate-api in the terminal, checkin-api in Tower. Running the whole path end to end found four real platform bugs the unit tests had missed, three of them from the release-file split. All four are fixed.

  31. The stack, as decisions

    Every tool in Hangar on one page, each with what I chose it over and why, and the same tools on the homepage in the order a change meets them.

  32. An architecture review

    A staff-architect review of the whole platform: a conditional approval, ten findings with evidence, and five gates before production. The biggest are prod's dependency on the dev cluster, identity on a personal GitHub account, and no restore plan.

  33. This site

    Hangar gets a home on the web: the platform, its principles and its diagrams in one place, built from the same repo.

  34. Autopilot, the sixth product

    Design for running any AI agent workload, bounded and audited. The Clearance core, the AppSpec planner, nine Skyport agent definitions and six Preflight cases are built and tested; the AgentRun XRD is drafted. The Airframe scorecard lands with a committed baseline of 27 out of 100.

  35. Infisical operator retired on the prod cluster

    All five apps and Glidepath itself migrated onto the new Airframe pin and External Secrets, phase by phase, with the plan and each phase recorded as it closed.

  36. The prod cluster, rebuilt

    The upper cluster is rebuilt from the Apron template instead of being patched in place.

  37. Every app stack scaffolds its cicd.yaml

    The last hand-authored step in onboarding goes away. The same week, docs across every repo get one table of contents and TechDocs wiring in Tower.

  38. SecretStore on Infisical, built

    One secret store per app and cluster, shared across that app's environments, never across clusters.

  39. The Hangar brand

    The project is renamed Hangar, with the instrument-dial mark family: one gauge, one glyph per product, and the calm-cockpit colour rule.

  40. A self-hosted transparency log

    Rekor and Trillian join the self-hosted Fulcio, so image signatures get a real transparency-log timestamp.

  41. Testkube, and reading the source

    The documented multi-namespace mode turns out to be paid-only in the source. The shared-namespace design ships, with a Kyverno policy closing the gap RBAC cannot.

  42. Lower and upper environments become a real boundary

    Built and verified live after a real bug: a separate AppProject, not just a separate folder.

  43. AI triage in the control plane

    A Composition Function watches Argo Rollouts and dispatches a diagnosis on degradation. Proven end to end: a real broken canary, a real diagnosis, a real fix PR. The application chart is verified live the same day.

  44. Design resolved, build starts

    The GitOps strategy and service-catalog design settle, and the platform around Glidepath begins: Crossplane as the control plane, ArgoCD for delivery, Backstage as the pane of glass.