Default Bridge vs User-Defined Bridge

Docker creates a default bridge network named bridge — the docker0 interface — and attaches every container to it unless you say otherwise. It is the wrong network to use for anything real. The default bridge gives containers no automatic name resolution: they can reach each other only by raw IP address or the deprecated --link flag, and a container's IP changes every time it restarts.

A user-defined bridge — one you create with docker network create — adds an embedded DNS server, so containers find each other by name, and it isolates its members from containers on other networks. The rule for this whole chapter fits on one line: always create a user-defined bridge; never run a multi-container app on the default one.

The Default Bridge, and Why It's a Trap

Every container started with no --network flag lands on the default bridge. It works fine for the simplest case — a single container that just needs to reach the internet through NAT. The trap springs the moment you have two containers that must talk. There is no DNS on the default bridge, so web can reach db only at an address like 172.17.0.3 — an address Docker assigns from the subnet at startup and reassigns on the next restart. Hardcode it and the app works until the first docker restart, then breaks for a reason that looks like anything but networking.

--link Is Deprecated

The old workaround for name resolution on the default bridge was --link, which injects /etc/hosts entries into one container pointing at another. It is deprecated for good reasons: it is one-directional, it breaks when the linked container restarts with a new IP, and it survives today only in legacy setups. Do not build on it. If you find yourself reaching for --link, the real answer is a user-defined bridge.

User-Defined Bridges and Automatic DNS

Creating a network is one command, and it changes everything about how the containers find each other.

docker network create driftwood-net

docker run -d --name db --network driftwood-net postgres:16
docker run -d --name web --network driftwood-net driftwood:latest

docker network create driftwood-net makes a bridge with Docker's embedded DNS server (topic 41) attached. Any container on driftwood-net resolves every other container on it by name, so web's database URL is simply db:5432 and stays correct no matter which IP db draws at startup. This single feature — name resolution that survives restarts — is what makes a multi-container app sane to operate.

Isolation by Network

A container can reach only the containers it shares a network with. A user-defined bridge is its own broadcast domain — its own switch — so a container on driftwood-net cannot reach a container on some other network, and vice versa. That gives you isolation the default bridge does not: on the flat default bridge, every container shares one network, so an unrelated container can reach your db by IP. Topic 44 builds real tier isolation on this property; for now the point is that separate networks are walls, and the default bridge has none.

Driftwood on driftwood-net

The three Driftwood containers join one user-defined bridge, driftwood-net. proxy resolves web, web resolves db, and none of them carries a hardcoded IP anywhere — the wiring is written once with names and works on every machine and across every restart. This is the spine of the chapter, and it is exactly the shape Docker Compose (Chapter 8) creates for you automatically: when a tutorial's containers "just find each other by name," it is because Compose quietly made a user-defined network like this one.