Docker Networks: Bridge, Host, Overlay, Macvlan: Production Guide

Understanding Docker Networking

Docker networking is the subsystem that allows containers to communicate with each other, with the host, and with external networks. By default, Docker ships with several built-in network drivers—Bridge, Host, Overlay, and Macvlan—that cover everything from simple single‑host setups to complex multi‑host, production‑grade deployments. Each driver provides a different level of isolation, performance, and configuration flexibility.

Why Network Design Matters in Production

In a production environment, your network topology directly impacts:

• Security – isolation between services prevents lateral movement after a breach.
• Performance – some drivers offer near line‑rate throughput by bypassing virtualisation layers.
• Scalability – overlay networks allow you to spread workloads across dozens of nodes without manual port mapping.
• Operational clarity – a well‑structured network makes debugging, monitoring, and compliance audits far easier.

Choosing the wrong driver can lead to port collisions, IP exhaustion, or containers that cannot reach critical backend services. The following sections dive deep into each driver, complete with production‑ready code examples and best practices.

Bridge Network

What is the Bridge Driver?

The bridge driver creates a private, internal virtual network on a single Docker host. Containers attached to the same bridge can communicate directly via IP address or container name (DNS), while traffic destined outside the host must be explicitly published via port mapping or routing.

Docker provides two bridge networks out‑of‑the‑box:

• Default bridge (named bridge) – legacy, no automatic DNS resolution between containers, not recommended for production.
• User‑defined bridge – provides automatic DNS resolution, better isolation, and the ability to connect/disconnect containers on the fly.

Production Use Cases

• Running multiple containers that need to talk to each other on the same host (e.g. a web app, Redis, and a worker).
• Isolating groups of containers into separate network namespaces for security or compliance.
• Exposing only specific ports to the outside world while keeping internal services hidden.

How to Use Bridge Networks

Always create a user‑defined bridge for production workloads. Below is a complete workflow.

# 1. Create a user-defined bridge network
docker network create \
  --driver bridge \
  --subnet 172.25.0.0/16 \
  --gateway 172.25.0.1 \
  --attachable \
  app_net

# 2. Run a database container, attached to the bridge
docker run -d \
  --name postgres \
  --network app_net \
  --ip 172.25.0.10 \
  -e POSTGRES_PASSWORD=secret \
  postgres:15

# 3. Run an application container that resolves 'postgres' via DNS
docker run -d \
  --name app \
  --network app_net \
  -p 8080:3000 \
  my-app-image:latest

# 4. Inspect the network to see connected containers
docker network inspect app_net

# 5. Dynamically connect an existing container to the bridge
docker network connect app_net existing_container

# 6. Remove a container from the bridge
docker network disconnect app_net existing_container

Best Practices for Bridge

• Always prefer user‑defined bridges over the default bridge. They provide automatic DNS resolution and better isolation.
• Define explicit subnets to avoid clashes with corporate VPNs or other internal networks.
• Use --ip sparingly—let Docker assign IPs via its internal IPAM unless you need static addressing for legacy apps.
• Keep internal services off the host network by not publishing ports unnecessarily. Only expose what’s needed via -p.
• Monitor bridge traffic with tools like docker network inspect and iptables to detect unexpected cross‑container communication.

Host Network

What is Host Networking?

When a container uses the host driver, it shares the host machine’s network namespace directly. The container does not get its own IP address; instead, all its network interfaces are the host’s. Ports opened by the container appear on the host’s IP without any NAT or port mapping overhead.

When to Use Host in Production

• High‑performance networking – applications that require maximum throughput and minimal latency (e.g. network‑intensive proxies, load balancers, or real‑time video streaming).
• Monitoring and system agents – tools like node_exporter or filebeat that need to observe the host’s network interfaces or bind to privileged ports (<1024).
• Legacy or special‑purpose workloads that cannot tolerate double‑NAT or virtual bridge overhead.

Using Host Network

# Run nginx directly on the host network (no port mapping needed)
docker run -d \
  --name nginx-host \
  --network host \
  -v /etc/nginx/conf.d:/etc/nginx/conf.d:ro \
  nginx:latest

# Verify it's listening on the host's port 80
curl http://localhost:80

Because there is no network isolation, any port conflict with host services will cause the container to fail to bind. The container’s entire network stack (iptables, routing table, interfaces) is identical to the host’s.

Best Practices and Caveats

• Use host networking sparingly. It breaks container isolation and makes port management harder.
• Reserve host ports with configuration management (e.g. Ansible, systemd socket units) to avoid accidental collisions.
• Never expose containers using host networking to untrusted networks unless you have additional firewall rules, because the container shares the host’s firewall context.
• Combine with Linux capabilities (like CAP_NET_BIND_SERVICE) for non‑root users binding to low ports instead of full host mode.
• Consider host networking only for infrastructure daemons (monitoring, logging, CNI plugins) that truly need direct host access.

Overlay Network

Understanding Overlay Networks

Overlay networks extend Docker networking across multiple hosts, typically in a Docker Swarm cluster. They use VXLAN encapsulation to tunnel container traffic over physical networks, making containers on different nodes appear as if they are on the same flat network. Overlay networks support encryption (IPSec) and can be created as attachable for standalone containers or used natively by Swarm services.

Production Scenarios

• Microservice deployments across a Swarm cluster – services can discover each other by name via Docker’s built‑in DNS, regardless of which node they run on.
• Multi‑tenant platforms where each tenant’s services need isolated overlay networks with encrypted traffic.
• CI/CD pipelines that spin up temporary test environments spanning multiple worker nodes.

