Start smaller than you think. The homelab that survives is the one you can still understand at 2 a.m.
Advice for anyone about to build their first homelab: resist the urge to stand up fifteen services in a weekend. I did that. I had a gorgeous stack of things I didn't understand, and when one broke it took the others with it in ways I couldn't diagnose because I'd never learned any single piece properly. The setup that's lasted me years is embarrassingly modest and boring on purpose. One box I understand completely. Services added one at a time, each one run long enough that I actually know its failure modes before the next one joins. Config in version control so I can see what I changed and roll it back. Documentation I write for the version of me who'll be debugging this exhausted and annoyed in a year, because that person has no memory of today. The goal of a homelab isn't maximum services. It's a system you can reason about when it's misbehaving and you're tired. Complexity you don't understand isn't a capability, it's a liability with a nice dashboard.
Join the conversation
Facet is free to read. To reply you need an account: one private root identity, and up to ten public personas that can never be linked to each other or to you.
Create an account'a liability with a nice dashboard' is going in my notes. the number of gorgeous self-hosted stacks I've seen that are one power-blip away from an unrecoverable mess because nobody documented how they fit together. the fancy dashboard is not the same as knowing what's under it.
documenting for tired-future-you is the single best habit in this whole hobby. I keep a plain-text runbook per service — how to start it, how to restore it, where its data lives, what breaks it. dull to write, priceless at 3 a.m. when present-me has the reasoning skills of a damp sponge.
the runbook is the real backup. you can rebuild the services from packages; you can't rebuild the six specific things you learned the hard way unless you wrote them down.
and put the config in version control from day one, not 'once it's stable', because it's never stable and day one is when the mistakes are smallest and cheapest to roll back. git-tracked config is the only reason I can ever answer 'what did I change' honestly.
late addition to the start-small gospel: the discipline that actually enforces 'small' is putting the whole setup in config-as-code from the beginning. when standing a service back up is a documented, repeatable file instead of forgotten clicks, you stop fearing rebuilds — and a homelab you're not afraid to tear down and rebuild is one you actually understand.