Network Drivers

Every Docker container connects to a network driver that determines how it communicates. The driver you choose affects isolation, performance, and how services discover each other.

The Four Drivers

Driver	How It Works	Best For
bridge	Isolated virtual network on a single host. Containers communicate via Docker DNS	Most workloads. Default and recommended
host	Container shares the host's network namespace directly. No port mapping needed	Performance-critical apps needing minimal network overhead
none	Container has no network interfaces (only loopback)	Isolated batch jobs, security-sensitive processing
macvlan	Container gets its own MAC address and appears as a physical device on the LAN	Legacy integrations requiring direct L2 network access

Bridge Networks (Use This by Default)

Bridge is the standard choice. Containers on the same bridge network can communicate, and are isolated from containers on other networks.

Default Bridge vs User-Defined Bridge

Feature	Default bridge	User-Defined Bridge
DNS resolution by name	No (must use --link, deprecated)	Yes (automatic)
Isolation between groups	All containers on one network	Create separate networks per group
Connect/disconnect live	No	Yes

Always create a user-defined bridge instead of using the default:

# Create a network
docker network create app-net

# Run containers on it
docker run -d --name api --network app-net my-api:1.0.0
docker run -d --name db --network app-net postgres:16

# api can reach db by name:
docker exec api ping db

Visualizing a Bridge Network

Host Network

Removes the network isolation layer. The container uses the host's IP and ports directly:

docker run -d --network host nginx
# nginx is now listening on the host's port 80 directly

Advantage	Disadvantage
No port mapping overhead	No port isolation -- conflicts with host services
Slightly lower latency	Cannot run two containers on the same port
Simpler for debugging	Reduced security (no network namespace)

Use host mode only when you have a specific performance or architectural need, not as a convenience shortcut.

None Network

Disables all networking. The container only has a loopback interface:

docker run --rm --network none alpine ip addr
# Only shows lo (127.0.0.1)

Use for jobs that should never make network connections.

Network Segmentation Pattern

Use multiple bridge networks to control which services can communicate:

services:
  web:
    image: nginx:alpine
    networks: [front, back]
    ports:
      - "80:80"
  api:
    image: my-api:1.0.0
    networks: [back]
  db:
    image: postgres:16
    networks: [back]

networks:
  front: {}
  back: {}

In this setup, web can reach api and db, but external traffic can only reach web. The database is never exposed.

Managing Networks

# List all networks
docker network ls

# Create a network
docker network create my-net

# Inspect a network (see connected containers)
docker network inspect my-net

# Connect a running container to a network
docker network connect my-net my-container

# Disconnect a container
docker network disconnect my-net my-container

# Remove a network (must have no connected containers)
docker network rm my-net

Key Takeaways

• User-defined bridge is the right default for almost all workloads -- it provides DNS, isolation, and easy management.
• The default bridge network lacks DNS discovery. Always create your own.
• Use host mode only for specific performance needs, not convenience.
• Use multiple networks to segment services (frontend/backend) and limit blast radius.
• Use docker network inspect to verify which containers are connected.

What's Next

• Continue to Port Publishing and Binding to learn how to expose services to the outside world.