Docker Networking Deep Dive: Choosing Between bridge, host, and overlay

Docker container networking controls communication between containers, with the host, and with external networks. The three primary network drivers — bridge, host, and overlay — each have distinct characteristics, and choosing the right one directly impacts application performance and security.

At Kubo, we provide container networking on Kubernetes, but understanding Docker-level networking forms the foundation for Kubernetes networking concepts. This article dives deep into each network mode's architecture and practical selection criteria.

Docker Network Architecture Fundamentals

Docker networking is implemented through the libnetwork library using a pluggable driver model. The Docker official documentation describes five network drivers.

# List available networks
docker network ls

# Inspect network details
docker network inspect bridge

Captain.AI analyzes your application requirements and automatically suggests optimal network configurations.

Bridge Network: The Default Choice

Bridge is Docker's default network driver, most widely used for container-to-container communication on a single host.

How It Works

Docker creates a virtual bridge interface called docker0, and containers communicate through this bridge. Each container receives a private IP address from the 172.17.0.0/16 subnet.

# Start containers on default bridge network
docker run -d --name web nginx
docker run -d --name api node:20-alpine

# Check IP address
docker inspect -f '{{range.NetworkSettings.Networks}}{{.IPAddress}}{{end}}' web

User-Defined Bridge Networks

Using a user-defined bridge network instead of the default bridge is strongly recommended.

# Create user-defined network
docker network create --driver bridge myapp-network

# Start containers on the network
docker run -d --name web --network myapp-network nginx
docker run -d --name api --network myapp-network node:20-alpine

Advantages of user-defined bridges:

• dns-based service discovery: communicate by container name (http:--api:3000)
• Automatic DNS resolution: Default bridge requires IP-based communication
• Network isolation: Block communication between containers on different networks
• Dynamic connect/disconnect: Change running container networks on the fly

The DEV Community Docker networking article recommends user-defined bridges as the standard for all projects.

Bridge Networks in Docker Compose

services:
  web:
    image: nginx
    networks:
      - frontend
  api:
    image: node:20-alpine
    networks:
      - frontend
      - backend
  db:
    image: postgres:16
    networks:
      - backend

networks:
  frontend:
    driver: bridge
  backend:
    driver: bridge
    internal: true  # Block external access

Setting internal: true prevents containers on that network from accessing external networks (internet). This is effective for internal services like databases.

Host Network: Maximum Performance

In host mode, containers directly share the host machine's network namespace. No dedicated IP address is assigned — containers use the host's network interfaces and ports directly.

# Start container with host network
docker run -d --network host nginx

# Binds directly to host port 80
curl http://localhost:80

Performance Characteristics

According to BetterLink's benchmark article, host networking achieves:

Appropriate Uses for Host Mode

• high-frequency network i-o: real-time processing, streaming
• Monitoring tools: Prometheus Node Exporter, etc.
• Network performance testing: iperf3, etc.
• Legacy applications: Those requiring direct port binding

Constraints and Caveats

# Port mapping is ignored in host mode (-p flag is disregarded)
docker run --network host -p 8080:80 nginx  # -p is ignored

• Port conflicts: Multiple containers cannot use the same port
• No isolation: Containers can access the host's entire network
• Security risk: Expanded attack surface without network isolation
• Linux only: Behavior differs on macOS/Windows Docker Desktop

On Kubo's Kubernetes environment, using hostNetwork: true is discouraged unless there is a specific justification.

Overlay Network: Multi-Host Communication

Overlay networks enable containers across multiple Docker hosts to communicate over a distributed network. They are primarily used with Docker Swarm mode.

VXLAN Implementation

Overlay networks use VXLAN (Virtual Extensible LAN) technology. VXLAN encapsulates container Layer 2 frames into IP/UDP packets between hosts, building a virtual overlay network on top of the physical network.

# Initialize Docker Swarm
docker swarm init

# Create overlay network
docker network create --driver overlay --attachable myapp-overlay

# Enable encryption (IPsec)
docker network create --driver overlay --opt encrypted myapp-secure

Required Ports

According to Docker's official Swarm networking documentation, overlay networks require:

Service Discovery and DNS

Docker Swarm automatically assigns a Virtual IP (VIP) to services and registers DNS entries. Other services can reference them by name without hardcoded IP addresses.

# Create Swarm services
docker service create --name web --network myapp-overlay \
  --replicas 3 nginx

docker service create --name api --network myapp-overlay \
  --replicas 2 myapp:latest

# Access web service from api service
# curl http://web:80 (automatic load balancing via VIP)

DNS Round-Robin (DNSRR)

In addition to VIP-based load balancing, DNS round-robin mode is available:

docker service create --name web \
  --endpoint-mode dnsrr \
  --network myapp-overlay \
  nginx

In DNSRR mode, DNS queries return a list of IP addresses for all service replicas, and clients directly choose which to connect to. Reintech's Docker Swarm article provides more detail.

Network Mode Selection Guide

Recommendations by Use Case

Security Best Practices

# Network isolation in Docker Compose
services:
  web:
    networks:
      - frontend
  api:
    networks:
      - frontend
      - backend
  db:
    networks:
      - backend

networks:
  frontend:
    driver: bridge
  backend:
    driver: bridge
    internal: true
    ipam:
      config:
        - subnet: 172.28.0.0-24

The env.dev Docker networking guide emphasizes the importance of network segmentation in production environments.

Relationship with Kubernetes

Docker's networking model serves as the foundation for Kubernetes CNI (Container Network Interface):

The moldstud comprehensive guide covers Docker to Kubernetes networking migration in detail.

Summary: Right Network for the Right Job

Understanding and appropriately selecting among Docker's three primary network drivers is essential for balancing container application performance and security.

• Bridge: First choice for most use cases. Always use user-defined networks.
• Host: Only when performance is the top priority and isolation can be sacrificed.
• Overlay: For inter-service communication in multi-host Docker Swarm environments.

Kubo builds on Docker-level networking knowledge to provide advanced Kubernetes networking capabilities — Service Mesh, NetworkPolicy, and Ingress — as a container platform. Combined with Captain.AI, AI assists from network design through operational monitoring.

For Docker networking or Kubernetes network design consulting, please contact us.