Homelab IP Management: Knowing What’s Running Where
Every homelab starts manageable. One Raspberry Pi, one IP, easy to remember. Then there’s a NAS, a Docker host, Pi-hole, Home Assistant, a Proxmox node, some VMs, a few containers.
Six months in, your router’s client list shows “ubuntu-server-01” (which one?), “docker-host” (there are three), and several “Unknown Device” entries. When something breaks at midnight, you’re digging through SSH history to figure out where the service actually lives.
The fix isn’t enterprise tooling. It’s just having the right information in the right place.
What the router’s client list can’t tell you
The DHCP client list gives you MAC addresses, hostnames, and current IPs. That’s it. It doesn’t tell you:
- Which service is running on which host
- What depends on what (your monitoring stack probably points at specific IPs)
- Which IPs are in use by Docker containers vs. physical hosts
- Whether a device is supposed to be there or is just something that connected once
When your Plex server disappears, you don’t want to be cross-referencing MACs and guessing which of three “ubuntu” hostnames is the right one.
A structure that scales
Divide your address space by what lives there:
| Range | Purpose |
|---|---|
| .1–.20 | Network infrastructure (router, switch, AP, DNS) |
| .21–.50 | Management interfaces (iDRAC, IPMI, iLO) |
| .51–.100 | Physical servers and hypervisors |
| .101–.150 | VMs and major container hosts |
| .151–.200 | Services (reverse proxy, monitoring, media) |
| .201–.240 | Smart home and IoT |
| .241–.254 | DHCP pool |
When you know your Plex container should be in the .151–.200 range, you’ve already narrowed the search area significantly. When you’re adding a new service, you check that range, pick the next available IP, and assign it consistently.
Document services, not just devices
The difference between a useful inventory and a useless one is documenting services alongside devices.
For each service, it’s worth recording:
- Primary IP (and host IP if it’s a container or VM)
- What it does and who depends on it
- Where its config and data live
- Common troubleshooting notes
This doesn’t need to be elaborate. Even a simple note — “Plex at .165, config in /opt/plex, media on NAS at .54” — saves significant time when something breaks.
The hardcoded IP problem
The most common homelab pain point is services that break because an IP changed. This happens when:
- Docker Compose files have
192.168.1.xhardcoded instead of service names - Cron jobs SSH to specific IPs
- Monitoring systems point at addresses that drift
The solution isn’t to prevent IP changes — it’s to make IP assignment predictable. If your NAS is always at .54, nothing breaks when you restart it. If it could get any address from DHCP, everything that points to it eventually breaks.
Assign static IPs (or DHCP reservations) to anything that other things depend on. That’s your servers, storage, Pi-hole, Home Assistant, reverse proxy, and monitoring stack. Laptops and phones can be dynamic — they don’t have dependents.
Level 1 is enough for most homelabs
You don’t need Ansible, Terraform, or NetBox. A well-maintained device inventory — even a simple one — solves the “what’s at what IP” problem that breaks things at midnight.
- Device name and primary IP
- What it does
- What depends on it
- Where the config lives
Start there. Add detail as you need it.
Netory is built for exactly this kind of structured, searchable homelab inventory — without the complexity of enterprise IPAM tools.
Organise your homelab network in Netory — free for iOS and Android.