Skip to content

Homelab Infrastructure

System architecture

How the virtualisation, storage, container, DNS, routing, monitoring and GPU layers of my homelab fit together.

This represents the environment I actually operate rather than an idealised reference architecture. Internal hostnames, addresses and credentials are deliberately left out.

Overview

Current environment

One Proxmox host, one storage VM that doubles as the Docker host, and the services that run on it.

Homelab architectureA Proxmox host with ZFS storage runs an OpenMediaVault virtual machine that provides mdadm RAID1 storage, SMB shares and Docker services: Nginx Proxy Manager routing to published applications, Pi-hole and Unbound for DNS, Node Exporter, cAdvisor and a Pi-hole exporter feeding Prometheus and Grafana, and Ollama using an NVIDIA RTX A2000 passed through from the host. Internet users reach published services via Cloudflare and Cloudflare Tunnel into Nginx Proxy Manager. LAN clients resolve DNS through Pi-hole and Unbound to the root, TLD and authoritative servers. Tailscale provides remote administrative access.Proxmox VE hostZFS host storage · bridged networking · consistent IP assignmentsOpenMediaVault VMmdadm RAID1 · SMB file services · Docker hostIngress & routingNginx Proxy ManagerTLS · HTTPS routingPublished servicesthis website · blog · internal appsDNSPi-holefiltering · local recordsUnboundrecursive · DNSSECObservabilityExportersNode Exporter · cAdvisor · Pi-holePrometheusGrafanaGPU workloadOllamaGPU-accelerated modelsNVIDIA RTX A2000PCI passthrough to the OMV VMOther Linux & Windows VMslab and admin workloadspassthroughInternet usersCloudflareDNS · TunnelCloudflare TunnelLAN clientsDNS queriesRoot · TLD ·authoritative DNSrecursionTailscaleremote admin access
Current homelab architecture. Internal hostnames, addresses and credentials are omitted deliberately. No network segmentation is shown because none is implemented: the environment uses bridged networking with consistent IP assignments.

Platform

Infrastructure stack

  1. 01

    Physical host

    Dedicated homelab hardware providing compute, storage connectivity and an NVIDIA RTX A2000 that is passed through to a virtual machine rather than used by the host.

  2. 02

    Proxmox virtualisation

    Proxmox VE provides the VM layer, with ZFS as the host storage backend. Bridged networking with consistent IP assignments keeps core systems reachable at known addresses. Linux and Windows VMs run alongside the storage VM for lab and administrative workloads.

  3. 03

    OpenMediaVault VM

    OpenMediaVault runs as a virtual machine and provides the mdadm RAID1 storage and SMB file services. It is also the main Docker host, and it receives the RTX A2000 via PCI passthrough.

  4. 04

    Docker services

    Docker Compose runs the infrastructure and application services with persistent storage and repeatable configuration: DNS, reverse proxy, monitoring, Ollama and the published web applications.

physical → virtualisation → operating system → containers

Paths

Request, DNS and hardware paths

Internal DNS resolution, externally published services and the GPU follow different paths through the environment.

Internal

LAN DNS resolution

  1. LAN client

  2. Pi-hole

  3. Unbound

  4. Root / TLD / authoritative servers

Pi-hole handles client-facing DNS while Unbound performs recursive resolution with DNSSEC validation rather than relying on a public upstream resolver.

External

Published web services

  1. Internet user

  2. Cloudflare

  3. Cloudflare Tunnel

  4. Nginx Proxy Manager

  5. Target Docker service

Cloudflare handles the public edge, the tunnel provides the path into the environment and Nginx Proxy Manager routes the request to the right internal service.

Hardware

GPU passthrough

  1. RTX A2000 on the Proxmox host

  2. PCI passthrough

  3. OpenMediaVault VM

  4. Docker NVIDIA runtime

  5. Ollama container

The driver inside the VM is a DKMS module, so it has to build against every new kernel. A failed build after a routine upgrade is the subject of the GPU passthrough recovery case study.

Core services

Infrastructure services

DNS

Pi-hole · Unbound

Pi-hole provides internal DNS, filtering and query visibility. Unbound performs full recursive resolution with DNSSEC validation rather than forwarding to a public resolver.

HTTPS & routing

Nginx Proxy Manager · Cloudflare

Nginx Proxy Manager handles TLS certificates and HTTPS routing to the Docker services. Cloudflare DNS and Cloudflare Tunnel provide the external path in, so no container is exposed directly.

Monitoring

Prometheus · Grafana

Prometheus collects metrics from Node Exporter, cAdvisor and a Pi-hole exporter. Grafana dashboards cover host resources, containers, disk usage and RAID status.

Storage

OpenMediaVault · mdadm · SMART · SMB

A two-disk mdadm RAID1 mirror for critical data with a separate disk for non-critical media, shared over SMB and monitored with SMART.

GPU workloads

NVIDIA RTX A2000 · Ollama

The RTX A2000 is passed through from the Proxmox host to the OpenMediaVault VM, where the Docker NVIDIA runtime makes it available to Ollama for GPU-accelerated models.

Remote access

Tailscale

Tailscale provides remote administrative access to the Linux environment, with the Windows 11 client configured as well. It is separate from the published-service path through Cloudflare.

Observability

Metrics path

Monitoring is kept separate from the applications being observed.

EXPORTERS

Node Exporter

cAdvisor

Pi-hole Exporter

COLLECTION

Prometheus

VISUALISATION

Grafana

exporters → Prometheus → Grafana

Dashboards provide visibility into host resources, Docker containers, disk usage, RAID status and DNS-related metrics.

Example workload

This website

waqasmohammad.com is a Next.js application built into a Docker image and run as a container within the same environment. It is published through the Cloudflare Tunnel and Nginx Proxy Manager layers described above rather than exposing the container directly to the internet, and analytics run on self-hosted Umami.

  • Next.js
  • Docker
  • Nginx Proxy Manager
  • Cloudflare Tunnel
  • Umami

Reality check

What this environment is, and is not

It is a working homelab. The systems shown here run real services and are where I practise infrastructure administration and troubleshooting.

It is not a highly available platform. Core services depend on a single Proxmox host and a single storage VM, so host-level failure remains a single point of failure.

Backups are real but not automated. Backup and migration work has been carried out and validated by hand. I do not present it as a mature automated backup strategy with scheduled jobs and routine restore testing.

There is no network segmentation. The environment uses bridged networking with consistent IP assignments. No VLAN design is shown because none is implemented.

Kubernetes is not part of this architecture. My k3s work remains an incomplete learning experiment and is documented separately on the Projects page.

Terraform use is limited. I have used it to manage seven Cloudflare DNS records with AI-assisted guidance, not to define this environment as code.

Implementation

See the individual projects and case studies.

The Projects page breaks these layers down into the systems, tools and practical work used to build them, including what broke and how it was recovered.

View ProjectsView CV