January 10, 2026

Homelab IP Management: Beyond the Router's Client List

Scale your homelab network with proper IP address planning, device documentation, and conflict prevention. Stop guessing which service is at which IP.

7 min read

homelabnetwork-management

Homelab IP Management: Beyond the Router’s Client List

Your homelab started simple—maybe a Raspberry Pi running Pi-hole and Plex. Fast-forward six months, and you’re running Docker containers across three servers, your router’s client list looks like hieroglyphics, and you can’t remember which VM hosts your monitoring stack.

“What was that IP again?” becomes the most common question in your homelab journey.

Professional network administrators use IP Address Management (IPAM) tools, but enterprise solutions are overkill for homelabs. You need something between “wing it with mental notes” and “deploy NetBox with a database cluster.”

Here’s how to scale your homelab network documentation without losing your sanity.

The Homelab IP Documentation Problem

What Starts Simple Becomes Complex Fast

Week 1: One Pi, one IP address, easy to remember Month 3: NAS, Home Assistant, Pi-hole, Plex server Month 6: Docker swarm, VMs, reverse proxy, monitoring stack Year 1: Multiple VLANs, dedicated firewall, 20+ services across 5 physical hosts

Router Client Lists Don’t Scale

Your router shows:

“ubuntu-server-01” (which Ubuntu server?)
“VM-192-168-1-100” (what’s running there?)
“docker-host” (which of the three Docker hosts?)
“Unknown Device” (mystery strikes again)

The Hidden Cost of Poor Documentation

Time Lost to “IP Archaeology”:

15 minutes finding which server runs your backup service
30 minutes debugging why a container can’t reach a database
2 hours after a power outage rebuilding port forwards and firewall rules
4 hours migrating services because you forgot what dependencies exist

Reliability Issues:

Hard-coded IPs in Docker compose files
Services that break when IP assignments change
Backup scripts that fail silently when targets move
Monitoring systems that can’t track renamed or relocated services

Homelab Network Architecture That Scales

Hierarchical IP Planning

Instead of random IP assignments, use ranges that make sense for infrastructure:

Infrastructure Core: 192.168.1.1-50

192.168.1.1: Router/Gateway
192.168.1.2-10: Switches, access points, firewall
192.168.1.11-20: Network services (DNS, DHCP)
192.168.1.21-30: Management interfaces (iDRAC, IPMI, iLO)

Physical Servers: 192.168.1.51-100

192.168.1.51: Main hypervisor (Proxmox/ESXi host)
192.168.1.52: Docker host #1
192.168.1.53: Docker host #2
192.168.1.54: NAS/storage server
192.168.1.55: Dedicated database server

Virtual Machines: 192.168.1.101-150

192.168.1.101-110: Production VMs
192.168.1.111-120: Development/testing VMs
192.168.1.121-130: Specialized services (game servers, build agents)

Container Services: 192.168.1.151-200

192.168.1.151-160: Web services (reverse proxy, web apps)
192.168.1.161-170: Database containers
192.168.1.171-180: Monitoring and logging
192.168.1.181-190: Media services

IoT and Smart Home: 192.168.1.201-250

192.168.1.201: Home Assistant
192.168.1.202-220: IP cameras and security
192.168.1.221-240: Smart home hubs and bridges

VLAN Strategy for Homelabs

As your homelab grows, VLANs provide both security and organization:

Management VLAN (10.0.10.x)

Server management interfaces
Network equipment administration
Backup and monitoring traffic

Services VLAN (10.0.20.x)

Production applications
Databases and storage
Internal web services

IoT VLAN (10.0.30.x)

Smart home devices
IP cameras
IoT sensors (isolated from main network)

Guest/Lab VLAN (10.0.40.x)

Testing and development
Temporary services
Potentially unsafe experiments

Service-Centric Documentation

Traditional network documentation focuses on devices. Homelab documentation should focus on services and their relationships.

Service Mapping Template

For each service, document:

Service Identity

Name: “Plex Media Server”
Purpose: “Stream movies and TV shows to devices”
Criticality: High (family uses daily)

Network Information

Primary IP: 192.168.1.165 (container)
Host IP: 192.168.1.52 (docker-host-01)
External ports: 32400 (web UI), 8324 (Roku)
Internal ports: 32400

Dependencies

Storage: NAS at 192.168.1.54 (SMB shares)
Database: PostgreSQL container at 192.168.1.162
Authentication: Optional (local users vs. LDAP)

Deployment Details

Platform: Docker container
Config location: /opt/plex/docker-compose.yml
Data location: /mnt/nas/media, /opt/plex/config
Backup requirements: Config weekly, media not backed up

Troubleshooting Notes

Logs: docker logs plex-server
Common issues: “Transcoding fails = check /tmp disk space”
Performance: “High CPU during transcoding is normal”

Infrastructure Relationship Mapping

Document how services connect:

Reverse Proxy Setup

Traefik at 192.168.1.151 routes to:
- plex.homelab.local → 192.168.1.165:32400
- nas.homelab.local → 192.168.1.54:5000
- monitor.homelab.local → 192.168.1.171:3000

Storage Dependencies

