How do user-defined bridge networks improve on the default bridge network?
Quick Answer
User-defined bridge networks provide automatic DNS-based service discovery by container name (which the default bridge lacks entirely), better isolation (only containers explicitly attached to a given network can reach each other, letting you segment an application into logical groups), and the ability to dynamically connect or disconnect a running container from a network without restarting it. This is why Docker's own guidance — and Compose's automatic default behavior — is to always use a user-defined network rather than relying on the default bridge for any real multi-container setup.
Detailed Answer
This question directly builds on the earlier default-bridge question — here's a fuller comparison, focused specifically 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
This setup gives web no path to reach db directly at all (different networks, no shared connectivity) — only api, deliberately connected to both frontend-net and backend-net, can bridge between them. This is a genuine, deliberate isolation and segmentation tool. You can architect which containers are allowed to even see which others, rather than everything sharing one flat, undifferentiated network the way the single default bridge works.
Dynamic network membership
docker network connect my-network already-running-container
docker network disconnect my-network already-running-container
A container can be attached to or detached from a user-defined network while it's still running, without needing 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 diagnostic session, then detaching it afterward. It's a flexibility the default bridge doesn't offer in the same way.
Why Compose's automatic behavior reinforces this as the 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 the most common way people run multi-container Docker setups locally, by a wide margin. The fact that it does this automatically, by default, for every project, reflects just how strongly the ecosystem has converged on "always use a user-defined network, never the default bridge" as the correct baseline practice.