A few years ago I noticed I was nodding along in meetings I didn’t really understand. The networking team would mention something about routing or VLANs and I’d quietly file it under “their problem”; IT would talk about reverse proxies and authentication providers and I’d take it on faith that whatever they were doing was right. It wasn’t that I didn’t care — I just couldn’t picture the moving parts. I knew enough to ship software, not enough to ask the right questions when something on the other side of the wire was getting in the way of a release.
The homelab started as a way to fix that. The brief I set myself was simple: build, on a small scale and on my own kit, the same kind of setup a software company actually runs. Reverse proxies sitting in front of services so I understand what they do and how they fail. DNS that’s mine, not whatever the router decided. A NAS so I can take backups seriously and stop pretending an external drive in a desk drawer is a strategy. Docker for the everyday stuff and K3s for when I want to think harder about what “production” really means. Monitoring so I know when something is unhappy before I find out by accident. Authentication so I’m not creating yet another password per service. None of it is exotic — and that’s the point. It’s the basics of a software development setup, the kind of plumbing that any company depends on, and now I get to break it on my own terms.
The other reason is more selfish, and probably more useful in my day job. As a Software Engineering Manager I’m regularly asked to weigh in on technical direction — what tools we should adopt, how a piece of infrastructure should be shaped, whether an idea on a slide is worth chasing. The honest version is that I’d much rather have spent a Saturday breaking and fixing something at home than offer a strong opinion based purely on what I read in a vendor blog post. The homelab is where I get to find out, in safety, that an idea I liked at first glance turns out to be much harder than it looked, or that a tool I was sceptical of is actually well thought through once you’ve lived with it for a week. By the time I bring it back to work, I’ve usually changed my mind at least once. The conversations with our network and IT teams have got noticeably better since I started doing this — partly because I now know what they’re talking about, but mostly because I’ve stopped asking for things that obviously won’t work.
This blog is where I’ll write all of it up. Build logs, mistakes, retrospectives, occasional rants. Expect the foundations first: setting up Linux servers without losing a weekend to bad defaults, getting reverse proxies and DNS to behave, putting Docker and K3s in their respective places, layering on monitoring and authentication once there’s something worth monitoring and protecting. The point isn’t novelty — it’s having a working mental model, end to end, of the kind of system I depend on every day. If any of it saves someone else a headache, all the better.