My 2026 Homelab Architecture — Part 1: The Infrastructure

Why a Homelab?#

Ten years ago, I started with a Raspberry Pi just to run a Nextcloud and some Docker containers. It was a simple playground — a place to learn Linux and self-hosting without worrying about breaking anything important.

Since then, things have grown a lot. That single device has turned into 5+ Proxmox nodes with dedicated storage, NAS, a strong firewall, and more services than I can count. My setup now includes a UDM SE and a custom pfSense router, both managing several network segments. But the main idea is still the same: learn by doing, keep control of your data, and avoid depending on companies that might change their terms or go away.

There’s a big privacy aspect to it, too. I prefer hosting daily-use tools instead of paying a large subscription fee for a service when open-source alternatives are available, and I like knowing exactly where my data lives and who has access to it.

This post is Part 1 of a three-part series about my full homelab setup:

Part 1 (this post): The complete infrastructure — networking, compute, storage, remote management, and power.

Part 2: Services & Apps — every VM, LXC, and container running across the homelab.

Part 3: Operations & Plans — backup strategy, observability stack, deployment automation, and 2026 roadmap.

Whether you’re just starting your first lab or looking for ideas to upgrade your current one, I hope you find this useful. Let’s start with the network, because if the foundation isn’t solid, nothing else works.

Full Inventory at a Glance#

Network#

The network is split into three distinct segments, each with its own subnet and purpose:

The reasoning behind three segments:

• Isolation: homelab traffic stays separate from daily browsing.
• Security: pfSense enforces detailed firewall rules just for the lab segment.
• Performance: smaller broadcast domains keep NAS traffic from affecting WiFi.

Network Topology#

Airtel ISP
    │
    ▼
UDM SE (172.16.10.1)
    ├──── pfSense WAN (172.16.10.183)
    │         │
    │         ▼ LAN (10.0.5.1)
    │         ├── Netgear GS308P (PoE)
    │         │     ├── PiKVM KVM-A3  (→ Unraid)
    │         │     └── PiKVM X651    (→ pve1)
    │         ├── TP-Link SG108E
    │         │     ├── Proxmox nodes
    │         │     └── NAS devices
    │         ├── Netgear GS308T
    │         │     ├── Proxmox nodes
    │         │     └── NAS devices
    │         └── NixOS Dell Optiplex
    │
    └──── Netgear R7800 (10.0.1.1)
              └── Mobile phones & other WiFi devices

Now let’s walk through each layer, starting from the edge.

The Edge: UDM SE#

The UniFi Dream Machine SE is the first device that connects to the internet. Everything that enters or leaves my network goes through it. I chose the UDM SE because it offers the right balance: it is enterprise-grade inside, but still simple to set up without needing deep networking knowledge. The built-in UniFi controller means I do not need a separate management VM, and the hardware is reliable for continuous use.

Beyond basic routing, the UDM SE handles two additional responsibilities:

• WireGuard VPN — runs directly on the UDM SE for quick remote access (details in the VPN section below).
• NextDNS — all DNS queries are routed through NextDNS for network-wide ad blocking (details in the DNS section below).

Firewall & Router: pfSense#

The brain of the homelab network runs on a repurposed thin client:

While the UDM SE handles edge-level routing, pfSense is where the homelab’s network rules actually live. Here, it segments the lab from the client network, enforces service-level firewall policies, and runs several packages that would be too heavyweight for the UDM SE, creating a clearer division of network responsibilities.

Packages running on pfSense:

VPN Strategy#

Three tools cover remote access and service exposure, each with a distinct role:

WireGuard on UDM SE covers quick remote access. When an external connection is needed, WireGuard is enabled on a phone or laptop, providing direct access to both the homelab and the client segment. This approach is fast and avoids external dependencies.

Netbird is a self-hosted, open-source WireGuard-based mesh VPN. Unlike the hub-and-spoke model, each device running the Netbird agent is a peer. The management server runs on a Hetzner VPS. pfSense runs the Netbird client and exposes the 10.0.5.0/24 homelab subnet, so any peer can reach homelab devices as if they were local, even if the home network is unreachable.

Pangolin runs on the same Hetzner VPS as Netbird. It is a reverse proxy, so services inside the homelab can be exposed externally via Pangolin without opening firewall ports or a public IP address. It is a self-hosted alternative to Cloudflare Tunnel, giving full control over the relay server.

DNS#

DNS splits into two concerns: ad blocking at the network level and service name resolution for all homelab services.

