My Homelab
This site documents my homelab: what I run, how it’s wired, and how I keep it documented and auditable. I’m sharing it so others can see a concrete example and borrow ideas—not a generic tutorial, but a real setup you can learn from and adapt.
What’s here
- Architecture — Three physical hosts (a Windows desktop/hypervisor, an Ubuntu NAS, and a bare-metal proxy box in the network closet), a MikroTik router, and where every VM and service lives. Hyper-V on the Desktop Host, ZFS on the NAS Host, nginx + keepalived on the Proxy Host; Docker, Pi-hole, Plex, Minecraft, Stoat Chat, OpenWebUI, Paperless, and more in specific places for simplicity and redundancy.
- Network — Single flat LAN, DHCP with reservations on the router, three Pi-holes (synced via Nebula Sync) plus a Google DNS fallback for redundancy, and how traffic gets from the internet to the right service (port forward → VIP → nginx → backends).
- Services — The exact stack: nginx with keepalived VIP (two active nodes), Let’s Encrypt wildcard, Vaultwarden, Mealie, Paperless-ngx, ConvertX, IT-Tools, Donetick, Homepage, Plex, OpenWebUI, Uptime Kuma, Stoat Chat, Minecraft, and how they’re exposed (subdomains, LAN-only where it matters).
- Monitoring & Observability — Uptime Kuma for HTTP checks, plus a full Loki + Prometheus + Grafana stack with Alloy agents on every host for centralized logs and metrics. Automated audit scripts for config drift detection.
- Backup & Disaster Recovery — Multi-tier automated backups: weekly VM image exports, nightly application data, GPG encryption for sensitive data, and off-site replication to Backblaze B2 via Restic.
- Security — What I actually do: SSH keys only, fail2ban, router hardening, TLS 1.2/1.3, GPG-encrypted backups, Docker image pinning, resource limits on all containers, and restricting admin UIs to the LAN.
- Documentation and automation — Repo-as-blueprint: placeholders for secrets,
make generate-configs,make audit(including thorough config drift), and why that’s worth the effort. - Getting started — A practical order if you want to build something similar, with links to the tech I use.
I keep internal IPs out of this; the domain is substituted at build time. Everything else is as I run it. If you’re technically curious and comfortable following links for depth, you should be able to replicate or adapt the design.