Why I run my own home lab

March 19, 2025

I work day-to-day in cyber security. From a background in hacking to security architecture I have worked across many aspects of information technology. My background is primarily that of a software developer, but I have always believed that in order to appropriately secure something, you must have a foundational understanding of it. For that reason, I embarked on building my own home lab so that I can quickly and easily learn and practice new concepts.

This blog is going over the basics of my home lab configuration. I will cover the basic setup, network devices, network configuration, server configuration and things I have learnt.

The goals of a home lab

So why even have a home lab? What do I want to achieve? Outside of just playing with technology I wanted to ensure my home lab was actually useful. With this in mind, I decided on a list of outcomes I needed to achieve.

I wanted to ensure I could deliver the following outcomes:

  1. Multiple networks to allow visitors access to the Internet without security risks.
  2. My file server is accessible from laptops, TV and desktops.
  3. I can run my own servers inside to save on subscription costs (e.g., email, web hosting).
  4. I can do local and remote development on Windows, Linux and MacOS.
  5. I can host internal services for streaming media and blocking ads/malware/malicious domains.

The basic setup

My basic setup operates out of a full height server rack in my garage. This was something I purchased for $50 locally from a network engineer who was upgrading his own home lab setup.

I have:

  1. 3x servers (2x Tower, 1x Rack-mount)
  2. 1x 24-port Cisco Switch
  3. 3x Ubiquti power-over-Ethernet wireless access points
  4. 2x Ubiquti edge-routers
  5. 1x MacOs Mini M1
  6. 5x Raspberry Pi 4B
  7. 1x Intel NUC (Retired)
  8. 1x Dual Nic Intel NUC (Retired)

Connecting to my network would be my desktop, multiple phones, tvs and gaming consoles.

Network configuration

One of the biggest outcomes I wanted to achieve was network segregation between my personal systems and wireless devices. Devices that connect to a wireless network would be considered "untrusted" and would be limited to Internet connectivity only. This would essentially create a guest wireless network that any visiting friends and family could use while separating devices I generally don't trust (e.g., TVs).

I decided on running three different networks (VLAN-0, VLAN-10, VLAN-20).

  1. VLAN-0 would be my 192.168.0.0/24 network for trusted devices. Hardwired devices only.
  2. VLAN-10 would be my 192.168.1.0/24 network for untrusted devices. Wireless network connectivity primarily.
  3. VLAN-20 would be my 192.168.2.0/24 network for highly untrusted devices and segmented testing.

In retrospect, the VLAN-20 network wasn't needed. I decommissioned it after about 12 months as it didn't provide any added value and having to map connectivity through the internal router was more hassle than it was worth. So I ended up with two networks, trusted (VLAN-0) and untrusted (VLAN-10).

The trusted network would host my desktop, file server, development server and primary network interfaces for networking devices. The untrusted network would be my wireless network where TVs, phones, gaming consoles, laptops and guests/family could connect to.

One thing I did purposely decide on was having my Internet router on the VLAN-0 trusted network. This ensured I had minimal devices (hops) between my desktop that I use for gaming and the Internet. Should I encounter any networking issues from my desktop I could quickly eliminate my internet network as the cause.

A final note on networking was that my Cisco switch supported port-to-VLAN mapping. I can map physical network ports to different VLANs allowing me to use that as the primary means of network segmentation. Some ports, like my desktop, supported both untagged and tagged data allowing me to swap networks if I needed to diagnose or debug anything.

Device configuration

Being someone who likes the classics, I decided to go with primarily Greek/Roman/Egyptian Gods and related for my naming scheme. I decided upon the following use-cases for my devices.

  1. Thoth (OpenSuSe Linux) - Development server, hosts gaming servers, runs docker containers and is used as a VSCode Linux remote host.
  2. Osiris (OpenSuse Linux) - File server, runs docker containers for internal and network services.
  3. Amun (OpenSuse Linux) - Network jump-host. Was retired because it wasn't that helpful when I started to pin-hole firewall rules.
  4. Isis (OpenSuSe Linux) - Reverse proxy for server web sites and handling Let's Encrypt certificate automation. Retired when it died.
  5. Denwen (Cisco switch) - Network connectivity and VLAN mapping.
  6. Tartarus (Ubiquti WAPs) - Wireless network for VLAN-10 spanning across three access points.
  7. Bast - (Promox) - Virtual machine hypervisor for running internal VM services.
  8. Aten - (Ubiquiti Router) - Internet connectivity
  9. Babi (Ubiquiti Router) - Internal network router

Now, Admittedly when I first created my home lab I had ran three wireless networks, one for each VLAN. In the end I found that I didn't really use any other than the Tartarus network because it had three access points and could deliver high speed connectivity anywhere in my house.

