May 2026
The most expensive resource in a home lab isn't hardware — it's the attention each box silently demands.
I recently inventoried my infrastructure. Twelve hosts. Two hypervisors. A Raspberry Pi. A managed switch. A router with a DHCP reservation table that looks like a medium-sized enterprise.
Some of these I chose. Most I accumulated.
Here's what I found when I actually wrote down everything on the network:
| Host | Purpose | Status |
|---|---|---|
| .16 | Dev hub (Ollama, OB1, opencode, Jellyfin) | Essential |
| .25 | Jump box (SSH, RDP, lynx) | Utility |
| .39 | 10Gb switch | Essential |
| .111 | TrueNAS (storage VM) | Essential |
| .112 | File server (NFS for VM disks) | Essential |
| .113 | KVM hypervisor (hosts 3 VMs) | Essential |
| .120 | Worker4 VM (ask.atkatana.com, resume QA) | Decommissioning |
| .154 | Windows GPU host (Ollama inference) | Essential |
| .171 | Raspberry Pi (Pi-hole + unbound) | Essential |
| .176 | Hermes VM (nginx, cloudflared, agents) | Essential |
| .201 | Gateway VM (old tunnel, unreachable) | Decommissioning |
| Router | ISP gateway, DHCP, NAT | Essential |
Twelve entries. Four of them are doing work that could be consolidated into two. Let me walk through how that happened and what I'm doing about it.
It never feels like a bad decision in the moment.
The gateway VM (.201). I needed a dedicated reverse proxy that could survive reboots independently of the hypervisor. Made perfect sense. Ubuntu 24.04, clean install, cloudflared configured. Then I realized the tunnel should live on the same host that serves the content — not one network hop away. So I moved it to .176. .201 stayed running because I never got around to turning it off. Three months later, it's still there. Autostart disabled. Unreachable by SSH. Running nothing. But consuming 2 vCPU and 4 GB of RAM from the hypervisor pool.
The worker4 VM (.120). A dedicated QA server for AI queries. Also made perfect sense — isolate the experimental workload from production. Then Hermes absorbed the QA function. Then ask.atkatana.com started proxying directly through nginx on .176. .120 sat there, 50 GB root disk 73% full, snapper snapshots piling up, running a service nobody was talking to directly.
The dual tunnel incident. When migrating the CloudFlare tunnel, I set up a temporary VM and a container in parallel, both with autostart. A power blink brought both back up. I had two active tunnels to the same domain for a week before I noticed. Neither was wrong — I just forgot to close the old one.
Three rules emerged from untangling this:
Every service I want to stay up runs on Ubuntu 24.04 now. The Hermes VM (.176) has been up for months without a surprise. The Arch boxes (.120, my old approach) need attention every time I log in — a rolling release is a maintenance contract, not a deployment target.
The CloudFlare tunnel lives on .176, the same VM that runs nginx. No split-brain, no routing through intermediaries, one ingress path to audit. If .176 goes down, the tunnel goes with it — and that's fine, because there's nothing to serve anyway.
This is harder than it sounds. Every VM has a story. I built that. I configured that. It took me an evening to get it right. The sunk cost is emotional, not practical.
I asked myself: would I notice if this host disappeared tonight? For .120 and .201, the honest answer was no.
The cuts bring me from 12 hosts to 8 active. But the real reduction is in attention:
The Pi-hole, the file server, and the switch don't move. They earned their place.
| Resource | Before | After |
|---|---|---|
| Active hosts | 12 | 8 |
| VMs | 4 | 3 |
| vCPU allocated | ~48 | ~36 |
| RAM allocated (GB) | ~120 | ~100 |
| Tunnel instances | 2 (or more) | 1 |
| Things I need to remember exist | Too many | Manageable |
Nothing dramatic. Just a few percentage points back in capacity and a meaningful reduction in mental overhead.
Homelab sprawl is the same pattern as cloud sprawl: every service starts as an experiment. Each one earns its keep in the moment. But experiments don't decommission themselves. They become obligations the moment you stop paying attention to them.
The only difference between a well-run lab and a mess is knowing what to turn off. Most of the time, that's harder than deciding what to build.
I still have more hosts than I need. But now I know which ones are optional, and I have a process for retiring them. That alone feels like progress.
Built on a home lab, powered by local models, and owned by Andrew Katana.