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 a 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 or one block with multipleserver_names. 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. - 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. 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 and 6 are for redundancy 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 | Same + CAPsMAN docs |
| Hypervisor | Hyper-V (Windows) | Microsoft Hyper-V |
| Storage/NAS | TrueNAS Scale | truenas.com/docs |
| Reverse proxy | nginx | nginx.org/docs |
| HA (VIP) | keepalived | keepalived.org |
| TLS | Let’s Encrypt, certbot, DNS challenge | letsencrypt.org |
| DNS | Pi-hole ×3 | docs.pi-hole.net |
| Containers | Docker, Docker Compose | Docker |
| Password manager | Bitwarden (self-hosted) | Bitwarden help |
| Media | Plex | Plex support |
| Dashboard | Homepage | gethomepage/homepage |
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.