Docker Network Drivers
Docker network drivers control how containers communicate with each other and with the outside world. This guide covers all five built-in drivers: bridge, host, none, overlay, and macvlan, with use cases and practical examples.
Docker network drivers are pluggable interfaces that define how containers communicate. Each driver provides a different networking model with different isolation, performance, and use case characteristics. Understanding these drivers is essential for designing container architectures that are secure, performant, and maintainable.
By default, Docker provides five built-in network drivers: bridge (default for standalone containers), host (removes network isolation), none (completely isolated), overlay (connects containers across multiple hosts), and macvlan (assigns MAC addresses to containers). You can also install third-party drivers for advanced use cases.
docker network ls. To inspect a network: docker network inspect bridge.
| Driver | Isolation | Use Case | Multi-Host |
|---|---|---|---|
| bridge | Container-level | Default, single-host communication | No |
| host | None (uses host network) | High performance, direct port access | No |
| none | Full isolation | Security, containers with no network | No |
| overlay | Swarm-level | Multi-host communication, Swarm mode | Yes |
| macvlan | MAC-level | Direct physical network access | Yes |
The bridge driver is the default network driver for standalone containers. It creates a private internal network on the host. Containers on the same bridge network can communicate with each other using IP addresses. Containers on different bridge networks are isolated by default.
When you run a container without specifying a network, Docker connects it to the default bridge network. However, using the default bridge network has limitations: containers can only communicate by IP (not by container name), and you need manual port publishing to expose services.
For better isolation and name resolution, create custom bridge networks. Custom bridge networks provide automatic DNS resolution (containers can ping each other by name) and better isolation.
# Create a custom bridge network
docker network create my-bridge
# Run containers on the custom network
docker run -d --name web --network my-bridge nginx
docker run -d --name app --network my-bridge node:18
# Containers can communicate by name
docker exec app ping web # Works!
# Connect existing container to network
docker network connect my-bridge existing-container
# Disconnect container from network
docker network disconnect my-bridge container-name
# Inspect network to see connected containers
docker network inspect my-bridge
The host driver removes network isolation between the container and the Docker host. The container uses the host's network stack directly—it shares the host's IP address and port space. This means you don't need to publish ports with -p; the container's ports are automatically available on the host.
Host networking offers the highest performance because there's no network address translation (NAT) overhead. However, it reduces security because containers are not isolated. Port conflicts become possible—only one container can bind to a specific port on the host. Host networking is only available on Linux hosts (not Docker Desktop on macOS or Windows).
Use host networking for performance-critical applications where you need maximum throughput, or when the container needs to bind to many ports (like a monitoring agent).
# Run container with host network (Linux only)
docker run -d --name web --network host nginx
# No port publishing needed - container uses host ports directly
# Nginx on port 80 is now accessible at localhost:80
# Verify network mode
docker inspect web | grep -A 5 NetworkMode
# Important: Port conflicts will prevent container startup
# If host is already using port 80, nginx won't start
The none driver disables all networking for the container. The container has only a loopback interface (localhost) and no external network connectivity. This is the most secure network configuration because the container cannot send or receive any network traffic.
Use none networking for batch jobs, data processing containers that don't need network access, or when you want to manually configure networking using low-level tools. It's also useful for security-sensitive containers that should not have any network exposure.
# Run container with no network
docker run -it --network none alpine sh
# Inside container - only loopback exists
ip addr show
# 1: lo: ... (only loopback)
# No external connectivity
ping 8.8.8.8 # Fails - network unreachable
# Suitable for batch processing containers
docker run --network none --rm python:3.11 python -c "print('Processing data...')"
The overlay driver creates a distributed network that spans multiple Docker daemons (hosts). It's primarily used with Docker Swarm mode to allow containers on different hosts to communicate securely as if they were on the same network. Overlay networks use VXLAN encapsulation to tunnel traffic between hosts.
Overlay networks are essential for multi-host container deployments. They provide automatic encryption (optional), service discovery, and load balancing. When you deploy a service in Swarm mode, you typically attach it to an overlay network.
To use overlay networks, you must first initialize Docker Swarm mode: docker swarm init on the manager node, then join worker nodes. Overlay networks are created on the manager and automatically distributed to all Swarm nodes.
# Initialize Swarm mode (manager node)
docker swarm init --advertise-addr 192.168.1.10
# Create an overlay network (encrypted)
docker network create -d overlay --attachable my-overlay
# Run services on the overlay network
docker service create --name web --network my-overlay --replicas 3 nginx
# Attach standalone container to overlay network (needs --attachable flag)
docker run -d --network my-overlay --name client alpine sleep infinity
# Inspect overlay network
docker network inspect my-overlay
# Leave Swarm when done (on worker nodes)
docker swarm leave
docker swarm leave --force (on manager)
The macvlan driver assigns a real MAC address and IP address to each container, making it appear as a physical device on your network. This allows containers to connect directly to your existing physical network, bypassing Docker's NAT layer.
Macvlan is useful for legacy applications that need to be on the same network as physical devices, or for scenarios where you need containers to receive traffic directly (without port publishing). However, macvlan requires your physical network switch to support promiscuous mode (most do), and each container consumes an IP address from your network's DHCP pool.
Common use cases: migrating VM-based workloads to containers while keeping the same IP addresses, running network monitoring tools that need to see raw traffic, or integrating with hardware appliances.
# Create macvlan network (Linux host required)
# Bridge mode - containers get IPs from parent interface's subnet
docker network create -d macvlan \
--subnet=192.168.1.0/24 \
--gateway=192.168.1.1 \
--ip-range=192.168.1.128/25 \
-o parent=eth0 \
my-macvlan
# Run container on macvlan network
docker run -d --name web --network my-macvlan --ip=192.168.1.130 nginx
# Run with DHCP (requires dhcp client in container)
docker run -d --name dhcp-test --network my-macvlan alpine sleep infinity
# Important: Host cannot communicate with macvlan containers via parent interface
# Add a macvlan subinterface on host for communication
docker network create -d macvlan \
--subnet=192.168.1.0/24 \
--gateway=192.168.1.1 \
-o parent=eth0.100 \
vlan100-macvlan
Use bridge (custom) for most standalone containers. Custom bridge networks provide automatic DNS resolution, better isolation, and are the standard choice for single-host applications.
Use host for performance-critical applications where you need maximum throughput and low latency, and security isolation is less critical (e.g., monitoring agents, performance benchmarks).
Use overlay for multi-host deployments. If you're using Docker Swarm or Kubernetes, overlay networks are the standard way to connect containers across hosts.
Use macvlan when containers need to be first-class citizens on your physical network (e.g., migrating VMs to containers with same IPs).
Use none for batch jobs or containers that should have no network access. This is the most secure option.
# List all networks
docker network ls
# Inspect a network (shows connected containers, subnet, gateway)
docker network inspect bridge
# Create a custom bridge network
docker network create --driver bridge --subnet 172.20.0.0/16 --gateway 172.20.0.1 mynet
# Create overlay network (requires swarm mode)
docker network create -d overlay --attachable my-overlay
# Create macvlan network
docker network create -d macvlan --subnet=192.168.1.0/24 --gateway=192.168.1.1 -o parent=eth0 my-macvlan
# Connect container to network (after creation)
docker network connect mynet my-container
# Disconnect container from network
docker network disconnect mynet my-container
# Remove network
docker network rm mynet
# Run container on specific network
docker run -d --name web --network mynet nginx
# Clean up unused networks
docker network prune
docker exec -it container bash then test: ping other-container, curl http://service:port, ip addr show. Also check docker network inspect network-name to see connected containers.Choosing the right network driver is critical for security, performance, and functionality. For most containers, start with a custom bridge network.