Custom Bridge Networks

When you run multiple containers with the default bridge network, they can only communicate by IP address—and they lack DNS-based service discovery. This creates fragile, hard-to-maintain connections that break when containers restart and get new IPs. Custom bridge networks solve this by giving you automatic DNS resolution, better isolation, and a clean way to link containers by service name.

The problem this lesson solves

Without a custom network, containers on the default bridge must use --link (deprecated) or hardcoded IPs to talk to each other. Every time a container restarts, its IP can change, breaking any connections that depended on it. This makes multi-container applications—like a web app talking to a database—unreliable.

Custom bridge networks replace this fragile approach with:

• Automatic DNS resolution – Containers can reach each other by container name (e.g., db or web).
• Better isolation – Containers on different custom networks cannot communicate unless explicitly connected.
• Cleaner configuration – No more --link flags or environment variable hacks.

Core concept / mental model

Think of a Docker network like a virtual switch. The default bridge network is a single, shared switch that every container joins automatically unless you specify otherwise. A custom bridge network is like creating your own dedicated switch—only containers you explicitly connect can join, and they can discover each other by name.

Key terms

• Bridge network – A software-based switch inside the Docker host. Containers attached to the same bridge can communicate.
• Custom bridge – A user-defined bridge network with automatic DNS resolution and scoped isolation.
• Default bridge – The built-in bridge network that all containers use by default. No automatic DNS.
• Container name resolution – Docker's built-in DNS server (127.0.0.11) resolves container names to IPs on the same custom network.

How it works step by step

1. Create the network – Use docker network create with a name. This allocates a subnet and gateway IP (default 172.x.x.x/16).
2. Run containers on the network – Pass --network mynet to docker run. The container gets an IP from that subnet.
3. Communicate by name – Inside any container on the same custom network, resolve another container by its name (or --name alias). No need to look up IPs.
4. Connect additional containers – Use docker network connect mynet existing-container to attach a running container.
5. Disconnect or remove – Detach with docker network disconnect or delete with docker network rm (all containers must be disconnected first).

Pro tip: When you create a custom network, Docker automatically starts a DNS server for that network. Containers use this DNS to resolve names without any extra configuration.

Hands-on walkthrough

Let's build a two-container application: a Redis server and a Python client that uses Redis. They'll communicate over a custom bridge network.

Step 1: Create the custom bridge network

docker network create my-redis-net

Verify it exists:

docker network ls
# Output (example):
# NETWORK ID     NAME           DRIVER    SCOPE
# a1b2c3d4e5f6   bridge         bridge    local
# g7h8i9j0k1l2   my-redis-net   bridge    local

Step 2: Run the Redis container on the new network

docker run -d --name redis-server --network my-redis-net redis:alpine

Step 3: Run a Python client container on the same network

Create a simple script to test connectivity:

# test_redis.py
import redis

r = redis.Redis(host='redis-server', port=6379, decode_responses=True)
r.set('message', 'Hello from custom bridge!')
print(r.get('message'))

Build and run the client container:

docker run -it --rm --name redis-client --network my-redis-net \
    -v $(pwd):/app python:3.10-slim sh -c "pip install redis && python /app/test_redis.py"

Expected output:

Hello from custom bridge!

Notice that the client resolved redis-server to the Redis container's IP automatically. If you run the same test on the default bridge network (without --network), it would fail with a name resolution error.

Step 4: Inspect the network

docker network inspect my-redis-net

Look for the Containers section—you'll see both redis-server and redis-client listed with their IPs on the 172.x.x.x subnet.

Compare options / when to choose what

When to choose custom bridge: Always pick a custom bridge when you have two or more containers that need to talk to each other by a stable name. It's the default for docker-compose projects as well.

Variations

• You can create networks with a specific subnet using --subnet 10.0.0.0/24 and --gateway 10.0.0.1.
• Use --ip-range to limit the DHCP pool for containers.
• Legacy --link still works but is deprecated—migrate to custom networks.

Troubleshooting & edge cases

Container can't reach another by name

Cause: The containers are on different networks. Fix: Connect both to the same custom network or use docker network connect to attach one container to the other's network.

docker network connect my-redis-net redis-client

Port conflicts when accessing published ports

Even on a custom network, containers can still publish ports with -p for host access. But internal communication over the network does not need port publishing—containers talk directly on the network's internal IP.

Network not found when running a container

Error: network my-net not found Fix: Create the network first with docker network create, or ensure the network name is spelled exactly (case-sensitive).

Containers restart and lose connectivity

Docker preserves the network assignment across container restarts—the container keeps its IP unless you explicitly disconnect. However, if you docker rm and recreate the container with the same name, it will get a different IP. But because you use name resolution (not IP), this works seamlessly.

I accidentally removed the network while containers are attached

Docker will warn you that containers still exist. Use docker rm -f to force remove the containers, then remove the network:

docker container rm -f redis-server redis-client
docker network rm my-redis-net

What you learned & what's next

You now understand how to create and use custom bridge networks in Docker. You know:

• How to create a custom bridge network with docker network create.
• How to run containers on that network using --network.
• How automatic DNS resolution lets containers find each other by name.
• When to use custom bridges vs default bridge vs host networking.

This is the foundation for connecting multi-container applications. In the next lesson, you'll learn how to link services together using Docker Compose, which builds on the same custom network concept but automates the wiring.