Homelab

Current Architecture

The homelab is split into a few rough layers. The physical layer is the rack, router, switch, NAS, Proxmox nodes, Raspberry Pis, and UPS/power work. The platform layer is Proxmox, TrueNAS, VLANs, WireGuard, DNS, and internal TLS. The services layer is where the fun and pain live: Gitea, Jenkins, Caddy, Jellyfin, Shoko, monitoring, Ollama, Open WebUI, K3s experiments, and everything else I decide to deploy because it looked useful at 2am. Also AI is a keyword that keeps popping up, here is some infra allocated to tick the AI box.

Remote Access with WireGuard + AdGuard

For remote access, I use a small VPS as a public WireGuard edge gateway. This solves a few annoying residential network problems at once: double NAT, possible CGNAT, and ISP IP rotation.

Instead of exposing the homelab directly (remember not a reliable IP because of ISP behaviour), the router maintains an outbound WireGuard connection to the VPS. Remote peers also terminate on the VPS, and traffic is then forwarded into the homelab based on the WireGuard interface design and firewall rules. I split access by interface as well, so admin and guest peers do not get the same reach into the internal VLANs.

        [Remote Peer]
        ↓ WireGuard 
        [VPS]
        ↓ Forwarding Rules to Seperate Tunnel
        [MikroTik Router]
        ↓ VLAN Routing + Firewall Policy
        [Internal VLANs / Services]
        ↓ Internet Traffic
        [AdGuard Home (DNS)]
        ↓
        [Unbound (DoT upstreams)]
    

The intermediary VPS layer helps to solve a couple of problems. One of which is the frequent switching (rotation) of residential IPs by the ISP, solving the issue of double NAT (I did not want to replace the ISP router with my own -- My family still uses the regular ISP network), potential CGNAT issues, and a static IP my domain can point to. It's a cheap 5 dollar/month nanode that purely handels this network filtering and forwarding job. The peer list is still quite small and managable, but I might look at automating it via git changes, though some form of secrets generation and replacement (maybe hashicorp valut) might be needed.

The VPS also terminates separate WireGuard interfaces for different roles. There is an admin interface for full internal access, a guest interface with restricted VLAN reach, and a backhaul interface linking the VPS to the homelab router. From there, traffic is routed and filtered into the internal network using WireGuard peer design, MikroTik routing, and firewall rules. No internal VLANs are exposed directly to the public internet.

In practice, this means the VPS acts as a public entry point, policy boundary, and transit hop rather than a machine that actually hosts the services themselves. It is mostly there to provide a static IP, terminate the tunnels, and forward permitted traffic onward to the homelab.

All DNS requests over VPN are handled by AdGuard Home, which tries to block ads, trackers, telemetry, and malware. It forwards queries to Unbound, which uses DNS-over-TLS (DoT) to upstream providers. This on paper gives me a secure and ad-free browsing experience, even on public Wi-Fi.

With this setup, I can access self-hosted services like Proxmox, TrueNAS, Gitea, and Docker UIs from anywhere, without exposing them to the public internet.

On my phone, the WireGuard tunnel is permanently active — traffic is always routed through my homelab. On my Windows laptop, I toggle the connection using the WireGuard GUI client. On Linux, I manage it using wg-quick for a minimal CLI-based approach.

Automation State

The current automation direction is to make the lab reproducible enough that rebuilding a VM or service is not a dramatic event. Terraform defines the Proxmox VM shape, cloud-init seeds the base config, Ansible applies the service configuration, and Jenkins/Gitea are being wired up so changes can eventually flow from git into the lab with less manual clicking.

• Terraform: VM definitions, VLAN placement, cloud-init, storage, sizing, and Proxmox provider work.
• Ansible: bootstrap, packages, users, SSH, chrony, Caddy, DNS, Gitea, Jenkins, monitoring, K3s, and media roles.
• Jenkins: intended CI runner for linting, validating, and eventually running controlled plans/playbooks.
• Gitea: internal git mirror / source of truth for lab repos.
• SOPS: secrets handling, I also want to figure out how Hashi vault works.

This is nowhere close to an enterprise level automation. It is done enough to be useful, broken enough to teach me things, and structured enough that I can keep improving it without starting from scratch each time.

Homelab Potential Upgrades

While the current homelab setup is stable and operational, I have a long-term roadmap focused on scalability, service uptime, physical infrastructure, and secure external access. This roadmap is driven by experimentation, curiosity, and a desire to reduce failure domains while staying in control of every service.

Physical Infrastructure

• Considering a migration from the current 10U MikroTik SR-10U to a 20-40u 1000mm depth rack for improved airflow and cable management. Looking at some 800x1000mm 36u rack to fit forseable hardware needs.
• Add a rack-mounted UPS to prevent data loss and allow for graceful shutdowns across critical services during power outages. Possibly using NUT to control the UPS behaviour
• Building a central permament 2-4u virtualisation server using either a Rome or Milan chip to take advantage of the enterprise/datacenter hardware decomissioning cycle (hope DDR4 rdimm becomes cheaper in bulk).
• Additional 1-4u servers based on needs, like NAS expansion, dedicated public facing services server, more proxmox nodes for HA (consensus voting)
• Standardize rack layout with proper labeling, patch panels, and side/rear cable routing.
• When the enterprise upgrade/decomission cycle for LTO-8 is due, I plan to add an additional layer of tape archives on top of my NAS, to keep them in a different format and for long term storage.

Network Upgrades

• Complete migration to the MikroTik RB5009UG+S+IN as the core router with VLAN-aware firewall rules and faster routing capacity.
• Consider an upgraded Router after the RB5009 like the CCR2004 or entierprise switches

• Look into replacing the generic 2.5Gbps switch with MikroTik CRS-series switches for better VLAN tagging, consistency, and monitoring.
• Subscribe to a 10Gbps fiber plan to fully utilize RB5009’s capabilities and reduce upstream bottlenecks.

External Access & Security

• Deploy a VPS-based reverse proxy (e.g., Hetzner) to tunnel traffic into the homelab via WireGuard.
• Look into dedicated firewall devices, both enterprise (e.g. Cisco, Fortinet) and open-source (e.g. OPNsense, pfSense) (or even the forbidden virtualised firewall route)
• Self-host selected services (e.g.Gitea, Jellyfin, dashboards, email) via subdomains routed through the VPS.
• Ensure all outbound traffic from sensitive services like qBittorrent pass through a VPN killswitch using NordVPN to avoid IP leaks.
• Begin exploring Zero Trust architecture for access control, identity-based access, and device trust posture enforcement.
• Maybe consider looking into hardware authentication for access control as well

Service Architecture

• Increase use of Proxmox for service separation via LXC containers and VMs.
• Move toward either Docker Swarm or consider Kubernetes (K3s) to maintain consistent uptime, make service recovery easier, and support future scaling.
• Break out critical services (AdGuard, Unbound, monitoring tools) onto a dedicated Raspberry Pi 5 for higher availability and role separation.
• It is looking more like K3s since the recommended running for AWX involves AWX Operator, and having ran it via Rancher, it looks promising

Philosophy: One Purpose per Device vs General Purpose

• Borrowing from the UNIX philosophy of "Write programs that do one thing and do it well."
• Experimenting with a philosophy of one device per critical role (DNS, VPN, monitoring) for fault isolation and simplicity.
• In parallel, maintain general-purpose nodes (e.g., Proxmox or Docker hosts) for scalable, fast-to-deploy services.
• This approach should balance resource efficiency with clean service boundaries.