Getting Started: If You Want to Build Something Similar
A practical order and the tech I use, with links. Assumes you’re comfortable with SSH, basic networking, and looking up docs.
Order I’d do it
- Router and one subnet — Get a router you can control (MikroTik, pfSense, or even your current one). One LAN, DHCP on the router, static reservations for any server you care about. MikroTik docs.
- One DNS server — Run Pi-hole (or similar) so the LAN uses it. Put it on a VM or an always-on box. Add its IP as the DNS server in DHCP. Pi-hole.
- One host and a reverse proxy — Pick one machine, install nginx (or Caddy). Point a domain at your home IP (DDNS if needed). Get a cert (e.g. Let’s Encrypt, DNS challenge if you can). Forward 80/443 from the router to that host. One
serverblock per service. nginx · Let’s Encrypt. - One backend service — Put something behind the proxy (e.g. Plex or a small web app). Confirm you can hit it via
https://something.yourdomain. You now have the full path: internet → router → proxy → backend. - Monitoring — Add Uptime Kuma (single container) for HTTP health checks. Later, add Loki + Prometheus + Grafana for logs and metrics. Start simple; grow as you need visibility. Uptime Kuma · Grafana.
- Backups — Automate from day one. Even a cron job that tars your service data to another disk is better than nothing. Encrypt sensitive data (GPG). Add off-site when you have irreplaceable data. Restic.
- Second proxy node and VIP (optional) — Add a second machine with nginx (same config). Put keepalived on both; give them a shared VIP. Point the router’s port forward at the VIP. Now one node can die and the other still serves. keepalived.
- More services and more DNS — Add more backends (Docker, Plex, etc.). Add more Pi-holes on other hosts and list them all in DHCP for redundancy. Use Nebula Sync to keep them in sync. Document everything in a repo with placeholders and a values file.
You can stop at step 4 and still have a useful, exposed homelab. Steps 5–8 are for reliability, visibility, and scale.
Tech I use (and where to read more)
| Layer | What I use | Link |
|---|---|---|
| Router | MikroTik hEX | help.mikrotik.com |
| Wi‑Fi | MikroTik hAP ac² ×4, CAPsMAN (per-AP channels) | MikroTik help |
| Hypervisor | Hyper-V (Windows) | Microsoft Hyper-V |
| Storage/NAS | Ubuntu LTS + ZFS | Ubuntu Server · OpenZFS |
| Reverse proxy | nginx | nginx.org/docs |
| HA (VIP) | keepalived | keepalived.org |
| TLS | Let’s Encrypt, certbot, DNS challenge | letsencrypt.org |
| DNS | Pi-hole ×3, synced via Nebula Sync | docs.pi-hole.net · Nebula Sync |
| Containers | Docker, Docker Compose | Docker |
| Password manager | Vaultwarden (Bitwarden-compatible) | Vaultwarden wiki |
| Document management | Paperless-ngx | docs.paperless-ngx.com |
| Media | Plex | Plex support |
| Dashboard | Homepage | gethomepage/homepage |
| Monitoring | Uptime Kuma, Loki, Prometheus, Grafana, Alloy | Uptime Kuma · Grafana |
| Backups | Cron scripts, GPG, Restic → B2 | Restic · Backblaze B2 |
Repo and validation
If you adopt “repo as blueprint”:
- Put all configs and docs in a repo. Use placeholders (
<KEY>) for anything secret or environment-specific. - Keep one local file (e.g.
values.yaml.local) with the real values; gitignore it. - Run a script before every commit that fails if any of those values appear in tracked files. That way you never commit an IP or key.
- Optionally, generate “filled” configs from the repo and diff them against what’s on the servers. That’s your drift check.
You don’t need a full IaC stack to get most of the benefit; placeholders + generate + audit is enough to stay honest.