Rebuilding My Home Lab: A Tangential DevOps Adventure

Dayton Jones
Devops Category

I’ve always considered my home lab an experimental playground, a place to test out new technology in the quiet comfort of my spare room. While it might not be traditional “DevOps,” re-engineering a home lab has a lot in common with the automation and orchestration principles we use daily in the DevOps world. In fact, it’s those same principles—Ansible for config management, containerization for agile deployments, and carefully planned network segmentation—that motivated me to tear down my old setup and start anew.*

Over the years, I’ve run my share of haphazard networks at home: consumer switches, a second-hand firewall that ran too hot, and a server or two buzzing on a shelf. As time passed and my needs evolved, I realized I needed a fresh start—a brand-new home lab that would handle VLAN segmentation, virtual machines and containers, and a solid firewall to manage traffic and security. This rebuild was significantly more comprehensive than a few system updates. I had a chance to replace aging hardware, rationalize my network topology (hello VLANs!), and adopt modern virtualization and container strategies. Let’s dive into my process.

Why Rebuild?

Before diving into the specific hardware, let’s talk about why I decided to rebuild my home lab from the ground up. It’s not that my old setup was failing. In fact, it worked well enough for hosting smaller services—like a personal wiki, DNS server, and some development sandboxes. But over time, I found myself running more resource-intensive services (Nextcloud, media servers, and testing various container orchestration platforms). My old hardware was outdated, noisy, and limited in terms of VLAN and PoE support. I wanted to do it right this time. My previous setup grew a bit haphazardly. I might spin up a new VM for a project, forget to document it, then find it hogging memory six months later. That chaos, plus some aging hardware that couldn’t handle newer virtualization workloads, convinced me it was time to rebuild from the ground up. This time, I wanted a lab that was:

  • Maintainable – All infrastructure as code where possible.
  • Modular – Containers for lightweight services, VMs for bigger builds.
  • Secure – Proper network segmentation, up-to-date firewall rules.
  • Documented – Well… at least in my code repositories and a notebook. The result? A fresh start with a plan for the future.

Choosing the right hardware

Switches (Managed vs. Unmanaged)

One of the biggest hardware changes in this rebuild was upgrading my switches. Historically, I just used whatever “unmanaged” consumer-grade switches I could find, but with the new lab design, VLAN support was a must-have. An unmanaged switch can’t easily isolate traffic across VLANs; if you want to keep your IoT devices separate from your main workstation or management network, you’ll need a managed switch.

Managed Switch Advantages:

  • VLAN and trunking capabilities.
  • Quality of Service (QoS) controls.
  • Better reporting/monitoring of traffic.

Unmanaged Switch Advantages:

  • Cheaper, easier to install.
  • No configuration needed.

Router/Firewall

I also needed to handle more sophisticated routing and firewall policies. A robust router is vital to a segmented network, especially when you start throwing IoT gadgets onto their own VLAN. There are several open-source firewall options out there—pfSense, OPNsense, etc.—that offer enterprise-grade features on consumer hardware.

What I went with

1. Switches – Juniper EX-2200-C-12P-2G

I needed switches that offered VLAN support, PoE, and some level of manageability. After evaluating a few options, I settled on two Juniper EX-2200-C-12P-2G switches. Yes, they’re end-of-life (EOL) in terms of official support, but they’re budget-friendly on the used market and can still do everything I need: VLANs, PoE for devices, and advanced Layer 2 features. Plus, as a learning exercise, there’s something to be said for working with “real” enterprise gear in a home environment. These Juniper switches let me practice JunOS, which is a great skill to have in my back pocket. Two is probably overkill really, but with the Juniper switches I can set them up in a virtual chassis for easier configurtion (make changes in one, have it propagated, etc) And with two, I had more flixibility in where to place everything (as long as I could run long enough cables without causing tripping hazards!)

2. Firewall/Router – Firewalla Gold

While there are plenty of router/firewall options out there, I’ve grown particularly fond of the Firewalla Gold for its simplicity and power. It’s not a monstrous enterprise firewall, but it’s more than capable of segmenting networks, managing traffic, and securing my home environment. Firewalla’s user-friendly interface is perfect for quick configuration, yet it still exposes enough options for a more advanced setup. Whether you need to block certain domains, set up geo-blocking, or manage multiple VLANs, it does a remarkable job for a home lab scenario. Because of its small footprint, it also integrates seamlessly in my modest rack space.

