3-Node Proxmox Cluster

Why I built it

Everything in my lab runs on this cluster: the SIEM, the automation stack, my web services and home services. I wanted it to behave like production infrastructure: segmented, monitored, patched on a schedule and able to recover on its own, without me babysitting it.

What's running

The largest node runs an Intel i7-14700K (28 threads, about 64 GB RAM), which leaves headroom for the SIEM and for running a language model locally.

How it's secured

• Nothing is exposed directly. Services are published through Nginx Proxy Manager with TLS, and the admin dashboard sits behind Cloudflare Access (zero-trust SSO).
• Segmented network. A UniFi gateway (UDM Pro Max) with VLANs and firewall rules, across 4 switches and 2 access points.
• Key-only SSH. I'm moving every node to SSH keys with password login disabled, using a separate key per workstation so one lost laptop can be revoked on its own. I'm rolling it out one node at a time, so a mistake can never lock me out of the whole cluster.
• Secrets kept out of workflows. The automation reaches Proxmox with credentials kept in n8n's encrypted store, never in workflow files or chat.
• Logging. Filebeat on each node ships logs to the SIEM over HTTPS.

How it runs itself

• Self-healing watchdog (every 5 minutes): finds guests that are set to start at boot but are down, and restarts them. Machines I shut down on purpose are left alone.
• Approval-gated patching: a nightly job checks every node, VM and container for updates, snapshots guests first, and patches nothing until I approve it. No approval means the run is skipped and logged.
• Maintenance without outages: VMs and containers reboot weekly and nodes monthly, staggered so two nodes are never down at the same time.
• Health reports: node, guest and storage health go to my dashboard, with Discord as a fallback channel.

Problems I worked through

• Right-sizing a container for a local LLM. The container running the model was starved for memory, so requests timed out. I profiled it, raised its RAM, measured token throughput and used the numbers to decide what should run locally and what should go to a hosted model.
• Keeping the SIEM stable on shared hardware. Elasticsearch takes a big share of RAM by default, so I capped its heap to keep the VM and its neighbors healthy.
• Safe change control. Snapshots before patching, human approval and staggered reboots are the same discipline as ITIL change management, applied at home.

Skills demonstrated

Virtualization (KVM/LXC) · clustering · network segmentation · hardening (SSH, least privilege) · patch and change management · monitoring and log shipping · automation · capacity planning and troubleshooting

What's next

• Finish the SSH key-only rollout on the remaining nodes.
• Add backup-restore drills to prove snapshots actually restore.
• Ship more guest logs (not just node logs) into the SIEM.