The architecture
Six always-on cloud VMs, spread to reduce blast radius from any single provider incident, joined into one flat mesh VPN so every node can reach every other node regardless of what NAT or carrier-grade address translation sits in front of it. One node is deliberately kept as a relay/bastion — when a couple of hosts sit behind restrictive consumer-ISP NAT, having a node that both sides can always reach turns "unreachable" into "one hop further."
Configuration lives in Ansible, not in anyone's memory of what they typed into a shell six months ago. Every host in the fleet, plus the home lab nodes, gets the same baseline: security updates, monitoring agent, log shipping, firewall policy — applied the same way, every time.
Automated maintenance, actually automated
Every node checks for and applies updates on a fixed schedule, reboots automatically only when a reboot is actually required, and logs the entire run. That log is what turns "did this box get patched?" from a guess into a one-line lookup — which matters a lot when you're managing six-plus machines you don't touch by hand most weeks.
Incident: two nodes, gone without warning
Two fleet nodes were deprovisioned by the cloud vendor with no advance notice. One was hosting a production application with a live database.
Rebuilt the application's environment on a healthy fleet node from infrastructure-as-code rather than by hand, restoring what could be restored from the most recent backup. Not everything was recoverable — the gap between "we had backups" and "we had backups of literally everything" was the real lesson.
The practice that came out of it, and now applies to every production change on any host in the fleet: back up the current state before you touch anything, verify the backup landed somewhere outside the box you're about to change, and only then start editing. It's the same rule this very site's hardening pass followed.