A homelab is only as useful as the problems it forces you to solve.
I see a lot of people spend significant money on hardware, stand up a few VMs, and then wonder why they’re not learning anything. The hardware isn’t the issue. The approach is.
The goal of a homelab isn’t to have a perfect environment. It’s to have a controlled environment where breaking things has no consequences except the time it takes to fix them.
Start with intent, not hardware
Before buying anything, ask: what do I actually want to understand?
That question should drive every purchasing and configuration decision. If the answer is “I want to understand how enterprise networking works,” then a managed switch, a few VLANs, and a firewall that makes you configure ACLs manually will teach you more than any course.
If the answer is “I want to get comfortable with Linux administration,” then a single physical machine running several VMs under Proxmox or KVM is a better starting point than a full rack.
The stack I landed on
After a few iterations, here’s what I run:
- Hypervisor: Proxmox VE on a repurposed server
- Network: Separate management, production, and lab VLANs with firewall rules between each
- Monitoring: Prometheus and Grafana for metrics, Loki for log aggregation
- DNS: Pi-hole for local DNS resolution and ad filtering
None of this is groundbreaking. The value is in having configured it yourself, broken it, and had to trace down why it stopped working.
What actually teaches you
Running a service teaches you far less than debugging a service that stopped working at 2am.
When I lost DNS resolution across the lab network last year, I learned more about how DNS caching works in three hours of troubleshooting than I had in months of reading. That experience is durable in a way that documentation is not.
The homelab creates those situations on demand. You get to be the person who broke it and the person who has to fix it.
The next step
Document everything. The act of writing down what you built and why forces you to understand it well enough to explain it. If you can’t explain a configuration decision, you probably don’t understand it yet — and that’s fine. It just means you have more to learn.
That’s the whole point.