Proxmox

Status: in progress.

A fully redundant Zabbix monitoring stack, deployed entirely through code rather than manual configuration:

• Multi-node Zabbix server cluster — native Zabbix HA nodes for server-level failover
• Distributed Zabbix proxies — spread across network segments or regions for resilient, scalable data collection
• Clustered database backend — the catalog/history database itself deployed as a cluster, not a single point of failure
• Infrastructure as Code — the entire stack reproducible from a single set of Terraform/Ansible definitions

The goal is portability: the same IaC definitions should stand up the cluster identically whether the target is on-premise Proxmox VE, or a public cloud — AWS, Azure, or GCP. Same architecture, same automation, different provider underneath.

The problem

There’s something innate in some people — the drive to fix whatever is annoying. Annoying to some, but apparently default behavior for others.

Since I started my journey with Proxmox, I was amazed by its capabilities, and every release improved on that foundation. But there was trouble in this newfound paradise: one of the most repetitive tasks was creating a VM almost identical to the previous one. Same base OS, same baseline packages, same manual clicking through the same wizard.