Setting Up Overlay Networks

First, initialize a Swarm (or join an existing one). Then create an overlay network and deploy services.

# On the manager node, init the swarm
docker swarm init --advertise-addr 192.168.1.100

# Create an attachable overlay network (works for both services and standalone containers)
docker network create \
  --driver overlay \
  --attachable \
  --subnet 10.0.9.0/24 \
  --gateway 10.0.9.1 \
  --opt encrypted \
  backend_overlay

# Deploy a Swarm service attached to the overlay
docker service create \
  --name api \
  --network backend_overlay \
  --replicas 3 \
  -p 8000:8000 \
  my-api:latest

# Run a standalone container on any node and attach it to the overlay
docker run -d \
  --name debug-tool \
  --network backend_overlay \
  alpine/socat

Swarm services automatically get load‑balancing and service discovery via the overlay’s internal DNS. The --opt encrypted flag enables automatic IPSec encryption of all VXLAN traffic between nodes.

Overlay Network Best Practices

• Always encrypt overlay traffic in production using --opt encrypted or external tools like WireGuard if your cluster spans untrusted networks.
• Use --attachable only when necessary; otherwise keep networks scoped to Swarm services for better isolation.
• Plan IP subnets carefully to avoid overlapping with corporate LANs or other overlay networks—overlay IPAM is separate but overlapping ranges cause routing confusion.
• Monitor VXLAN overhead; in high‑throughput environments, ensure your physical network can handle the extra encapsulation bytes.
• Keep overlay networks small in terms of attached endpoints to reduce broadcast domain size and DNS chatter.

Macvlan Network

What is Macvlan?

Macvlan assigns a unique MAC address to each container, making it appear as a separate physical device on the network. Containers get their own IP addresses directly from the physical subnet, with no NAT or port mapping. They can communicate at Layer 2 with other physical machines and legacy systems that require direct MAC‑based visibility.

Macvlan Modes and Production Use Cases

• Bridge mode (default) – containers share the parent interface but each gets a unique MAC/IP. Suitable for most cases.
• 802.1q trunk mode – containers are placed into specific VLANs by tagging traffic with VLAN IDs. Perfect for multi‑tenant or legacy VLAN‑segregated environments.
• Legacy application migration – apps that rely on fixed IPs, broadcast discovery, or direct L2 adjacency.
• Network monitoring and intrusion detection – containers that must capture packets from the wire as if they were bare‑metal sensors.

How to Deploy Macvlan Networks

# 1. Create a macvlan network in bridge mode (no VLAN tag)
docker network create \
  --driver macvlan \
  --subnet 192.168.1.0/24 \
  --gateway 192.168.1.1 \
  --ip-range 192.168.1.200/29 \
  -o parent=eth0 \
  macvlan_net

# 2. Run a container with a static IP from the physical subnet
docker run -d \
  --name legacy_app \
  --network macvlan_net \
  --ip 192.168.1.201 \
  my-legacy-app:latest

# 3. Create an 802.1q trunk macvlan for VLAN 10
docker network create \
  --driver macvlan \
  --subnet 10.10.10.0/24 \
  --gateway 10.10.10.1 \
  -o parent=eth0.10 \
  vlan10_net

# 4. Run a container on VLAN 10
docker run -d \
  --name vlan_app \
  --network vlan10_net \
  --ip 10.10.10.50 \
  my-app-vlan:latest

The parent interface must exist on the host and be up. For VLAN trunking, create the sub‑interface (eth0.10) before creating the network, or use the macvlan driver with -o parent=eth0 -o vlan=10 (driver‑level VLAN tagging where supported).

Macvlan Production Best Practices

• Reserve IP ranges with your network team before deploying Macvlan containers to avoid DHCP conflicts.
• Use dedicated parent interfaces (e.g. a secondary NIC) for Macvlan traffic to keep host management traffic separate and avoid MAC flooding issues.
• Enable promiscuous mode on the parent interface in virtualised environments (VMware, cloud) to allow the hypervisor to pass multiple MAC addresses.
• Monitor ARP tables on upstream switches; each container generates its own ARP entry, which can stress small routers.
• Combine with firewall rules (either on‑host or upstream) because Macvlan containers bypass Docker’s usual NAT‑based protection and are exposed directly to the physical network.

Network Comparison and Decision Framework

The table below summarises when each driver fits best. Use it as a quick reference when designing your production architecture.

• Bridge – single‑host, container‑to‑container communication, moderate isolation, easy port publishing. Start here unless you have a clear reason to choose another driver.
• Host – maximum performance, no isolation, suitable only for privileged infrastructure services that must share the host’s network stack.
• Overlay – multi‑host Swarm clusters, encrypted inter‑node traffic, built‑in service discovery. The default for distributed production applications.
• Macvlan – direct L2 connectivity, legacy integrations, VLAN‑based isolation, no NAT overhead. Use when containers must appear as physical endpoints on your corporate LAN.

Conclusion

Choosing the right Docker network driver is a foundational decision that affects security, performance, and operational complexity. In production, lean towards user‑defined bridge for single‑host isolation, overlay for multi‑host microservices, and reserve host and macvlan for the specialised cases where their unique characteristics are genuinely required. Always plan IP spaces ahead, encrypt inter‑node traffic, and document your network topology alongside your container orchestration configuration. A deliberate network strategy turns Docker from a simple container runtime into a robust, production‑grade platform.