This is the first entry in what I’m calling the Homelab Diary: a running log of my self-hosting setup, what’s working, what’s on fire, and what I end up doing about it.
Here’s where things stand. Somewhere along the way I ended up running a media server for a library that’s now past 30,000 songs and movies, a handful of private tools I use daily, a Foundry VTT container my group uses for our TTRPG sessions, and a few websites, including the one you’re reading this on as well as my own gitea repository. There’s also a Matrix Synapse server I set up once the EU Chat Control debate started picking up steam, mostly so my own chats didn’t depend on whatever a platform or a regulator decided to do next. Internal services sit behind a reverse proxy, and the public-facing ones go out through a Cloudflare tunnel instead of anything exposed directly. Almost everything is managed through Portainer, which I reach over a VPN when I’m not home.
None of that sounds bad on paper. In practice, it’s a mess.
The honest version: I have no documentation. If something breaks, the only reason I can fix it is that I remember building it, not because there’s a file anywhere explaining how. Nothing is defined as code. Containers and services got added one at a time, over months, whenever I felt like adding one, which means the setup reflects the order I got curious about things rather than any actual plan. Backups exist for some of this and not all of it, and I genuinely couldn’t tell you with confidence which parts are covered. Same story with security: some services are locked down properly, others got exposed in a hurry and never revisited. And because it all grew this way, I’ve lost track of what’s actually running half the time. I’ll open Portainer to check on one thing and find two containers I forgot existed.
So I’ve decided to start rebuilding it. Not patch it, not clean it up service by service, but start over with something I can actually reason about: infrastructure as code, a real backup strategy applied consistently instead of per-service, and documentation that exists somewhere other than my memory. I haven’t started yet, which is exactly why I wanted to write this down first. I want a record of what the mess actually looked like before I make it disappear, and I want the next entries in this series to track the rebuild as it happens instead of me summarizing it after the fact once everything already looks tidy.
Next entry: the actual plan, and probably the first thing that doesn’t go the way I expect.