Keeping services available can be a difficult task. Here’s how I approach it in my homelab.
Instead of chasing perfect uptime, I focus on detecting failures quickly and recovering fast.
Why I'm Not Using High Availability
On a single server, true HA isn’t possible since the server itself is the failure domain.
If I were designing this for a small business, I would, for example, run Authentik on two nodes behind a load balancer with a shared PostgreSQL backend. The trade-off is complexity: you now have to manage consensus, deal with split-brain scenarios, and maintain proper backup strategies for clustered state.
For a single-user homelab, that overhead isn’t worth it. If I were running multiple servers, I would consider implementing HA.
My current setup focuses on:
- avoiding lockouts
- detecting issues early
- being able to recover quickly
I use centralized logging to catch issues before they break my system, and I maintain off-site backups for easy recovery.
To prevent lockouts, I keep fallback accounts for critical services such as Proxmox VE. For some services, I intentionally avoid SSO. For example, on iDRAC.
Out-of-Band Management (Last Resort)
An important component of my setup is iDRAC 9 Enterprise. It acts as a last-resort access method if everything else fails.
It provides full remote control of the server, including the ability to boot into a live operating system. This helped me recover from a situation where the root partition was corrupted and needed to be unmounted for repair.
Backups
I currently use Proxmox Backup Server which is installed in an offsite location to back up my system.
Proxmox Backup Server integrates perfectly into my Proxmox VE setup.
I chose it because it offers features such as incremental backups, deduplication, snapshot-based backups and client-side encryption.
Its incremental backup design, extremely efficient storage usage, and tight Proxmox VE integration make it the best option for me.
How to deal with attacks
When implementing a security strategy, you should always know what you are defending against. In my case, that is mostly non-targeted automated attacks. My homelab is also used to learn and experiment with security concepts.
With that being said, do not take this as a security baseline for your own setup.
Always evaluate your situation individually.
Another important factor is the attack surface. Most of it is created by public-facing applications. That’s why I primarily expose my services only within my LAN or via Tailscale. Services that must be publicly accessible, such as Authentik, are exposed through a Cloudflare Tunnel and hardened.
For example, Authentik is publicly accessible in my setup, but a high number of failed login attempts will lock the account, and 2FA is enabled. I also use Cloudflare to automatically block known bots and present CAPTCHAs based on defined rules.
Even within your local network, you should consider security when designing your setup. Internal networks are not automatically safe. For example, you can use VLANs to separate devices or implement a firewall (software or hardware).
One of the most effective security measures, however, is simply keeping your services up to date. 👀
Another important principle is least privilege and privilege separation. Services and users should only have the permissions they actually need nothing more. This limits the impact if something gets compromised.
Zero Trust
I follow Zero Trust principles in my homelab using multiple layers of access control.
First, I use Tailscale with ACLs so that not every user or device can access every resource. Access is restricted based on identity and policy.
Second, I use SSO for my web applications to centralize authentication and make access easier to manage.
Third, I use mTLS as an additional layer at the WAF level. Before users even reach the actual SSO login process, they must present a valid client certificate. Only after passing mTLS are they allowed to continue to authentication and authorization.
For my Apple devices, the client certificates are deployed through MDM. For other devices, I manually import the certificate.
Ideally, each device should have its own client certificate, so a single lost or compromised device can be revoked without affecting every other client.
Monitoring & Logging
To detect issues early and reduce downtime, I use the LGTM stack (Loki, Grafana, Tempo, Mimir) alongside uptime monitoring.
For basic availability checks, I rely on Uptime Kuma, which gives me a clean dashboard of all services and alerts me if something goes down. However, uptime monitoring is reactive. It only tells you after a failure occurs.
To go deeper, I use the LGTM stack:
- Grafana Loki for centralized logging across all services
- Grafana Tempo for distributed tracing to follow requests through systems
- Grafana Mimir for scalable metrics collection and alerting
This combination lets me correlate logs, metrics, and traces in one place, making it much easier to debug issues and detect anomalies early.
All critical alerts and notifications are sent directly to my phone via Telegram, so I can respond quickly.
Conclusion
Running a reliable and secure homelab is less about complex setups and more about making the right trade-offs.
In my case, I prioritize simplicity over high availability, reduce my attack surface as much as possible, and focus on fast recovery instead of preventing every possible failure. Tools like Proxmox Backup Server, Grafana Loki, and Uptime Kuma help me detect issues quickly and recover when something goes wrong.
At the same time, security is built in layers: limiting exposure using Tailscale, protecting public services behind Cloudflare Tunnel, and enforcing principles like least privilege.
There is no perfect setup. Only one that fits your needs and threat model.
What works for a single-user homelab may not be enough for a production environment, and that’s fine.
In the end, keeping things updated, having reliable backups, and being able to recover quickly will matter more than chasing a “perfect” architecture.