The build began with boundaries
My home lab grew around a simple need: create a place where I could change networks, break services, rebuild servers, and study the outcome without putting everyday systems at risk. Proxmox provided the compute layer, while pfSense, VLANs, Pi-hole, Windows Server, and monitoring became separate parts of one environment I could understand from end to end.
A lab needs an organizing idea
It is easy to add one more machine or one more service. The difficult part is preserving a clear answer to three questions: what is this for, what does it depend on, and how do I recover it?
Separate the layers
Compute, storage, networking, identity, monitoring, and applications should be understandable as separate layers even when they share hardware. That separation makes changes and failures easier to reason about.
Documentation is infrastructure
Diagrams, address plans, service ownership, firewall intent, and recovery notes are not cleanup work. They are part of the system and should evolve with it.
Growth now has a rule
A new node or service earns its place only when its purpose, dependencies, network zone, monitoring, backup, and recovery path are clear. That rule keeps experimentation fast without allowing the lab to become a pile of systems that only work because nobody has touched them recently.
What the lab looks like as a living system
The lab is not one finished installation. It is a controlled environment that changes as I learn. Proxmox clusters provide room for virtual machines and containers, pfSense controls traffic between zones, Pi-hole makes DNS behavior visible, and Grafana with Prometheus shows what the infrastructure is doing over time.
Some projects are temporary by design. I may create a server to test an identity workflow, a monitoring exporter, or a new automation pattern, then remove it once the lesson is documented. Other services become permanent because they support the rest of the environment. Knowing which category a system belongs to determines how much redundancy, backup, monitoring, and documentation it deserves.
The larger lesson has been that growth is not primarily a hardware problem. It is a clarity problem. A small lab with understandable dependencies is more useful than a large one that cannot be recovered confidently. Every rebuild gives me another opportunity to make the layout, naming, security boundaries, and recovery process easier to explain to the next person, including my future self.