Proxmox Deep Dive Part 13: Monitoring, Maintenance, and Homelab Best Practices

Part 12 covered permissions and automation. This closing part covers watching the stack once it’s running, keeping it maintained over time, and pulls every earlier part into a single homelab best-practices checklist.

Monitoring: Prometheus and Grafana on top of the same API from Part 12.

prometheus-pve-exporter translates the Proxmox API into Prometheus metrics, and one instance covers an entire cluster rather than needing one per node, since it’s just another API client scraping the same REST surface everything else in this series uses. node_exporter, run directly on each node, covers ordinary OS-level metrics, CPU, memory, disk, network, that the PVE-specific exporter doesn’t. Prometheus scrapes both, and Grafana visualizes the result, with community dashboards already covering node health, VM and container resource usage, storage (including ZFS-specific metrics), and hardware sensors, rather than needing a dashboard built from scratch. This is the same pattern as Terraform and Ansible from Part 12: monitoring isn’t a special built-in feature, it’s an ordinary consumer of the same API, and setting it up is proportionally the same kind of scoped-token exercise.

Ongoing maintenance: repositories and certificates.

Part 1 covered the three repository tiers at install time; the ongoing maintenance implication is making sure a homelab node stays pinned to No-Subscription (or a paid Enterprise subscription, if that’s the actual choice) rather than accidentally drifting onto Test, and checking in occasionally that updates are actually being applied rather than assuming a “set once” configuration stays correct indefinitely. Proxmox handles its own web GUI TLS certificate automatically by default (a self-signed certificate, replaceable with a proper one via Let’s Encrypt integration or a manually supplied certificate), worth doing for anything beyond a purely internal lab network, since a self-signed certificate trains the habit of clicking through browser warnings, which is exactly the habit that makes a genuine warning easy to miss later.

A homelab best-practices checklist, pulling this whole series together.

Hardware sizing: budget RAM for ZFS ARC (Part 3’s 2 GiB base plus roughly 1 GiB per TiB rule) as a separate line item from VM and container RAM, not a shared pool that quietly runs short; confirm CPU virtualization extensions (VT-x/AMD-V, and VT-d/AMD-Vi specifically if passthrough from Part 11 is a goal) before buying hardware rather than after; keep the boot drive separate from the storage pool, a small dedicated boot device rather than partitioning the same disks ZFS or Ceph are managing.

Security: restrict the web GUI and SSH to a management subnet at the node firewall level (Part 5), scope every API token to exactly what its automation needs rather than reusing a broad admin token (Part 12), and don’t expose the web GUI directly to the internet, a homelab management interface belongs behind a VPN or a reverse proxy with its own authentication layer, not port-forwarded directly.

Storage and resilience: default to ZFS mirrors for VM storage rather than RAIDZ, RAIDZ for bulk/streaming storage where capacity matters more than random IOPS (Part 3); don’t reach for Ceph or HA (Parts 8, 9) until the actual hardware and redundancy goals genuinely call for them, plenty of homelabs are better served by ZFS replication between two nodes than by a three-node Ceph cluster solving a problem they don’t have; add a QDevice (Part 7) the moment a cluster reaches exactly two nodes, since that’s the one node count where quorum behaves worse than either fewer or more nodes would.

Backup: PBS over plain vzdump-to-directory for anything that matters (Part 10), both prune and garbage collection scheduled, not just one of them, and an actual periodic restore test, not just a green checkmark on the backup job.

Where this leaves the pve host, and this series.

Every one of these practices is already visible in how the pve host behind this site’s own lab work is actually built: isolated vmbr-per-lab bridges rather than one flat network, ZFS as the storage backend, no HA or Ceph because the labs it runs (Sn1per, BloodHound, FortiManager) don’t need to survive a node failure automatically, and scoped access rather than one broad admin credential for everything that touches it. That’s the practical argument for this series existing at all: not that Proxmox has an enormous feature surface, which it does, but that the subset of it worth actually using in a homelab is smaller, more specific, and already proven out on infrastructure this site runs today.