All Docker containers use NAS (192.168.1.54) for persistent data
VM storage on Proxmox host (192.168.1.51) using ZFS pool
Backup destination: Offsite at backup.example.com

Network Service Dependencies

Pi-hole (192.168.1.21) provides DNS for *.homelab.local
DHCP reservations managed on router (192.168.1.1)
VPN server (192.168.1.25) provides remote access

Container and VM IP Management

Docker Networking Strategy

Host Networking for Simple Cases

version: '3.8'
services:
  plex:
    image: plexinc/pms-docker
    network_mode: host
    # Uses host IP: 192.168.1.52

Bridge Networks with Port Mapping

version: '3.8'
services:
  nginx:
    image: nginx
    ports:
      - "192.168.1.151:80:80"  # Explicit IP binding
      - "192.168.1.151:443:443"

Custom Docker Networks

networks:
  homelab:
    ipam:
      config:
        - subnet: 172.20.0.0/16
          gateway: 172.20.0.1
services:
  app:
    networks:
      homelab:
        ipv4_address: 172.20.0.10  # Predictable internal IP

VM IP Assignment Strategies

Static Assignment in VM

Pro: Survives host changes
Con: Must manage DNS, gateway configuration
Use for: Critical infrastructure VMs

DHCP Reservations

Pro: Centralized management
Con: Depends on DHCP server reliability
Use for: Most application VMs

Cloud-Init with Static IPs

network:
  version: 2
  ethernets:
    ens18:
      dhcp4: no
      addresses: [192.168.1.105/24]
      gateway4: 192.168.1.1
      nameservers:
        addresses: [192.168.1.21, 1.1.1.1]

Monitoring and Maintenance

Network Discovery and Verification

Automated Network Scanning

# Daily cron job to verify expected devices
#!/bin/bash
EXPECTED_IPS=(
  "192.168.1.51:Proxmox"
  "192.168.1.52:Docker-Host-1"
  "192.168.1.54:NAS"
)

for entry in "${EXPECTED_IPS[@]}"; do
  IP=${entry%%:*}
  NAME=${entry##*:}
  if ! ping -c 1 $IP > /dev/null; then
    echo "WARNING: $NAME ($IP) is not responding"
  fi
done

Service Health Monitoring

Uptime Kuma for HTTP service monitoring
Prometheus + Grafana for infrastructure metrics
Netdata for real-time system monitoring

Change Management Process

Before Adding New Services:

Check IP availability in planned range
Document service purpose and dependencies
Plan for persistent storage and backup requirements
Consider firewall and reverse proxy changes

When Decommissioning Services:

Update documentation to show “deprecated”
Check for dependent services
Plan graceful shutdown and data migration
Free up IP address for future use

Regular Maintenance Tasks:

Monthly: Verify critical services are accessible
Quarterly: Review IP assignments and update documentation
Annually: Evaluate network architecture and plan improvements

Backup and Disaster Recovery

Network Configuration Backup

Router Configuration

Export DHCP reservations
Save firewall rules and port forwards
Document WiFi and VLAN configurations

Service Configurations

Docker Compose files and .env files
VM configurations and cloud-init templates
Reverse proxy and SSL certificate configurations

IP Address Recovery Plan

Essential IP List (print and keep in a safe place):

Router admin: 192.168.1.1
Primary DNS: 192.168.1.21 (Pi-hole)
Main hypervisor: 192.168.1.51
NAS/storage: 192.168.1.54
Backup server: [external IP or VPN endpoint]

Recovery Priority:

Core networking (router, DNS, DHCP)
Hypervisor and storage
Critical services (reverse proxy, monitoring)
Application services
Development and testing environments

Scaling Beyond Single-Site Homelabs

Multi-Site Management

Home Lab + Colo/VPS:

Home: 192.168.1.0/24
VPS: 10.0.1.0/24
VPN interconnect for hybrid services

Multiple Physical Locations:

Main home: 192.168.1.0/24
Workshop/garage: 192.168.2.0/24
Remote cabin: 192.168.3.0/24

Advanced Networking Features

Dynamic DNS Integration:

Internal services: *.homelab.local
External access: dynamic.example.com
Automatic IP updates for WAN changes

Load Balancing and HA:

Multiple Docker hosts with service distribution
Database clustering and failover
Shared storage for stateless service migration

The Homelab Documentation Maturity Model

Level 1: Basic Inventory

List of devices and their primary IPs
Notes about what each device does
Contact info for critical services

Level 2: Service Documentation

Service dependencies and relationships
Deployment and configuration details
Basic troubleshooting information

Level 3: Infrastructure as Code

Automated deployment scripts
Configuration management (Ansible, Terraform)
Integrated monitoring and alerting

Level 4: Professional Operations

Change management processes
Automated backups and disaster recovery
Performance baselines and capacity planning

Most homelabs benefit enormously from reaching Level 2—you don’t need to go full enterprise to solve the “which IP was that again?” problem.

Your homelab network documentation should grow with your infrastructure. Start simple, be consistent, and focus on the information you actually need when things break at midnight.

Managing IP addresses across multiple servers and services? See how Netory helps homelabbers organize network documentation without enterprise complexity.