Platform engineering · James Fillman
Good platforms give people their time back. Hangar is how I build one.
Hi, I'm James. I've spent a long career helping software get from a developer's head to production with less friction and fewer surprises. This site is where I share how I think about that work, and Hangar is where I put it into practice: an internal developer platform I build in the open, for container apps and AI agents alike. It's never finished, and neither are my opinions.
What I believe
Seven ideas shape almost every decision in Hangar, roughly in order of how much they matter to me.
The platform is a product
The people using the platform are its customers, and the thing it sells is their time.
02Every change is a reviewed commit
If it changes a cluster, it went through git and someone could have said no.
03An API-driven control plane, ready for AI
The platform should be an API that keeps reconciling, so people, portals and agents can all drive it the same way.
04Paved roads, with security built in
The safe way should also be the easy way, so nobody has to choose.
05Event-driven by default
Components say what happened. Whoever cares, listens.
06Honest by design
A platform earns trust by saying exactly what it can and can't do yet.
07Interfaces people trust
A calm, clear, good-looking interface is how a platform earns the trust of people who never read its docs.
The whole SDLC, from the platform side
Follow a change from the first design conversation to the day you measure whether it worked. Each stage pairs what I believe with the part of Hangar that does it, and what's different when the author of the change is an AI agent.
Six products, one Hangar
Home base for building, releasing, and watching every service you run.
The platform as a whole: design, docs and the running status.
The structural core: what a compliant service is, defined once.
Crossplane XRDs, Compositions and Functions, and the one application chart every tier deploys through.
The guarded descent from a merged commit to a verified release.
CI/CD on Tekton and Pipelines-as-Code, chained by CDEvents, released by GitOps.
Release orchestration and operational intelligence for Backstage.
The single pane of glass: releases, deployments, SLOs and fleet views.
Ground infrastructure a cluster needs before a Hangar can run on it.
The template for a new cluster repo: one config file, one script, a known bootstrap order.
Any AI agent workload, bounded and audited.
Clearance (policy, audit, sessions), agent definitions, Preflight evaluations and the AgentRun claim.
Start here
Seventeen practices, one worked example
What I believe about CI/CD, told through Glidepath's architecture decision records.
AI workloadsAgents on a platform, bounded and audited
Autopilot, in nineteen diagrams: how Hangar runs any AI agent workload.
ArchitectureHow the platform fits together
The control plane, the delivery path and the pane of glass, for containers and agents.
LogWhat changed, and why
Hangar is never finished. This is its history, one dated entry at a time.
Away from the keyboard
I live in Squamish, BC, with my dog Riley. When I'm not building platforms I'm usually on a rock face, a trail or a chessboard. If any of this is useful to you, or you'd like to talk platforms, I'd love to hear from you.