Production-Style Homelab Architecture: Proxmox, Docker, DNS and Monitoring

This post documents my current homelab architecture, built to reflect production-style infrastructure rather than a typical home setup.

The focus is on how the system is structured, how components interact, and what I learned operating it over time.

The stack includes Proxmox for virtualisation, OpenMediaVault for storage, Docker for workloads, Pi-hole with Unbound for DNS, Nginx Proxy Manager for ingress, and a monitoring stack using Prometheus and Grafana.

Architecture Overview

At a high level, the environment is structured as follows:

• Proxmox VE as the hypervisor
• OpenMediaVault VM for storage management
• Docker for application workloads
• Pi-hole + Unbound for DNS resolution
• Nginx Proxy Manager as the reverse proxy layer
• Prometheus and Grafana for monitoring

The goal is to keep responsibilities clearly separated while maintaining operational simplicity.

Infrastructure Layer

Proxmox

Proxmox is used as the primary hypervisor, providing VM isolation and resource control.

The host runs on ZFS-backed storage, with workloads separated into virtual machines rather than overloading a single system.

Storage (OpenMediaVault)

OpenMediaVault runs as a VM with direct disk access.

• mdadm RAID1 for redundancy (2x 3TB disks)
• Separate 8TB disk for bulk data
• ext4 filesystem for simplicity and stability

This keeps storage concerns isolated while remaining easy to manage and recover.

Container Workloads

All application services are containerised using Docker and managed with Compose.

Services include:

• Pi-hole (DNS filtering)
• Unbound (recursive DNS)
• Nginx Proxy Manager (reverse proxy)
• Prometheus (metrics collection)
• Grafana (visualisation)
• cAdvisor (container metrics)

Each service runs independently with persistent volumes and explicit configuration, making the system reproducible and easier to troubleshoot.

DNS and Network Design

DNS is handled internally using Pi-hole and Unbound.

Pi-hole provides filtering and local DNS overrides, while Unbound performs recursive resolution without relying on upstream providers.

Static IPs are assigned to key services to avoid dependency on DHCP and improve reliability during troubleshooting.

Reverse Proxy

Nginx Proxy Manager is used as the ingress layer.

It handles:

• Routing external traffic to internal services
• Managing SSL certificates
• Providing clean domain-based access

For example, blog.waqasmohammad.com routes to the Ghost instance running internally.

This mirrors common cloud patterns where a central ingress layer manages service exposure.

Monitoring and Observability

The monitoring stack consists of:

• Prometheus
• Node Exporter
• cAdvisor
• Grafana

This provides visibility into:

• CPU and memory usage
• Disk utilisation
• Container-level metrics

A key focus was building dashboards that are actually useful for diagnosing issues rather than just displaying metrics.

Key Learnings

Operating this environment reinforced a few core principles:

• Systems should be designed for recovery, not just uptime
• DNS control is critical for debugging and reliability
• Observability should be built in from the start
• Simplicity is often more valuable than over-engineering

The goal is not to replicate enterprise scale, but to replicate enterprise thinking.