Proxmox

After posting my earlier project, where I pulled a small, open-source infrastructure out of a hat for a small business that had nothing and now has real infrastructure, some people reached out and started asking questions. One of those turned into a hands-down agreement on a job.

A tight budget and no Windows Domain

One of the people who reached out was a business owner I know personally. They run a small local company with about 10 Windows PCs, a few printers, one NAS, and a lot of sensitive data handled daily. Budget is tight, and the owner has no interest in cloud-based identity services like Azure AD or M365.

Overview

I’m a firm believer in experience gained by breaking things, working through failures, and solving problems under real constraints, with real ownership of the decisions.

The homelab idea was introduced to me by r/homelab and a few other forums, including Tom Lawrence’s, a very technical community.

For context: my current setup is a rework of a previous build. Below I’ll detail the actual hardware choices, the struggles along the way, and the real-world constraints behind them.

A small retailer asked me for help. They had nothing. No backups. No monitoring. No remote access. Budget: roughly zero, or a discount on groceries. They promised.

I said yes. Mostly because I like a good challenge. Partly because the groceries were decent.

What followed was one of the most honest projects I have worked on in years. No safety net. No team to escalate to. No budget for the right tool. Just me, a 12-year-old HP desktop gathering dust, and the question: what can actually be built with what is here?

Overview

Two separate small-business engagements, both with essentially zero budget and no existing infrastructure. The first, paid partly in groceries, came first and proved the approach. It spurred the second: a mixed Windows/Linux environment for a second business, built on the same philosophy but with a wider scope.

The problem

Neither business had any of the basics most infrastructure takes for granted: backups that actually restore, visibility into what’s running, secure remote access, or any monitoring at all. Budget in both cases ruled out new hardware or commercial licensing.

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.