What is Docker's default `bridge` network (docker0), and why does Docker recommend creating your own bridge network instead?

## The three networks Docker gives you for free On a fresh engine, `docker network ls` lists three predefined networks: `bridge`, `host` and `none`. The `bridge` entry is what people call the **default bridge**. When dockerd starts it creates a Linux bridge device on the host named `docker0`, gives it an address, and attaches every container that is started without an explicit `--network` flag to it. None of the three predefined networks can be removed. ## What attachment actually looks like When a container joins any bridge network, the daemon creates a veth pair: one end stays on the host and is enslaved to the bridge device, the other is moved into the container's network namespace where it appears as `eth0`. The container gets an address out of that bridge's subnet and a default route pointing at the bridge's own address. A network you create — `docker network create digest-net` — gets exactly the same plumbing; the only visible difference on the host is that the bridge device is named `br-<first characters of the network id>` rather than `docker0`. So the *mechanism* is identical. What differs is scope, discovery, configuration and lifecycle. ## Difference 1 — who is on the segment The default bridge is a single shared segment. Every container on the host that did not ask for a network is a peer of every other one: your database, a colleague's debugging shell, a job container someone left running. A network you create is a membership list. Only the containers you attach are on it, and a container attached to a different bridge cannot reach in, because the daemon does not route between the two bridges. That is the isolation people mean when they say "put it on its own network". ## Difference 2 — discovery On a user-defined bridge Docker gives each attached container an embedded resolver, so container names and network aliases resolve to the peer's current address. On the default bridge there is no such resolution: you address peers by IP, or historically by declaring a `--link`. Since a container's address is handed out at start time and can be different after the next start, "IP only" is a fragile way to wire anything together. The internals of that resolver are a separate subject; the bridge-level fact to carry into an interview is that the feature exists only on networks you create. ## Difference 3 — configuration granularity Settings for docker0 are daemon-wide. `mtu`, `icc`, `bip` and the address pools live in `/etc/docker/daemon.json`, and changing one means restarting dockerd, which touches every container on the host. A network you create takes its settings at creation time and keeps them: `--subnet`, `--gateway`, `--internal`, and `--opt` keys such as `com.docker.network.driver.mtu`, `com.docker.network.bridge.enable_icc`, `com.docker.network.bridge.name` and `com.docker.network.bridge.enable_ip_masquerade`. Those options are immutable afterwards — to change one you create a replacement network and re-attach the containers — but the blast radius of a change is one network, not the whole engine. ## Difference 4 — lifecycle A running container can be attached to a network you created with `docker network connect`. For the default bridge, Docker's guidance is to recreate the container with `--network` rather than shuffling it around, because its networking was decided at creation. ## Difference 5 — legacy versus current `--link` only ever made sense on the default bridge, as a workaround for the missing name resolution. It is documented as legacy. On a user-defined network you simply use the peer's name. ## The failure everybody meets A stack that worked as a Compose project is re-run by hand as three `docker run` commands. Under Compose the containers were on a network of their own; run by hand they land on docker0, and the first thing that breaks is name resolution — a Ruby email-digest builder that opens `redis://digest-redis:6379` now dies with `getaddrinfo: Name or service not known`. The fix is a network, not hand-written `/etc/hosts` entries and not `--link`: ``` docker network create digest-net docker run -d --name digest-redis --network digest-net redis:7 docker run -d --name digest-worker --network digest-net digest:1.4 ``` ## What isolation does and does not mean Two caveats keep coming up as follow-ups. First, attaching to your own network isolates you from containers on *other* networks; it does not firewall peers on the *same* network from each other — that needs inter-container communication disabled explicitly. Second, none of this changes port publishing: `-p 8080:4567` maps a host port the same way whichever bridge the container is on, so "it is on a private network" is not an argument that it is unreachable from outside the host. ## When the default bridge is fine Throwaway commands. `docker run --rm -it ruby:3.3-slim-bookworm irb` does not need a network of its own. The moment a second container has to find the first one by name, create a network.