3. Server – Dell R420 Running Proxmox

I wanted a dedicated server that could handle virtualization and containers, along with some overhead for future expansion. The Dell R420 is a 1U rackmount system offering dual CPU sockets, plenty of RAM expansion, and decent drive options. It’s also easy to find second-hand on sites like eBay or local auctions.

On top of this hardware, I installed Proxmox. If you haven’t used it, Proxmox is an open-source virtualization platform that supports both KVM-based VMs and LXC containers with an intuitive web UI. It struck a balance between powerful virtualization features and ease of use, perfect for a home lab that needs a variety of environments.

4. Sound Dampening, Cooled Enclosure

Let’s be honest: rack servers can get loud. The Dell R420 is no exception (especially when the fans kick into high gear). Because I don’t have a dedicated server room hidden away in a basement, I invested in a sound dampening, cooled enclosure. This enclosure provides airflow and cooling to keep the server at a safe temperature while dampening the noise to a tolerable level. It’s not silent, but it’s much more manageable, and it allows me to place the rack in a more accessible part of the house without driving everyone crazy.

5. Rackmount UPS

Power stability is non-negotiable if you want to protect your gear and avoid abrupt shutdowns. A rackmount UPS (Uninterruptible Power Supply) is essential for clean, reliable power. Look for a UPS that can handle the total power draw of your server, switches, and firewall. Many UPS units also have a monitoring port or network interface that ties into Proxmox or other management software, letting you gracefully shut down in the event of an extended power outage.

Network Design: VLANs

I wanted a network design that would let me keep my IoT devices and experiments isolated from my main LAN. With VLANs, that’s not only possible—it’s relatively straightforward to manage:

  • Management VLAN: For switches, routers, firewall, and other infrastructure devices.
  • IoT VLAN: For smart home gadgets that shouldn’t be able to peek into my private files.
  • Guest VLAN: For visitor Wi-Fi, ensuring no accidental intrusion into my main network.
  • Server VLAN: Hosts my VM and container traffic. This VLAN is dedicated to data center–style traffic and can be further segmented as needed (for example, dev, test, prod).
  • Main LAN VLAN: For general home use, including computers, mobile devices, and streaming boxes.

To configure these VLANs, I took advantage of the Juniper EX-2200’s robust VLAN handling. JunOS configuration often looks like this:

set interfaces ge-0/0/0 unit 0 family ethernet-switching port-mode trunk
set interfaces ge-0/0/0 unit 0 family ethernet-switching vlan members [ VLAN_IDs... ]
set vlans IOT vlan-id 20
set vlans MGMT vlan-id 30

Using a text-based configuration is where Ansible comes in handy. I can keep these VLAN definitions in Ansible inventories/roles and push them out to the switches. This removes the tedium of logging in and manually configuring each switch.

Here’s a snippet of how you might define VLANs in an Ansible playbook for a device like a Netgear or Cisco switch (note that the exact modules and tasks vary by switch brand and Ansible collection):

- name: Configure VLANs on Managed Switch
  hosts: my_switch
  connection: network_cli
  tasks:
    - name: Create VLAN 10 for Management
      net_vlan:
        vlan_id: 10
        name: "Management"
        state: present

    - name: Create VLAN 20 for IoT
      net_vlan:
        vlan_id: 20
        name: "IoT"
        state: present

    - name: Create VLAN 30 for Servers
      net_vlan:
        vlan_id: 30
        name: "Servers"
        state: present

That’s just the basics, but it shows how easily you can integrate VLAN management into a DevOps/automation pipeline.

Virtualization and Containers with Proxmox

As with most things, there were several options for managing my virtual network.

  • ESXi: A solid hypervisor with a long history. Can be resource-intensive but is well-documented.
  • Proxmox VE: A popular open-source platform that combines KVM-based virtualization with containers (LXC).
  • Hyper-V: Primarily Windows-centric, but some folks love it for a home lab.
  • KVM on Linux: Minimal overhead, more manual management (though well-suited to Ansible).

Given my preference for open source and the fact that Proxmox VE integrates virtualization with containers (using LXC) out of the box, I chose Proxmox. It also has a built-in web UI and a vibrant community. Setup was fairly straightforward—boot from a USB stick, configure storage for local or network, and you’re up and running.

