← Back to Latest

How to Build a Modern Home Lab: pfSense, Docker, and Self-Hosted Services in 2026

A home lab used to mean a loud tower under your desk, a switch with half a dozen cables, and a rack you wished was smaller. In 2026, the practical home lab is quieter, smaller, and more capable than ever — a single mini-PC can run a firewall, a container host, and a dozen self-hosted services without becoming a space heater. This guide walks through building one: a pfSense firewall, a Docker Compose host, and a set of self-hosted services that cover the basics most people actually want.

The goal is not to replicate an enterprise data center in your closet. The goal is to get to a working, maintainable setup that teaches you something, gives you control over your own services, and does not require a dedicated server room.

What You Actually Need

The minimal practical home lab in 2026 runs on a single mini-PC — something like an Intel N100 or N305 machine, or an AMD Ryzen-based small form factor system. The N100 machines are cheap, quiet, and power-efficient enough to leave on 24/7 without guilt. The Ryzen machines give you more cores and more RAM for heavier workloads, at the cost of more power and a higher purchase price.

You will also want:

• At least 32GB of RAM — 16GB is workable for a bare-bones lab, but 32GB gives you room to run pfSense in a VM, a container host, and a few heavier services without constant memory pressure.
• NVMe storage — a 500GB or 1TB NVMe for the lab OS and containers. NAS storage is a separate decision; do not confuse the two.
• One or two additional NICs — if the mini-PC has only one Ethernet port, add a second. You will want at least two for a proper pfSense setup with a WAN and a LAN interface.
• A small UPS — not strictly required, but a UPS that can handle a clean shutdown makes the difference between "annoying restart" and "corrupted container database."
• A managed switch (optional but useful) — if you want VLANs, a managed switch lets you segment the lab network from your home network without rebuilding your entire home network.

Step 1: pfSense as the Firewall and Router

The firewall is the foundation. Everything else in the lab sits behind it. pfSense is the standard choice for a reason — it is free, well-documented, and does the job without requiring a subscription.

The practical setup is a VM, not bare metal, on the mini-PC. Give pfSense two virtual NICs: one bridged to the physical NIC that connects to your modem or existing router (the WAN side), and one on an internal virtual network (the LAN side). The LAN side becomes the network your lab services run on.

There is a choice here. You can replace your home router with pfSense, or you can put pfSense behind your existing router and use it as the lab's internal firewall. The first option gives you full control but requires you to reconfigure your home network. The second option is less disruptive and is the better choice if you are not ready to make your home network depend on a lab project.

For a first lab, the second option — pfSense behind an existing router, managing a dedicated lab VLAN — is the safer bet. You keep your home network working, and you get to experiment with firewall rules, VLANs, and traffic shaping without risking your family's Wi-Fi.

# Example: pfSense lab VLAN interface setup (conceptual)
# WAN: em0 — bridged to physical NIC, DHCP from existing router
# LAN: em1 — lab VLAN 10, 192.168.10.1/24
# OPT1: em2 — IoT VLAN 20, 192.168.20.1/24 (blocked from LAN by default)

The minimum firewall rules you want: block everything from WAN by default; allow established/related traffic back in; on the LAN side, allow the lab to reach the internet but block lab-to-home-network traffic unless you explicitly want it; on the IoT VLAN, block inbound and restrict outbound to the specific protocols the devices need.

The IoT VLAN rule is the one that teaches you something. Most IoT devices phone home to cloud services you do not control. Putting them on a separate VLAN with restricted outbound access — and logging the blocked traffic so you can see what they are trying to reach — is one of the most educational things a home lab can teach you about your own network.

Step 2: Docker Compose as the Service Layer

Once pfSense is running, the next layer is a Linux VM or a bare-metal Linux install that runs Docker Compose. Do not run Docker on pfSense — that is not what pfSense is for, and it will make your life worse.

A Debian or Ubuntu server VM works well. Alpine is lighter but the container ecosystem tooling is slightly less smooth. Pick whichever you are more comfortable troubleshooting at 2 AM.

The Compose file is where your lab becomes a set of services instead of a collection of manual installs. A reasonable first Compose stack looks like this:

version: "3.8"
services:
  traefik:
    image: traefik:v3
    restart: unless-stopped
    ports: ["80:80", "443:443"]
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock:ro
      - ./traefik:/etc/traefik
    networks: [lab]

  portainer:
    image: portainer/portainer-ce
    restart: unless-stopped
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock:ro
      - portainer_data:/data
    labels:
      - "traefik.http.routers.portainer.rule=Host(\`portainer.lab\`)"
    networks: [lab]

  wg-easy:
    image: ghcr.io/wg-easy/wg-easy
    restart: unless-stopped
    environment:
      - WG_HOST=your-lab-public-ip
      - PASSWORD=set-a-real-password
    ports: ["51820:51820/udp", "51821:51821"]
    cap_add: ["NET_ADMIN"]
    networks: [lab]

  uptime-kuma:
    image: louislam/uptime-kuma
    restart: unless-stopped
    volumes:
      - uptime_data:/app/data
    labels:
      - "traefik.http.routers.uptime.rule=Host(\`status.lab\`)"
    networks: [lab]

volumes:
  portainer_data:
  uptime_data:

networks:
  lab:
    driver: bridge

Traefik in front of the stack gives you automatic HTTPS via Let's Encrypt — either via DNS challenge (if your domain's DNS is accessible from the lab) or via a self-signed certificate for internal-only services. Portainer gives you a UI for container management. wg-easy gives you a WireGuard VPN into the lab so you can reach services securely from outside without exposing them to the internet. Uptime Kuma gives you monitoring and alerts.

The labels on each service tell Traefik how to route traffic. The pattern — a reverse proxy in front of containerized services, each with its own subdomain — is the same pattern that scales from a home lab to a production deployment. Learning it at home is not wasted effort.

Step 3: Self-Hosted Services Worth Running

The services that make a home lab feel useful are the ones you actually use. The list varies, but the common ones are:

• Ad-blocking DNS — Pi-hole or AdGuard Home. This is the service that makes the lab visible to everyone in the house, because it blocks ads on every device that uses it as its DNS server.
• Password manager — Vaultwarden (a lightweight Bitwarden-compatible server) or a self-hosted KeePass database. The self-hosted password manager is the service that teaches you about backups, because a lost password database is a real problem.
• File sync — Syncthing for device-to-device sync, or Nextcloud if you want a full file-sharing platform. Syncthing is simpler and more robust for personal use; Nextcloud is more capable and more complex.
• Media — Jellyfin for personal media, if you have media to serve.
• Home automation — Home Assistant if you have smart home devices you want to integrate locally.
• Backups — a backup service that backs up the lab itself, because a home lab that is not backed up is a home lab that will lose its data.

Do not install all of these on day one. Start with Traefik, Portainer, wg-easy, and Uptime Kuma. Add one more service at a time. The lab that breaks on day one because you installed six services you do not understand is less useful than the lab that runs four services reliably and grows over time.

Step 4: Backups and Monitoring

Backups are not optional, even for a home lab. The practical backup strategy is two layers:

• Container volumes — back up the Docker volumes that matter (Portainer data, Uptime Kuma data, Vaultwarden data, any persistent database). A nightly rsync or restic backup to an external drive or a NAS is the minimum.
• Configuration — back up the pfSense config, the Docker Compose files, the Traefik config, and any service-specific config. These are small files; back them up every time they change, and keep a copy off-device.

Monitoring is the other half. Uptime Kuma gives you service-level monitoring — is the service reachable, does it respond, does the cert expire soon? For system-level monitoring — CPU, memory, disk, temperature — Prometheus and Grafana are the standard choice, but they are heavier than a first lab needs. A simpler starting point is node_exporter plus a basic Grafana dashboard, or even just watching the container host's resource usage in Portainer until you have a reason to add more.

Day-to-Day Maintenance

The home lab that becomes a burden is the home lab that gets uninstalled. The maintenance tasks that keep it manageable are:

• Keep the container host and containers updated — but not all on the same night. Update one service at a time, watch for breakages, and keep a backup before each update that touches data.
• Check logs occasionally — Uptime Kuma alerts, container logs, pfSense logs. The lab that is running quietly is the lab that is running well; the lab that is running quietly because you ignored the logs is the lab that will surprise you.
• Review firewall rules periodically — services get added, VLANs get repurposed, and rules that made sense six months ago may not make sense now.
• Test backups occasionally — restoring from a backup you have never tested is how you discover that the backup was incomplete after the data is already gone.

What the Lab Is For

A home lab is useful for three things: learning, hosting, and experimenting. The learning is the primary value — you learn networking, Linux, containers, security, and how services actually behave when you are responsible for them. The hosting is the secondary value — running your own services means you control your own data, your own backups, and your own timeline. The experimenting is the fun part — trying a new service, breaking it, fixing it, and learning something in the process.

The home lab that tries to do all three at once often does none of them well. Start with one. Build from there. The mini-PC under your desk is not a data center. It is a place to learn, to host, and to experiment — quietly, efficiently, and one service at a time.

Related Articles