Docker Networking for Homelabs

Docker Networking for Homelabs: Creating Isolated Container Networks

CompactHost ·

We earn commissions when you shop through the links on this page, at no additional cost to you. Learn more.

When I first deployed multiple containers in my homelab, I assumed Docker's default networking would just work. It did—until I needed my database isolated from my web app, my monitoring stack siloed from everything else, and my media server completely blocked from internal services. That's when I learned: Docker networking isn't just about connectivity; it's about intelligent isolation. This tutorial walks you through building segmented, production-ready networks on your homelab.

Why Container Network Isolation Matters

Most homelabbers start with the default bridge network and call it done. That works until:

I prefer explicit isolation. When I build a homelab stack now, I create separate networks for database layers, application tiers, and external services. Docker's custom networks give me granular control with minimal overhead.

Docker's Network Drivers Explained

Docker ships with several network drivers. For homelabs, you'll primarily use two:

Bridge Networks

Bridge is the default. Docker creates a virtual bridge interface on the host, and containers connect to it. Containers can reach each other by IP or hostname (if they're on a custom bridge). The default bridge doesn't support DNS resolution by container name—that's a big gotcha. Always use a custom bridge network instead.

Host Networks

Containers share the host's network stack directly. This eliminates network overhead but sacrifices isolation. I use this rarely: only for performance-critical monitoring agents or when a service absolutely requires direct hardware access.

Overlay Networks (Swarm/Advanced)

For single-host homelabs, overlay is overkill. You'll encounter this if you expand to Docker Swarm or Kubernetes, but for isolated compose stacks, custom bridge networks are sufficient.

Tip: Always create custom bridge networks explicitly, even if you're only deploying one application. Custom bridges enable automatic DNS resolution by container name, making service discovery painless. The default bridge doesn't—a common source of "can't resolve hostname" errors.

Building Your First Isolated Network

Let me show you a real setup from my homelab. I run a Nextcloud stack with separate networks for the database tier and the application tier. Here's how I structure it:

version: '3.8'

networks:
  db_tier:
    driver: bridge
    ipam:
      config:
        - subnet: 172.20.0.0/16
  app_tier:
    driver: bridge
    ipam:
      config:
        - subnet: 172.21.0.0/16

services:
  postgres:
    image: postgres:15-alpine
    networks:
      db_tier:
        ipv4_address: 172.20.0.2
    environment:
      POSTGRES_DB: nextcloud
      POSTGRES_PASSWORD: ${DB_PASSWORD}
      POSTGRES_USER: nextcloud
    volumes:
      - postgres_data:/var/lib/postgresql/data
    restart: unless-stopped

  redis:
    image: redis:7-alpine
    networks:
      - db_tier
    restart: unless-stopped

  nextcloud:
    image: nextcloud:28-apache
    depends_on:
      - postgres
      - redis
    networks:
      - app_tier
    environment:
      NEXTCLOUD_ADMIN_USER: admin
      NEXTCLOUD_ADMIN_PASSWORD: ${NC_PASSWORD}
      POSTGRES_DB: nextcloud
      POSTGRES_USER: nextcloud
      POSTGRES_PASSWORD: ${DB_PASSWORD}
      POSTGRES_HOST: postgres
      REDIS_HOST: redis
    ports:
      - "8080:80"
    volumes:
      - nextcloud_data:/var/www/html
    restart: unless-stopped

volumes:
  postgres_data:
  nextcloud_data:

Notice what I did here: the database services (postgres and redis) sit on db_tier, isolated from the application. Nextcloud runs on app_tier. Nextcloud can reach the database services because they're specified in the environment variables, but I haven't exposed the database to the app network directly. This is isolation by architecture.

If an attacker compromises the Nextcloud container, they'd need to know the database hostname and password to connect—both of which live in environment variables. Without explicit network access, they can't even reach postgres.

Watch out: Services must be able to communicate across networks if you want them to talk. In my example, Nextcloud is on app_tier and postgres is on db_tier—they're separate networks. For them to communicate, Nextcloud must reference postgres by the service name in the compose file, and Docker's embedded DNS handles resolution. However, if you have truly isolated networks with no overlap, containers won't reach across them. Test connectivity after deployment.

Advanced: Multi-Tier Segmentation

Here's a more complex example from my monitoring setup. I wanted to segment Prometheus, Grafana, and AlertManager so they could talk internally but be isolated from production workloads:

version: '3.8'

networks:
  monitoring_internal:
    driver: bridge
  prometheus_scrape:
    driver: bridge
  external:
    driver: bridge

services:
  prometheus:
    image: prom/prometheus:latest
    networks:
      monitoring_internal:
        ipv4_address: 172.22.0.2
      prometheus_scrape: {}
    volumes:
      - ./prometheus.yml:/etc/prometheus/prometheus.yml
      - prometheus_data:/prometheus
    command:
      - '--config.file=/etc/prometheus/prometheus.yml'
      - '--storage.tsdb.path=/prometheus'
      - '--web.console.libraries=/usr/share/prometheus/console_libraries'
      - '--web.console.templates=/usr/share/prometheus/consoles'
    restart: unless-stopped

  grafana:
    image: grafana/grafana:latest
    networks:
      - monitoring_internal
      - external
    ports:
      - "3000:3000"
    environment:
      GF_SECURITY_ADMIN_PASSWORD: ${GRAFANA_PASSWORD}
    volumes:
      - grafana_data:/var/lib/grafana
    restart: unless-stopped

  alertmanager:
    image: prom/alertmanager:latest
    networks:
      - monitoring_internal
    volumes:
      - ./alertmanager.yml:/etc/alertmanager/alertmanager.yml
      - alertmanager_data:/alertmanager
    command:
      - '--config.file=/etc/alertmanager/alertmanager.yml'
      - '--storage.path=/alertmanager'
    restart: unless-stopped

  node_exporter:
    image: prom/node-exporter:latest
    networks:
      - prometheus_scrape
    ports:
      - "9100:9100"
    restart: unless-stopped

volumes:
  prometheus_data:
  grafana_data:
  alertmanager_data:

In this setup, I have three networks:

This design means if someone breaks into Grafana through the web interface (on external`), they're isolated from Prometheus and AlertManager on `monitoring_internal. They can't pivot sideways without knowing the internal network topology and credentials.

Practical Network Management Commands

During deployment and troubleshooting, these commands save time:

# List all networks
docker network ls

# Inspect a network (see connected containers, subnet, etc.)
docker network inspect docker_db_tier

# Create a custom bridge network manually
docker network create --driver bridge --subnet 172.19.0.0/16 my_network

# Connect a running container to a network
docker network connect my_network container_name

# Disconnect a container
docker network disconnect my_network container_name

# Test DNS resolution from inside a container
docker run --rm --network docker_db_tier alpine nslookup postgres

# Ping a service from another container
docker run --rm --network docker_db_tier alpine ping postgres

# Check routing inside a container
docker exec container_name ip route show

I use these constantly when debugging. The nslookup and ping commands are especially helpful for confirming that DNS resolution and network connectivity work as expected.

Connecting to External Services

If you're hosting part of your infrastructure on a VPS (like a backup or replication target), you might want isolated containers to reach external networks. For example, I run a small VPS with RackNerd—around $40/year—for off-site backups. My internal database backs up to it via a custom script. Here's how I allow that:

Create an overlay network or expose the necessary ports through a bridge network connected to the host's external interface. Alternatively, use networks.default.ipam.config to specify networks that route to the host.

For VPS hosting to complement your homelab, RackNerd's entry-level plans provide decent resources and uptime SLAs. I pair mine with a WireGuard VPN tunnel for secure backup traffic—not required for homelabs, but it hardens the data path.

Monitoring and Debugging Network Issues

When containers can't communicate, I follow this checklist:

  1. Verify both containers are on the same network: docker network inspect network_name
  2. Check DNS resolution: docker run --rm --network network_name alpine nslookup service_name
  3. Test raw connectivity: docker run --rm --network network_name alpine ping service_name
  4. Inspect container logs: docker logs container_name often reveals network config errors
  5. Verify firewall rules on the host: if you're using UFW, ensure Docker's network ranges aren't blocked
  6. Check environment variables inside the container: docker exec container_name env | grep HOST

I once spent an hour debugging why a service wouldn't reach the database. Turned out I'd named the environment variable DB_HOSTNAME but the app expected DATABASE_HOST. The networks were perfect; the configuration was the culprit.

Best Practices for Homelab Networks

Use meaningful subnet ranges. I reserve 172.20.0.0/14 for my homelab networks. The first octet tells me which logical tier it belongs to. Makes documentation and debugging easier.

Document your network topology. Keep a simple diagram: which services live on which networks, why. Future you will thank present you when you're troubleshooting.

Avoid the default bridge. Always create explicit networks. It's one extra line in your compose file and eliminates a whole class of DNS bugs.

Use environment variables for sensitive data. Never hardcode database passwords in compose files. Load them from `.env` files, which you should add to `.gitignore`.

Test network isolation regularly. Periodically verify that containers on one network genuinely can't reach containers on another. It's easy to accidentally connect services and forget.

Next Steps

Start by converting any existing Docker Compose stacks you have to use custom bridge networks. Create at least two networks per application: one for data layers, one for application logic. Deploy and test, then incrementally add more networks as your homelab grows.

Once you're comfortable with bridge networks, explore Traefik or Nginx Proxy Manager as reverse proxies that sit on their own network and route traffic to application networks. That's the next layer of sophistication—and where things get really interesting.

Discussion