Frank
Nobody is going to tell you the home lab truth up front. Every YouTube channel, every Reddit thread, every Discord server is either trying to impress you with their setup or sell you on the next piece of hardware you absolutely need. What they don’t tell you is that ninety percent of your first two years is going to be tearing down things you just built and starting over, because you made a structural decision early on that seemed fine and then quietly became a load-bearing wall you can’t move.
I’ve been running a home lab in some form since before most people reading this knew what a VLAN was. I’ve got four NAS units on my network right now. A QNAP, three Synologys, named Rollo, Lamont, Grady, and FredG because I name everything and I have no apologies about that. I’ve got Docker stacks, a Caddy reverse proxy, Authelia handling internal SSO, Authentik phasing out for cloud, and enough containers running that I genuinely had to build HomeBase, a React and TypeScript asset tracker, just to keep track of what’s alive and what’s collecting digital dust.
That’s a lot of infrastructure for one guy in Gray, Georgia with a full-time job and a German Shepherd that eats too many treats.
Here’s what I wish Frank Robinson circa 2010 had known.
Stop buying hardware to solve a software problem. This was my single most expensive habit. My QNAP, Rollo, is the primary NAS now. Movies, TV shows, music, general storage. It works fine. But I didn’t start with a plan for what each box was going to own. I just kept acquiring drives and boxes because the deals were there and the itch was real. I ended up with overlapping storage, redundant backup jobs hitting the same files from different directions, and no clean answer to “where does THIS kind of data actually live?” The Synology boxes got roles eventually, Lamont handles docs and pictures, Grady handles Trilium and more TV, FredG handles classic cartoons and eBooks, but that clarity came from pain, not planning. If you’re starting out, write down your data categories before you buy a single drive. I mean physically write them down. It sounds ridiculous. Do it anyway.
Naming conventions are not optional and they are not for your ego. I name everything, Optimus is the primary domain controller, Scooby is the dev server, Megatron is the desktop workstation, Sentinal is the general Windows 10 box. People laugh at that. Those same people are the ones who end up with server-01, server-02, server-new, and server-new-final in their DNS and they can’t remember which is which at two in the morning when something breaks. When you have twenty-something things on your network and you’re running SSH sessions and RDP connections and checking Caddy logs, consistent names that you actually remember matter more than anyone gives credit for. Pick a naming scheme. Stick to it. Mine is Transformers and old Sanford & Son characters. Yours can be whatever. Just be consistent.
Docker will save you and then humble you in the same week. Containers are genuinely the right answer for a home lab. I don’t want to argue about this. The portability, the isolation, the ability to spin something up and tear it down without hosing your host machine, it changed how I run everything. But the early mistake I made was treating containers like they were indestructible. They’re not. The data inside a container, if you haven’t mapped it to a bind mount or a named volume that lives outside the container, is gone the moment you pull a new image and recreate it. I learned this the hard way with a compose stack I hadn’t properly documented. Gone. Not catastrophic in my case, but educational in the worst kind of way.
The other Docker mistake was running everything as root inside containers without thinking about it. That’s fine for a sealed home lab on a network you trust. The moment any of it is public-facing, you need to care. I run public stuff behind Caddy with proper configs now, and anything that needs to be exposed gets treated like it’s on the open internet, because it is.
Caddy is better than you think and NGINX Proxy Manager is more fragile than it looks. I ran NPM for a while and it worked right up until it didn’t. The database got corrupted in a way that wasn’t fun to sort out, and I’d built a bunch of proxy hosts I had to recreate. Caddy’s Caddyfile is just a text file. It lives in a bind mount. It’s in my backup routine. When something breaks I open it, read it like a human, fix it, reload. There’s real value in a config that doesn’t require a GUI to manage.
Backups are not the same as multiple copies. This is the one that kills people. I had four NAS boxes and I felt bulletproof. But for a while I had jobs configured where Lamont was backing up to Grady and Grady was backing up back to Lamont in some misguided mutual protection scheme. That protects you from a drive failure, not from the dumb thing you’re going to do. If you delete something or a ransomware variant finds its way in, all your “backups” die together. The 3-2-1 rule exists because it works. Three copies, two different media types, one offsite. I’m not going to pretend I’ve always been perfectly disciplined about the offsite part. But it’s the goal, and I take it more seriously now than I did.
I have three modes: unstoppable hyper focus, buffering, and molasses-dipped sloth. When the hyper focus hits and I’m deep in a new project at midnight, I make decisions fast and I don’t always document them. HomeBase exists partly because of that. I needed something to capture what I’d done during those sessions so I could understand my own network when the molasses mode kicked in three days later and I couldn’t remember why I added that container or what port it was supposed to be on.
Build the documentation habit early. It doesn’t have to be fancy. A text file in a folder called “what I did and why” is better than nothing. Trilium Notes works well for me for this now. When I stand something new up, I write a short entry about it. What it is, what it does, what the relevant configs are, why I put it where I put it. Future Frank thanks Past Frank on a regular basis. More often than Past Frank deserves.
The home lab is genuinely one of the best decisions I’ve made for my skills. Twenty-eight years in IT and the home lab is what pushed me into Docker, into React, into building things that actually work. It became the testbed for HookHouse-Pro, for Cookslate, for HomeBase itself. But none of that happened because I bought the right hardware. It happened because I kept breaking things and being too stubborn to leave them broken.
The hardware is just the table. What you build on it is the whole point.
