Docker Network Drivers: bridge, host, overlay, macvlan, and when to use each

Six built-in network drivers, each with a different isolation model. A practical guide to bridge vs host vs overlay vs macvlan vs ipvlan — and the user-defined network features most projects never discover.

Published on • October 13, 2026

AI Assistant

docker run -p 8080:80 works on a laptop, in CI, and on a server — and almost nobody thinks about which of Docker’s six network drivers is behind it. Then a service needs to reach another container by name, or appear on the LAN as a real device, or span two hosts — and the default bridge quietly stops being the answer.

Docker’s networking is built on pluggable drivers. Understanding what each one isolates, how it addresses traffic, and where its limits are turns “why can’t the containers reach each other” from an afternoon into a two-minute fix.

The six built-in drivers

docker network ls shows the driver for each network:

NETWORK ID     NAME      DRIVER    SCOPE
a1b2c3         bridge    bridge    local
b2c3d4         host      host      local
c3d4e5         none      null      local
d4e5f6         app_net   bridge    local
e5f6a6         swarm_net overlay   swarm

bridge — the default for standalone containers. Containers on a bridge get veth pairs into a software bridge, and traffic leaving the host is NATed. Isolation is at the container level; port publishing is how the outside world reaches in.

host — removes network isolation entirely. The container shares the host’s network namespace: same IPs, same ports, no -p mapping. Maximum performance, zero isolation — right for a monitoring agent or a latency-sensitive proxy, wrong the moment two containers need the same port. (The namespace mechanics live in Linux namespaces and container isolation.)

overlay — multi-host networking for Swarm services. Containers on different nodes communicate over VXLAN-encrypted tunnels, addressed as if on one LAN. An --opt encrypted flag adds data-plane encryption for untrusted networks.

macvlan — gives containers their own MAC address and a real IP on your physical network, assigned by your DHCP or a pool. To the router, each container is just another host. Requires the parent interface to allow promiscuous mode — which many cloud providers refuse, which is exactly why the next driver exists.

ipvlan — like macvlan but shares the parent interface’s MAC address, allocating only IPs. It works where macvlan is blocked (cloud environments, switches with MAC limits, bonded interfaces), at the cost of MAC-based features.

none — no networking. Only a loopback interface. Correct for batch jobs that must never phone home, or for build-time isolation.

User-defined bridges: the upgrade most projects skip

The implicit bridge network has two well-known gaps: no automatic DNS between containers and weak isolation (containers can reach each other’s unpublished ports by default). User-defined bridge networks fix both:

docker network create app_net
docker run -d --network app_net --name api my-api
docker run -d --network app_net --name db postgres:16

Now api resolves db by name via Docker’s embedded DNS at 127.0.0.11 — container-to-container by service name, no hardcoded IPs, no links. Isolation improves too: containers on different user-defined networks cannot reach each other unless explicitly connected. Attach more networks to expose selected services:

docker network create backend
docker network connect backend db     # db now on app_net AND backend

Two underused features on user-defined networks:

--network-alias — multiple containers answering to one name, giving you free client-side round-robin for a pool of workers.
gw-priority — when a container joins several networks, which one provides the default gateway. Without it, “why does my container’s outbound traffic take the wrong path” becomes a packet-capture session.

Choosing a driver: a decision table

Situation	Driver
Single host, a few services	`bridge` (user-defined)
Max performance, host-level agent	`host`
Swarm services across hosts	`overlay`
Containers must be real LAN devices	`macvlan`
Cloud/network blocks promiscuous mode	`ipvlan`
No network at all	`none`
Share one container’s stack exactly	`--network container:X`

That last row is worth calling out: docker run --network container:api sidecar puts the sidecar in api’s network namespace — same IP, same ports, localhost to localhost. This is how log shippers and service meshes historically piggybacked on the main process, and it is the networking analogue of PID sharing: powerful, and intimate enough that you must audit which processes get it.

Driver options and per-network tuning

Drivers accept options at creation:

docker network create -d bridge \
  -o com.docker.network.bridge.name=br-app \
  --subnet 172.28.0.0/16 \
  --ip-range 172.28.5.0/24 \
  --gateway 172.28.0.1 \
  app_net

Pinning subnets matters more than people expect: predictable CIDRs let you write firewall rules and service-mesh configs instead of discovering what the allocator picked today. For macvlan, -d macvlan -o parent=eth0 selects the physical parent; for ipvlan, -o ipvlan_mode=l3 switches from the default L2 mode when your environment needs L3 routing.

Diagnosing when it breaks

The debugging toolkit is small and sufficient:

docker network inspect app_net          # which containers, which IPs
docker exec api getent hosts db         # does embedded DNS resolve?
docker exec api ip route                # which gateway, which paths
docker exec api ping -c1 db

The overwhelming majority of cross-container connectivity problems are one of three things: containers on different networks that were never connected, an app binding to 127.0.0.1 inside the container (only reachable from that container — the classic “works with host networking, breaks with bridge”), or a published port on the default bridge while the client uses the user-defined network’s DNS name. Inspect first, curl second.