How do user-defined bridge networks improve on the default bridge network?
Quick Answer
User-defined bridge networks add three things the default bridge lacks: automatic DNS-based service discovery by container name, better isolation (only containers attached to the same network can reach each other, so you can segment an app into logical groups), and the ability to connect or disconnect a running container from a network without restarting it. This is why Docker's own guidance — and Compose's default behavior — is to always use a user-defined network instead of the default bridge.
Detailed Answer
This question builds on the earlier default-bridge question. Here's a fuller comparison, focused on what user-defined networks add.
Capability comparison
| Default bridge | User-defined bridge | |
|---|---|---|
| Containers reachable by IP | Yes | Yes |
| Containers reachable by name (DNS) | No | Yes |
| Can create multiple isolated networks | No (one shared default) | Yes (create as many as needed) |
| Dynamically connect/disconnect a running container | Limited | Yes, freely |
| Used automatically by Docker Compose | No | Yes (Compose creates one per project) |
Isolation and segmentation via multiple networks
docker network create frontend-net
docker network create backend-net
docker run -d --network frontend-net --name web nginx
docker run -d --network backend-net --name db postgres:16
docker run -d --network frontend-net --name api myapi:1.0
docker network connect backend-net api # api bridges BOTH networks
web has no path to reach db at all — they're on different networks with no shared connectivity. Only api, deliberately connected to both frontend-net and backend-net, can bridge between them. This is a real, deliberate isolation tool: you decide which containers can even see which others, instead of everything sharing one flat network like the default bridge does.
Dynamic network membership
docker network connect my-network already-running-container
docker network disconnect my-network already-running-container
A container can join or leave a user-defined network while it's still running, with no need to stop and recreate it. This is useful for reconfiguring connectivity on the fly — for example, temporarily attaching a debugging container to a production network segment for a one-off check, then detaching it afterward. The default bridge doesn't offer this flexibility.
Why Compose's automatic behavior reinforces this as standard practice
services:
web:
image: nginx
api:
image: myapi:1.0
docker compose up
# Creates a network named "<project-name>_default" automatically,
# and attaches both "web" and "api" to it -- giving them DNS-based
# discovery of each other by service name with ZERO explicit
# network configuration required.
Compose is by far the most common way people run multi-container Docker setups locally. It does this automatically, by default, for every project — a strong sign the ecosystem has settled on "always use a user-defined network, never the default bridge" as the correct baseline.