In terms of Linux distribution. I started using Linux in 1999 with Redhat and Slackware. Over the years I've used 10s of distributions but for whatever reason a few years ago I settled on using OpenSuSe. I run exclusively OpenSuSe Tumbleweed, an ultra-modern rolling release that allows me to have the latest versions of tooling like C++ compilers. I've honestly found OpenSuSe to be wonderful to use and never have I experienced a system issue with their update/upgrade system. If I was not using OpenSuSe, I'd honestly probably use Ubuntu, Mint, or Debian.

My services

The great benefit and fun of a home lab is running lots of services. Below is a list of what I am currently running and how.

  1. PiHole DNS black-hole - Docker container on Thoth, with backup docker container on Osiris. Routers configured to forward all DNS traffic to these. Any device on my network is automatically using these and it makes a difference with Internet speeds.
  2. MySQL server - Docker container on Thoth, this is used by my Discord Bot and Web application development.
  3. Nginx servers - Docker containers on Osiris and Thoth
  4. Kubernetes Cluster - Spread across 4x Raspberry Pis. Just used for fun and testing K8s deployments
  5. Email Server - Docker with macvlan on Osiris, this hosts some low-value domain email for me.
  6. Nginx Proxy Manager - Docker with macvlan on Osiris, this provides Internet front door and Let's Encrypt automation for hosting web apps.
  7. Custom Discord Bot - Docker containers on Thoth, this is used for retro video game collecting.
  8. Jellyfin - Docker container on Osiris, media streaming to my phones, gaming consoles and TVs.

The majority of my services are hosted as docker containers using macvlan. This allows me to spin up each docker container with it's own network connected IP address. This is a great solution as I can monitor different IP addresses, avoid host/container and container/container port collisions. As I run my networks across two subdomains, I have ~512 available addresses to use which is way more than I'll ever need.

I would like to note that I don't run Docker and Kubernetes (K8s) on the same system because K8s servers will introduce a number of firewall routes that mess with routing. This can cause networking conflicts between Docker and K8s. Docker will happily deploy a container with a specific port, but that port is never reachable because K8s has introduced a firewall rule (IP chain/tables) routing it to another port for it's own usage. For this reason, I separate Docker and K8s installations.

Network connectivity

Network connectivity turned out to be one of the biggest issues for me. I underestimated how many devices would need to actually communicate across the networks. Some of the more common examples that I needed to handle pretty quickly were:

  1. Running a DNS black hole meant every device would need to be able to access an internal DNS server.
  2. Our own laptops would need to access the internal file server.
  3. Televisions would need to access the file server for media streaming.
  4. My desktop computer would need to connect to the Raspberry Pi Kubernetes devices.
  5. My development server would need to connect to the Raspberry Pi Kubernetes devices.

This resulted in me having to do two things.

  1. Get rid of the VLAN-20 because it didn't provide any value.
  2. Important devices on the VLAN-10 untrusted network were DHCP'd static IP addresses by the internal router.
  3. I set up firewall bypass rules on the internal router to allow required devices point-to-point connectivity.

Services I operate

My home lab design has changed over the years, but I have ultimately settled on the following services that I run internally:

  1. Email server for my low-value domains.
  2. DNS server to black-hole advertisements and malicious domains.
  3. SSH server for Linux and Kubernetes administration.
  4. SSH for SFTP and SCP file transfers.
  5. Nginx Web Services for hosting low-value web projects.
  6. Nginx Proxy Manager for routing different virtual hosts and domains.
  7. Discord-Bot for monitoring retro video game auctions.
  8. MySQL databases
  9. Certificate authority (sometimes)

My learnings - Is it worth it?

Is it worth it to run your own home lab? I definitely think so.

As someone who is responsible for the cyber security of organisations, a home lab allows me to quickly and easily test new products and practice new ideas. I am not limited by what is available to me professionally, or the approval process to gain access to something. I want to deploy something to Kubernetes, done!, What to test some network monitoring tool? Easy!. Build and deploy my own Docker containers so I can learn how they operate to understand how to best secure them? Yep!

I have also extended my home lab with direct connectivity to a cloud hosted Kubernetes cluster. I can develop in my home lab, create docker containers, push them to a docker registry and then re-deploy my k8s deployments. My end-to-end development to production process is simple, quick and highly secure.

My background is primarily in software development, but having a home lab has made me proficient in networking. I have successfully delivered two projects with significant network components.

  1. The largest live broadcaster in New Zealand did an entire system upgrade. I was responsible for the design of a nationwide network used for real-time broadcasting of high-definition video. This was tied directly to 80% of the companies revenue. The project had added complexity where part of our network was located in control rooms in the back of trucks and would move physical locations.
  2. We needed to deliver financial information within seconds across a nationwide WAN to 380 different locations. We ended up using ~380 Raspberry Pis that would poll a pair of squid proxies for the updated information, then transmit that information over local RF loops for analogue TV display.