Connect Containers with Default Bridge

You've built your first Docker image, maybe even launched a few isolated containers. But a single container is just an island. The real power of Docker emerges when you connect containers together — for example, a web server talking to a database, or a microservice calling an API. Without a network, containers are blind to each other. The default bridge network is Docker's built-in, zero-config solution to let containers communicate by container name, solving the exact isolation pain that arises when you need two containers to talk on the same host.

The problem this lesson solves

Imagine you have a Node.js app container that needs to write to a PostgreSQL database container. You start both containers with docker run. They're both running, but the Node app can't reach localhost:5432 because that refers to its own container, not the database. The database isn't on the same network, so ping or curl fails. This is the fundamental challenge: containers are isolated by default. The default bridge network gives them a shared virtual LAN segment so they can discover each other by name and exchange data securely — without opening ports to the outside world.

Core concept / mental model

Think of Docker's default bridge network as a virtual switch inside your computer. Every container attached to it gets a private IP address (typically in the 172.17.0.0/16 range) and can talk to other containers on the same bridge using those IPs — or, more conveniently, using container names as hostnames.

💡 Pro Tip: The default bridge is created automatically when Docker Engine starts. It's named bridge and you can inspect it with docker network inspect bridge.

Key properties

• Automatic: No docker network create needed — it's there out of the box.
• Name resolution: While containers connected to the default bridge can communicate by IP, Docker's embedded DNS does not resolve container names on the default bridge for automatic discovery. You must use --link (deprecated) or better — attach containers to the same user-defined bridge. However, this lesson focuses on the default bridge, where you rely on IPs or published ports for connectivity.

Wait — this is a common point of confusion. Let's clarify: on the default bridge, containers can ping each other by IP, but not by container name automatically. This is a key limitation that we'll address in the Compare section. For now, understand that the default bridge is the simplest path to get two containers talking.

How it works step by step

1. Docker Engine starts — creates the default bridge network named bridge.
2. You run a container without specifying --network — Docker attaches it to the bridge network by default.
3. Each container gets a virtual Ethernet interface — an IP address from the bridge's subnet (e.g., 172.17.0.2).
4. Containers can reach each other — using those IPs, or by publishing ports to the host.
5. The host acts as a gateway — the docker0 interface (IP 172.17.0.1) forwards traffic between containers and the outside world.

Communication flow

Container A (web)  → 172.17.0.2:5000
Container B (db)   → 172.17.0.3:5432
Gate: 172.17.0.1   (host machine)

When Container A sends a packet to 172.17.0.3:5432, it goes out its virtual eth0 to the docker0 bridge, which forwards it to Container B's eth0. No external network needed.

Hands-on walkthrough

Let's make two containers talk. We'll use alpine for simplicity — one acts as a server, the other as a client.

Step 1: Start a container that listens

docker run -dit --name server alpine sh -c "while true; do echo 'Hello from server'; sleep 2; done"

Step 2: Get the server's IP on the default bridge

docker inspect server | grep IPAddress
# Output: "IPAddress": "172.17.0.2"

Step 3: Start a client container and ping the server by IP

docker run -it --name client alpine sh -c "ping -c 4 172.17.0.2"

You'll see successful replies:

PING 172.17.0.2 (172.17.0.2): 56 data bytes
64 bytes from 172.17.0.2: seq=0 ttl=64 time=0.123 ms
64 bytes from 172.17.0.2: seq=1 ttl=64 time=0.089 ms

Step 4: Try using the container name (fails on default bridge)

docker run -it --name client2 alpine sh -c "ping -c 2 server"

Expected output:

ping: bad address 'server'

Step 5: Use --link (deprecated but works on default bridge)

docker run -it --name client3 --link server alpine sh -c "ping -c 2 server"

Now it resolves. But --link is legacy — for production, use user-defined networks.

Compare options / when to choose what

When to choose the default bridge: - You just need two containers to communicate quickly for a one-off test. - You're following a simple tutorial and want minimal setup. - You're aware of the IP resolution limitation and are okay with using IPs or --link.

When to upgrade to a user-defined bridge: - You want automatic DNS resolution by container name. - You plan to detach and reattach containers (default bridge doesn't re-link IPs). - You need better isolation with your own subnet.

Troubleshooting & edge cases

Containers can't ping each other

• Check both are on the same network: docker inspect <container> | grep NetworkMode. If one is on host and the other on bridge, they won't talk.
• Firewall or iptables: Docker adds iptables rules, but custom rules might block inter-container traffic. Run iptables -L -n to inspect.
• IP change after restart: On the default bridge, IPs can change when containers restart. Always rely on IPs obtained fresh from docker inspect or move to user-defined networks.

"Cannot connect to the Docker daemon"

• Ensure Docker Engine is running: systemctl status docker (Linux) or check Docker Desktop.

Port publishing conflicts

• If two containers need the same host port (e.g., both want -p 80:80), only one can bind. Use different host ports like -p 8080:80.

What you learned & what's next

You now understand: - How the default bridge network lets containers communicate by IP. - The step-by-step process to create and test container-to-container connections. - The limitations of the default bridge (no automatic DNS) compared to user-defined networks. - How to troubleshoot common pitfalls.

Next step: Learn to create a user-defined bridge network — which gives you automatic DNS resolution, better isolation, and the ability to attach/detach containers dynamically. This is what you'll use in real multi-service applications.