On the Proxmox side, I separate my workloads into two main categories:

  1. KVM Virtual Machines for services that need a full-blown OS environment, such as Windows Servers or more complex Linux distributions that I don’t want to meddle with as containers.
  2. LXC Containers for lightweight workloads. I run Ubuntu containers for tasks like small web servers, proxies (NGINX), or DNS/DHCP servers. LXC containers spin up quickly and use fewer resources, making them ideal for most lab services.

Proxmox lets me map each VM or container NIC to a specific VLAN or trunk interface. This means my DNS LXC container can sit on a management VLAN, while a test web server runs on a different VLAN accessible to my main LAN.

Automation with Ansible

“Automate all the things” is a mantra that I’ve always said - I’m inheritantly lazy, so if I have to do something more than once it gets automated. In the new home lab, I rely on Ansible to:

  • Configure VLANs on the Juniper switches.
  • Set up new VMs on Proxmox by using the Proxmox module in Ansible.
  • Deploy services (DNS, DHCP, NGINX) inside LXC containers or VMs.

For instance, let’s say I want to deploy a small container that runs NGINX. With an Ansible playbook, I can automate the container creation, configure the environment, install NGINX, and even manage the firewall rules on Firewalla. An example snippet might look like this:

- name: Create LXC container for NGINX
  proxmox_kvm:
    api_user: "{{ proxmox_user }}"
    api_password: "{{ proxmox_password }}"
    api_host: "{{ proxmox_host }}"
    vmid: 101
    name: nginx-container
    ostype: l26
    storage: local-lvm
    memory: 2048
    cores: 2
    net0: name=eth0,bridge=vmbr0,tag=40
    onboot: 1
  delegate_to: localhost

- name: Install NGINX on container
  hosts: nginx-container
  become: yes
  tasks:
    - name: Update apt and install NGINX
      apt:
        name: nginx
        update_cache: yes
        state: latest

With everything defined as code, it becomes repeatable, traceable, and much easier to maintain. If I want to redeploy or switch containers, I just edit the YAML and rerun the playbook.

Supporting Services

While the above sections cover the main lab components, these supporting services make everything tick smoothly:

  • DNS/DHCP: Running my own DNS and DHCP gives me complete control over hostnames, domain names, and IP reservations. I typically run dnsmasq in an LXC container. It’s lightweight, easy to configure, and works well with dynamic DNS updates.
  • Proxies (NGINX): For inbound HTTP/HTTPS traffic, NGINX is a perfect reverse proxy. It routes requests from the outside world (or from my internal LAN) to the right container or VM. With NGINX, I can also handle SSL termination, basic traffic shaping, and authentication.
  • Monitoring and Logging: Tools like Grafana and Prometheus are excellent for monitoring. Logging is handled with a dedicated ELK (Elasticsearch, Logstash, Kibana) stack in some setups, though a simpler solution like the built-in Syslog server in Proxmox could suffice, depending on needs.

Lessons Learned

  1. Plan VLANs Early: Know which networks you need to separate before starting. It saves a lot of reconfiguration down the road.
  2. Account for Noise and Heat: Rackmount servers can be loud and hot, so plan accordingly with an enclosure or dedicated space.
  3. Automation Pays Off: Even in a small home lab, Ansible or other configuration management tools dramatically reduce overhead.
  4. EOL Hardware Isn’t Always Bad: The Juniper EX-2200-C might be end-of-life, but it’s perfect for a budget home lab if you’re willing to spend some time setting it up.

Rebuilding my home lab was a rewarding experience, blending the joys of tinkering with hardware and the best practices of DevOps-style automation. By selecting the Juniper switches, Firewalla Gold, and a Dell R420 running Proxmox, I’ve laid the foundation for an environment that supports VLAN segmentation, powerful virtualization, and streamlined automation. The final setup, enclosed in a sound-dampening rack with a UPS, gives me confidence that my services will run reliably—and quietly.

Most importantly, I’ve created a space where I can experiment with new technologies, practice automation with Ansible, and safely run everything from DNS servers to media hosting. If you’re thinking about your own home lab, remember that the sky’s the limit—just don’t forget to plan your VLANs, keep things quiet, and automate as much as you can!

Footnote

I did briefly consider going a totally different route, and was looking at Project Mini Rack. If you’re planning a home lab, you might want to take a look and see if it’s right for you!