The Domesticated Lab
From learner lab to home service provider
When the House Started Depending on It
My home lab was never some dramatic basement rack situation. For a long time it lived under my desk or in a corner, wherever I could make it fit. Eventually it started consolidating. A closet turned into the technology closet. The gear got a home. The cables became less embarrassing. The noise got managed. What used to feel like “stuff I’m messing with” slowly started behaving like something I was operating.
The real shift wasn’t the closet. It was the moment it stopped being “my gear” and started being “the house.” The firewall became the front door. Switches with PoE started feeding cameras. Servers took on real jobs like Plex, plus the other 30 containers that exist somewhere between useful and just plain fun. Once your home network depends on a stack you built, downtime stops being a learning moment and starts being a household problem.
When I talk about the learner lab, the emphasis was exposure. Cheap hardware was fine. Rebuilds were expected. Breaking things was part of the curriculum. That environment existed to stretch skills. This one is different. It still teaches, but it carries responsibility. Once core services and household dependencies live in the same environment you experiment in, your tolerance for risk changes. You don’t stop learning. You just stop learning recklessly.
The wife aggro factor became real. Work-from-home meant the internet wasn’t optional anymore. The kids became a monitoring system with exactly one alert level: “Plex is broken” or “the WiFi is down,” delivered at full volume from the other room. When that starts happening, you can’t run the lab like a scratch pad. You either separate learning from household dependencies, or you accept that every experiment comes with risk and cleanup.
I’m sure some folks would build this differently. That’s fine. But when your lab is down for two weeks because you built a clever two-node virtualization cluster on non-redundant storage due to budget constraints, you learn something real about recovery. At home, the best architecture in the world doesn’t matter if you can’t recover quickly when something goes sideways.
My solutions matured over time. Each decision weighed risk differently than it would have five years ago. This post walks through what’s in the technology closet and why those decisions shifted as the lab moved from learner territory to household infrastructure. It’s not a blueprint. It’s the setup that solved my problems, and the reasoning that kept me from rebuilding the same thing every other weekend.
Firewall and Router
My firewall is OPNsense, running on a small custom-built box instead of an off-the-shelf appliance. I wanted something I could control, repair, and expand. I didn’t want a black box that folded the moment I asked it to do more than basic routing.
The bigger reason is philosophical. OPNsense brings a lot of enterprise-style capabilities to the table without dragging along a subscription bill. It feels closer to platforms like pfSense, and it lets me apply practical firewall concepts that actually translate outside the house. For a while Cisco ASA was the go-to in many environments, and I even ran the free version of Sophos at one point. Both worked. But over time I settled on OPNsense because it gives me stable routing, segmentation, VPN capability, and security tooling in a way that feels serious without being expensive.
Small practical note: the Ryzen 5 4500 doesn’t have integrated graphics. I had to throw in a cheap GPU just to get video output during setup and troubleshooting. It’s one of those details you only forget once.
Firewall Hardware Specifications
- OS: OPNsense
- Motherboard: ASRock B450M-HDV R4.0 (AM4, B450 chipset, micro-ATX)
- CPU: AMD Ryzen 5 4500
- Memory: Team T-FORCE VULCAN Z 32GB (2 x 16GB) DDR4-3200
- Chassis: Rosewill RSV-Z2800U 2U rackmount
- Graphics: Inexpensive discrete GPU (no iGPU on CPU)
Networking
I’m running a Cisco WS-C3750G-48PS. It was given to me by a network engineer friend, which makes it very hard to complain about. The decision here is mostly about port density, VLAN capability, and PoE. Forty-eight ports means I realistically won’t run out. VLAN support gives me proper segmentation between trusted devices, lab networks, cameras, and whatever I’m testing that week. PoE means inline power without needing injectors scattered everywhere. Cameras and access points plug in and just work.
I’ve looked seriously at the Ubiquiti USW-Pro-48-PoE and the USW-Pro-24-PoE. The 24-port is attractive financially, but I’m not convinced I can realistically shrink long term. Once you get used to 48 ports, 24 feels like planning future regret.
For now, the Cisco stays. It was free, it’s stable, and it still does exactly what I need it to do. In a domesticated lab, stability and port density usually win over aesthetics.
Switch Specifications
- 48 x 10/100/1000 Ethernet ports
- 802.3af PoE support
- ~370W PoE budget
- 4 x 1G SFP uplinks
- Layer 3 capable
Wireless
Ubiquiti hit a sweet spot for me. It gave me a lot of enterprise-style configuration options in a package that didn’t require enterprise pricing. Central management, VLAN tagging, multiple SSIDs, guest isolation, and decent visibility into what the wireless network is doing all matter more than raw speed numbers.
They’ve been solid overall and still cover the house well. They’re showing their age a bit — occasional roaming quirks, the rare drop — but nothing dramatic.
They’re on the short list for an upgrade. Until the family starts yelling about WiFi, they stay.
UAP-AC-Lite
- 802.11ac Wave 1
- Dual-band 2x2 MIMO
- 300 Mbps (2.4 GHz) / 867 Mbps (5 GHz)
- 802.3af PoE
UAP-AC-LR
- 802.11ac Wave 1
- 3x3 MIMO (2.4 GHz), 2x2 (5 GHz)
- 450 Mbps (2.4 GHz) / 867 Mbps (5 GHz)
- 802.3af PoE
Core Compute
Core compute has been a funny area over the years because I’ve rarely had to shop for it like a normal person. I’ve had access to retired gear from work, so instead of price-optimizing I’ve mostly been scavenging the biggest, baddest thing I can responsibly drag home. That’s also why this part of the lab has changed more than the rest. When the hardware is “available” instead of “purchased,” it’s easier to experiment.
For a while I ran a chunk of the environment on Dell OptiPlex 3080 micro boxes with upgraded RAM. I had three of them online at once, and instead of building a full virtualization stack I just ran workloads directly on the hosts. It worked, and it was kind of great in a scrappy way. Low power, quiet, easy to tuck away, and if one died it didn’t take the whole house down with it.
Today core compute is a Dell Precision Tower 5810 running Proxmox. It has enough horsepower to host Plex and the container fleet without turning into a second job. I could run Rocky Linux directly on bare metal, but Proxmox makes the “rebuild the host” scenario way less dramatic.
VM backups land on the Synology over NFS. If this box dies, the playbook is simple: reinstall Proxmox, reconnect storage, restore, and keep moving.
The only real limitation is age. The Xeon E5-2630 v4 is Broadwell-era. Linux is fine. Windows 11 is officially unsupported on this CPU, and I treat it that way.
Hardware Specifications
- Dell Precision Tower 5810
- Intel Xeon E5-2630 v4 (10c/20t, 2.20 GHz)
- 128 GB RAM
- 1 TB SK hynix SC311 SATA SSD
- 2 x 1 TB WD Black (WD1003FZEX)
Storage
Storage is where I stopped trying to be clever.
I’m running a Synology RS2423+ today. Before that I ran a DS1815+ for about nine years, and that runtime matters when you’re judging the decision. It wasn’t the cheapest option up front, but spread across nine years the cost per month becomes pretty reasonable. That box paid for itself in stability.
And honestly, I believe I would have gotten even more life out of it if the hardware design at the core had been more durable. The DS1815+ lived through the Intel Atom C2000 era and eventually failed twice on me — once tied to the Intel Atom C2000 “clock signal”/LPC clock degradation issue (the AVR54 erratum that could brick devices and prevent them from booting), and once from a power issue. Call it known problems or bad luck, either way it drove the point home: you can fix configuration mistakes. You can recover from bad updates. But you can’t “tune” your way out of a flawed hardware platform.
I did the research on custom NAS builds. I went deep enough to convince myself I could do it. But the deeper I went, the more I realized I was turning my most important data into a hobby project. For a learner lab, that’s fine. For a domesticated lab, it’s a bad trade.
So my decision wasn’t “Synology is best.” It was “I’m prioritizing stability over optimization.” I want storage to be calm and predictable. I want updates that don’t feel like a gamble. I want easy monitoring. I want a platform where replacing the chassis doesn’t mean rebuilding my life from scratch.
That’s why the RS2423+ was the right move for me. Migration was the win: I moved the existing disks over, imported the configuration, and got back online without rebuilding everything from scratch. After the upgrade, I added four more 4TB drives and landed at about 31.4 TB usable.
Next growth step is straightforward: larger drives when prices drop or when I catch a deal.
RS2423+ Specifications
- 12 x 3.5" / 2.5" bays
- AMD Ryzen V1500B (4c/8t)
- 8 GB DDR4 ECC (expandable)
- 4 x 1GbE (expandable via PCIe)
- PCIe for 10GbE or NVMe cache
- SHR / RAID 5/6/10
