Yuvin Walker· LinkedIn Article Series
Yuvin Walker
Lab LogArticle 5 of 24·

My Home Lab: Pi-hole and WireGuard on Docker

A small Ubuntu server at home has taught me more about networking and security than any single course. Here's how it's built, and why every IT pro should have one.

Code on a monitor beside a mechanical keyboard on a home desk
Photo: Pexels · Pexels

Every IT professional I respect has a place where they're allowed to break things. For some, it's a test environment at work. For me, it's a small server at home.

My home lab is an Ubuntu server running containerized services in Docker. The two services I use most are Pi-hole, which filters DNS for my whole network, and WireGuard, which gives me secure remote access back into it. It isn't large or expensive. But it has taught me more about networking, Linux and security than any single course, because I'm the one responsible when something stops working.

This article walks through the setup, what each piece does and the lessons I've taken from it. If you're thinking about building your own lab, I hope it helps you get started.

Why build a home lab at all?

Courses and certifications teach concepts. A lab teaches consequences.

When I studied Cybersecurity and Threat Management at Seneca Polytechnic, I learned how DNS filtering, VPNs, patching and hardening work in principle. Running them myself showed me what happens in practice: the update that breaks a container, the firewall rule that blocks more than intended, the configuration that works perfectly until the router restarts.

A lab also gives you something concrete to talk about in interviews. Saying "I understand VPNs" is fine. Saying "I run a WireGuard server at home, and here's how I configured the keys and firewall rules" is much stronger.

The overall design

The setup is deliberately simple:

  • A home router that connects my network to the internet.
  • An Ubuntu Server machine on the home network with a fixed IP address.
  • Docker running on that server, with each service in its own container.
  • Pi-hole in one container, acting as the DNS server for every device at home.
  • WireGuard in another container, listening for encrypted connections from my laptop or phone when I'm away.
  • A single port forward on the router for WireGuard, and nothing else exposed to the internet.

Everything at home asks Pi-hole for DNS. When I'm away, my devices connect through WireGuard and use Pi-hole as if they were at home.

Why Ubuntu Server and Docker

I chose Ubuntu Server because it's widely used in industry, well documented and stable. Running it without a desktop keeps the system lean and forces me to work from the command line, which is exactly the skill I want to build.

Docker lets me run each service in an isolated container with its own configuration. The benefits became clear quickly:

  • Clean separation. If one service misbehaves, it doesn't affect the others or the host.
  • Easy rebuilds. Configuration lives in a Docker Compose file plus a few mounted folders. If I break something badly, I can recreate it in minutes.
  • Safe updates. I can pull a new image, test it and roll back if something goes wrong.
  • Documentation by default. The Compose file is a written record of exactly how each service runs.

Pi-hole: DNS filtering for the whole network

Pi-hole is a DNS server that blocks requests to known advertising, tracking and malicious domains. Instead of installing an ad blocker on every device, you point your network's DNS to Pi-hole, and it filters for everything: laptops, phones, smart TVs and devices that can't run blockers at all.

I configured my router to hand out Pi-hole's address as the DNS server through DHCP, so new devices use it automatically. Pi-hole forwards allowed requests to an upstream resolver and answers blocked ones with nothing.

What Pi-hole taught me:

  • How much background traffic devices generate. The query log shows a constant stream of requests from apps and smart devices, many to analytics and tracking domains. It's an eye-opening view of what normal looks like on a network.
  • How DNS filtering works as a security control. Many organizations use the same idea at a larger scale to block known malicious domains before a connection is even made.
  • How to troubleshoot it. Occasionally a legitimate site breaks because a domain it relies on is on a blocklist. Finding it in the log and allowing it is a small, realistic troubleshooting exercise.
  • Why DNS must be resilient. If the Pi-hole container goes down, the whole house loses name resolution. That lesson in single points of failure is exactly why companies run more than one DNS server.

WireGuard: secure remote access

WireGuard is a modern VPN protocol known for being fast, simple and built on current cryptography. Each device has a public and private key pair, and the server only accepts connections from peers whose public keys it knows.

