Projects

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.

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 resilient remote-access gateway built so that no single component — web tier, application tier, or database — is a single point of failure:

• Multiple Guacamole nodes behind an Nginx load balancer, so a node failure doesn’t take down access
• MariaDB Galera cluster as the authentication/connection database backend — synchronous multi-master replication, no single DB instance to lose
• Session recording for connection auditing and compliance
• Infrastructure as Code — the whole stack defined and reproducible, not hand-built

The interesting part of this project isn’t installing Guacamole — that’s well documented. It’s getting the Galera cluster quorum right (odd node count, proper arbitrator handling) and making sure failover at every layer — Nginx, Guacamole, and the database — actually works under a node failure, not just in theory.

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.