Ad blocking — NextDNS on UDM SE

All DNS queries from every device on both segments flow through NextDNS, configured directly on the UDM SE. This gives network-wide filtering without managing a local resolver. Block lists, allow lists, and query logs are all managed in the NextDNS dashboard.

Service DNS: Cloudflare, Terraform, and GitHub Actions

All homelab services use the *.thinkncode.biz domain, which is managed with Cloudflare. Instead of manually modifying records, DNS is treated as code—every DNS record is defined in Terraform. A dedicated GitHub Actions pipeline manages Terraform with Cloudflare bucket storage, automatically adding or removing records as services are deployed or retired.

Switching Layer#

Below pfSense, three switches distribute connectivity to all homelab devices:

Compute: Proxmox Nodes#

Below are the compute nodes. Every Proxmox instance runs in standalone mode for better manageability, except for pve4 and pve5, which are clustered together since both are NUCs and use little power.

• Each PVE node uses OAuth authentication based on pocket passkeys.
• A Cloudflare-based ACME provider is used to automatically fetch and renew certificates.
• Ubuntu/Debian VM-like templates have been created for easy provisioning.
• LVM-thin based storage is used to manage VM disks.

In Part 2, I’ll do a deep dive into each PVE node, covering the VMs, LXCs, and services I run on my Proxmox setup.

Totals: 200GB+ RAM · 40+ CPU cores · GTX 1650 Super for GPU workloads

Node Roles#

Storage#

I use four NAS devices, each with a specific role in my storage setup:

Unraid — Primary NAS & Docker Host#

Unraid is the main NAS and Docker host in my homelab. It does more work than any other machine—serving files, running containers, and hosting the Proxmox Backup Server (PBS) VM.

File sharing: NFS and SMB shares are exported to all Proxmox nodes. These are mounted for VM disk storage and to share data across the cluster.

Proxmox Backup Server (PBS): PBS runs as a dedicated VM on Unraid. All Proxmox nodes back up their VMs and containers here. Hosting PBS on Unraid means backup storage benefits from Unraid’s parity protection.

Docker containers: Unraid also runs several containers through Community Apps, including Immich for photo management. I’ll cover the full list of running services in Part 2.

Primary backup data store: Unraid stores the first copy of most of my homelab data, with TrueNAS and Synology maintaining secondary, offsite backups.

Synology DS18+ — Offsite Backup#

The Synology DS18+ serves as one of my two secondary backup targets. Data from Unraid and the Proxmox cluster is replicated here as a second copy, separate from primary storage.

TrueNAS — Offsite Backup#

TrueNAS (running bare metal) is my other offsite backup target, primarily used for ZFS-native replication. With 16GB of RAM, it’s well-suited for ZFS ARC and runs efficiently even under replication load.

HL-TrueNAS — Bulk VM Storage (on pve3)#

HL-TrueNAS is a TrueNAS instance running as a VM on pve3 (Lenovo P510, Xeon E5-2680v4). The drives are passed directly to the VM, giving TrueNAS full control over the disks, while the host manages everything else.

The 10TB WD UltraStar is the largest single drive in the lab. This VM serves as the high-capacity bulk storage pool — the place for large datasets, archives, and anything that needs a lot of space but not necessarily high performance.

Management#

PiKVM — Out-of-Band Access#

I use two PiKVM units for out-of-band access to my most critical machines. This setup gives me BIOS-level control without needing to be physically present.

NixOS Workstation — Admin Station#

My Dell Optiplex runs NixOS and sits on the homelab LAN segment (10.0.5.0/24), wired directly to one of the switches for maximum reliability.

Power Protection: APC UPS#

I use two UPS units to protect different layers of my infrastructure. Each is chosen based on how critical the devices are and how much power they draw.

APC UPS PRO 1000VA — Network & Management Tier#

This UPS protects the devices that absolutely need to stay up during an outage. If the network goes down, nothing else matters.

APC UPS PRO 1500VA — Compute & Storage Tier#

This UPS protects the heavy hitters—the servers and storage that take longer to shut down gracefully.

What’s Next#

This is Part 1 of a three-part series on my 2026 homelab architecture:

• Part 1: The Infrastructure (you are here) — network, compute, storage, remote management, and power
• Part 2: Services & Apps — every VM, LXC, and container across all nodes
• Part 3: Operations & Plans — backup strategy, observability stack, deployment automation, and 2026 roadmap