In my setup, the router forwards one UDP port to the WireGuard container. My laptop and phone each have their own key pair and configuration. When I connect, all my traffic, or just traffic for my home network depending on the configuration, travels through an encrypted tunnel to the server.

What WireGuard taught me:

  • Key management matters. Each device gets its own keys. If I lose a phone, I remove that one peer without affecting the others. That's the same principle as revoking a single user's access instead of changing a shared password.
  • Exposing services is a decision. I keep only one port open, and only for a service designed to be exposed. Everything else stays private behind the VPN.
  • Split tunnelling has trade-offs. Sending all traffic through the tunnel protects me on public Wi-Fi but adds latency. Sending only home traffic is faster but less protective. Understanding that trade-off helps when evaluating corporate VPN policies.
  • Testing from outside is essential. A VPN that works from inside the house proves nothing. I test from mobile data to make sure it truly works remotely.

Mistakes that taught me the most

The lab has broken many times, and each failure taught me something I now apply at work.

Forgetting that DNS is a dependency. Early on, I restarted the server for an update without thinking. For a few minutes, every device in the house lost name resolution, and everyone noticed. The lesson: know what depends on the system you're changing, and plan changes for a quiet time. That's change management in miniature.

Pinning nothing. Pulling the latest version of an image every time felt convenient until an update changed a setting and broke a service. Now I note which version I'm running, read release notes before major updates and keep the previous image available so I can roll back.

Port conflicts. Pi-hole needs port 53 for DNS, and on Ubuntu a system service was already listening there. Working out which process held the port, and how to change it safely, taught me more about Linux networking than any tutorial.

Not writing it down. The first time I rebuilt a container from scratch, I realized I couldn't remember half the settings I'd changed. Since then, every change goes into my notes and the Compose file. Documentation isn't extra work. It's what makes recovery possible.

Testing only the happy path. My VPN worked perfectly from my living room. It took a test from mobile data to discover a firewall rule was missing. Now I always test from the user's real position, not just the convenient one.

Keeping the lab secure

A home server is still a server, and it deserves the same care as one at work. My routine includes:

  • Regular updates for Ubuntu and for each container image.
  • SSH key authentication instead of passwords, with password login disabled.
  • A host firewall that allows only the ports I actually need.
  • Backups of configuration, so a failed disk is an inconvenience rather than a disaster.
  • Reviewing logs now and then for anything unusual.

What I'd add next

A lab is never finished, and that's part of the appeal. My next steps are to add a log collection and monitoring tool so I can practise detection the way a security operations team would, to build a small Windows domain for Active Directory practice, and to experiment with a dedicated firewall appliance. Each of these mirrors tools I'll meet in security and network administration roles.

How to start your own

You don't need expensive hardware. An old laptop, a small desktop or a single-board computer is plenty. Here's a simple path:

  1. Install Ubuntu Server and give the machine a fixed IP address.
  2. Learn basic Linux administration: users, updates, SSH and the firewall.
  3. Install Docker and Docker Compose.
  4. Deploy Pi-hole and point one device at it, then your whole network.
  5. Add WireGuard and test it from outside your home network.
  6. Write down everything you do. Your notes will become your best reference, and great material for interviews.

The goal isn't to build something impressive. It's to build something you understand completely, because you set up every part of it yourself.

Do you run a home lab? What's the most useful thing it has taught you?

About the author

Yuvin Walker is a cybersecurity and network specialist in Toronto. He has supported a 1,200-user manufacturing site and an internet service provider’s customers, holds the Certified Ethical Hacker (CEH) credential and a BEng in Computer Network and Security, and completed postgraduate programs in Cybersecurity and Threat Management and IT Project Management at Seneca Polytechnic.

Connect: LinkedIn · yuvinwalker@gmail.com

Share this article

My home lab is an Ubuntu server running Pi-hole and WireGuard in Docker. It's where I practise patching, hardening and troubleshooting before I do it for real. Here's the setup, what it taught me, and how to start your own. #HomeLab #Docker #PiHole #WireGuard #Linux

Share on LinkedIn ↗