Why I Stopped Building My Home Lab Like Work
The Pattern
For a long time, I was proud of my home lab. I had a two-node setup running under a VMUG subscription, and I was using my Synology as shared NFS storage. I was not just spinning up random test machines. I had services running that I genuinely depended on: a Windows mail server, Plex, a voice server, and a handful of utility systems that quietly became part of my routine.
The setup felt familiar because it looked like the environments I have built professionally. Shared storage gave me a clean model for where everything lived, and two nodes gave me that comforting sense of redundancy. The lab did not just run. It ran in a way that felt structured and deliberate. I did not spend much time questioning the assumptions underneath it because nothing was forcing me to.
Even when everything was working, the balance of the design was not what I thought it was. The compute looked redundant, but the storage was singular. In practice, the Synology was not just storage. It was the foundation. Both nodes depended on it equally, and all the important workloads lived on top of it.
At work, patterns like this are supported by layers of safety that you almost stop noticing. There are redundant storage paths, spare hardware, contracts, and options when something fails. At home, the pattern still looks clean, but the safety net is whatever you happen to have on hand and how quickly you can recover when something goes wrong.
I reproduced the structure, but not the conditions that make it resilient.
It looked like redundancy. It behaved like dependency.
The Break
One night the Synology took a hard error. It was not gradual. It was not something I could smooth over with restarts. The shared NFS storage dropped and the lab collapsed almost immediately. Virtual machines did not degrade. They failed in the way systems fail when the layer they depend on disappears.
What stands out to me is how quickly the situation shifted from troubleshooting to acceptance. In the first few minutes you want to believe it is something small. A mount that will reconnect. A service that needs restarting. But when storage goes hard down, you feel it. Both hypervisors could have been perfectly healthy and it would not have mattered. Without the datastore, the environment was simply gone.
The turning point was realizing this was not going to be fixed that night. The Synology had to go out under warranty, which meant I was going to be without it for a while. That while turned into nearly two weeks.
Two weeks is long enough that you stop treating it like an outage and start treating it like a gap in your life. Media, services, lab workloads, all of it was simply unavailable because one device failed and it happened to be the device everything was built around.
I have handled failures in professional environments where there are options. At home, the failure does not just take down a service. It takes down your ability to recreate that service quickly, and it forces you to live with the downtime while you wait on hardware.
The part that hurt was not the outage. It was being stuck.
The Decision
When the replacement Synology finally arrived, I got lucky. The failure ended up being purely hardware related, and they shipped me a new unit under warranty.
This is also where I will give Synology credit. If you have never swapped disks from one Synology to another, it is one of the coolest things since sliced bread. I expected a long, painful rebuild weekend. Instead, I moved the drives, the system recognized what it needed to recognize, and I was back in business far faster than I deserved to be.
Once storage was back, I fired back up what I had. I needed my services running again, and the quickest path was getting the existing environment online. That recovery was the relief I needed, but it did not erase what happened. It just gave me enough space to think clearly again.
At that point I started researching what a new solution could look like. Not a slightly different version of the same cluster, but an approach that fit a home lab better than the work patterns I had copied.
That is where I ran into containers.
What surprised me was how many of my “VM problems” were really just “service delivery problems.” Most of what I was running did not need a full virtual machine. It needed a clean way to run a service, keep configuration sane, persist data, and make rebuilds predictable.
Containers gave me a path into that, and they kick started an iterative learning loop that actually stuck. I started small, moved one service, learned the basics, then learned the next tool I needed to deploy it properly. Networking, volumes, updates, restarts, reverse proxies, logging. Each step taught me something useful without requiring me to rebuild the whole environment to make progress.
They also gave me a better way into Linux. I have installed enough software the old way to know how easily it turns into a mess. You follow a guide that is slightly wrong for your distro, dependencies drift, package names do not match, and suddenly you are spending hours debugging the installer instead of learning the thing you actually wanted to run. With Docker, I could focus on learning Linux fundamentals and the operational side of running services, without constantly getting stuck in install guide roulette.
That is really what changed for me. Containers were not just a technical preference. They became a learning accelerator, and they gave me a path away from building a home environment that behaves like a production cluster without the safety net to back it up.
The cluster came back. My confidence in the design did not.
