What are Docker's built-in network drivers?

bridge — the default, isolated virtual network

docker run -d --name web nginx        # attaches to the default bridge network automatically
docker network create my-network        # or create a custom, user-defined bridge network
docker run -d --network my-network --name web nginx

Creates a private, virtual network on the host. Containers on the same bridge network can reach each other by IP — and, on a user-defined bridge specifically, by container name via DNS (see the DNS question) — and reach the outside world via NAT through the host. This is the right default for the overwhelming majority of single-host container setups.

host — no network isolation at all

docker run -d --network host nginx

The container shares the host's network namespace directly — no isolation, no virtual interface, no port mapping needed (a container binding to port 80 with --network host is genuinely binding to port 80 on the host itself, directly). This eliminates a layer of network translation overhead, which occasionally matters for latency-sensitive or high-throughput networking use cases. But it sacrifices the isolation benefit entirely. Port conflicts between containers become a real, direct concern — two containers can't both bind the same host port — and a compromised container has direct access to the host's network stack.

none — no networking beyond loopback

docker run --network none myapp

The container gets no external network interface at all — only its own internal loopback (127.0.0.1). Useful for workloads that genuinely need zero network access, either for isolation/security reasons (a batch job processing only local files, with no legitimate reason to reach the network at all) or as an extra layer of defense-in-depth.

overlay — connecting containers across multiple hosts

docker network create -d overlay my-overlay-network    # used with Docker Swarm

Extends bridge-like networking across multiple Docker hosts, letting containers on different physical or virtual machines communicate as if they were on the same local network. This is specifically what Docker Swarm mode (see the production topic) uses to let services span multiple nodes while still reaching each other by name.

macvlan — a container appears as a physical device

docker network create -d macvlan --subnet=192.168.1.0/24 --gateway=192.168.1.1 -o parent=eth0 my-macvlan

Assigns each container its own MAC address and effectively makes it appear as a distinct physical device directly on the host's physical network, bypassing Docker's usual NAT-based bridge networking entirely. Used for niche cases where legacy applications or network monitoring tools expect containers to look like real, individually-addressable devices on the network, rather than being hidden behind the host's single IP via NAT.

Choosing between them, in practice

For the large majority of everyday Docker usage — a web application talking to a database, a handful of services communicating with each other on one machine — a user-defined bridge network (not even the default bridge network, for reasons covered in that question) is the right choice, and the most common one by a wide margin.