Three years of Pulumi, a few weeks of corrections, and a 3D rack with a sheet behind every device.
My homelab has run on Pulumi for a few years. Proxmox on the metal, a Kubernetes cluster on top, and every app deployed from one repository: the media stack, Home Assistant, the photo library, the monitoring, the backups, the DNS on a pair of Raspberry Pis. The repo is the source of truth for all of it. It has never been a picture of any of it.
A while ago I gave that repo to Claude (Fable) and asked a simple question: can you generate a 3D map and a set of diagrams from this, so I can document what's there and keep track of what I'm planning? This is what came out, after a couple of weeks of tweaking and correcting it.
homelab.robbeverhelst.com
The front page is the rack, in 3D. You can orbit it, and every device has a callout. Click one and a sheet opens beside it: what the device is, why it's there, what it's wired to, and what stops working if it goes. The NAS, the two Proxmox hosts, the gateway, the switches, the patch panels, the UPS, the Pi bay, the crash cart. The monitor on top of the rack even shows live figures from the cluster.
On the right there's a rail labelled "the rack over time". It steps the rack back through its revisions. Three years ago it was a mainboard, a power supply and some disks on a table. Then a cabinet with a screen on it. Then a real rack with the first boxes in it. Then what's racked now, and a stop for what I'm planning next. Each step animates the units that stayed, and fades the ones that didn't.
Behind the rack there are 64 sheets. Twenty-eight of them are a tour, meant to be read in order: all the hardware, the network, Proxmox, storage, power, the Pi fleet, the cluster, how a request travels, names, observability, and a section for when things break: alerts, out-of-band access, cold spares, and what's left if none of that works. The remaining 36 are one sheet per deployed app, each drawn through the same layout: where its traffic comes in, its namespace, its storage, its network policy, its quota, and what it talks to.
The first version was not this. Claude's first instinct was to generate the map from Pulumi state, and the result was technically correct and completely unreadable: every resource as a node, every relationship as an edge, a hairball. I told it that wasn't fun to look at, and we threw it away.
The second approach is what stuck. Every sheet is written as data: a list of boxes, what each one says, and how they connect. The 3D rack is the same idea, a hand-kept inventory of units with a position, a model and a story. Claude wrote almost all of it. My job was to read it and say what was wrong.
There was plenty. It described a service as a LoadBalancer that isn't one. It had a database that doesn't exist and missed two that do. It put a switch in the wrong year. It called the UPS metrics unreachable when they've been in Grafana for months. Some of that came from reading the repo too literally, some from guessing where the repo was silent. Each round I'd go through a batch of sheets, correct the facts, ask for the rack to look more like the actual rack, and ask for things I wanted to see that weren't there. After a few weeks the corrections got rare, and the map started being the thing I open when I want to remember how something is set up.
Two things surprised me. The first is how much of the value is in the words, not the picture. A rack render is nice for thirty seconds. A sheet that says what breaks when this box goes is what I actually come back to. The second is that a model with the whole repo in front of it is a very fast, very confident, and occasionally very wrong colleague. It needs someone who knows the real rack in the loop. That someone was me, and the map is better for the argument.
Orbit the rack, click a device, turn the rail, read a sheet or two. If a fact is wrong, a sheet is unclear, or there's something you'd want to see on a map like this that isn't there, every page has a feedback button that goes straight to my inbox. I'd like to hear it.