Ansible

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.

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.