Docker Networking

When we run multiple containers, they need to talk to each other. A web app needs to reach its database. A backend needs to hit Redis. Docker networking is how we connect them.

Network types

Docker has four built-in network drivers:

• bridge — the default. Containers get their own IP on an internal network. Most common for single-host setups.
• host — removes network isolation. The container shares the host’s network directly. Fast, but no port isolation.
• none — no networking at all. The container is completely isolated.
• overlay — connects containers across multiple Docker hosts. Used in Docker Swarm and orchestration setups.

Default bridge vs custom bridge

When we run a container without specifying a network, it goes on the default bridge. This works, but it has a big limitation — containers can only reach each other by IP address, not by name.

Custom bridge networks solve this. They give us automatic DNS resolution — containers can find each other by name. This is what we almost always want.

# Create a custom bridge network
docker network create my-network

# Run containers on that network
docker run -d --name postgres --network my-network postgres:16-alpine
docker run -d --name web-app --network my-network -p 8080:3000 my-app

# web-app can now connect to postgres using the hostname "postgres"
# e.g., connection string: postgresql://user:pass@postgres:5432/mydb

Port mapping

Containers have their own network namespace. To make a container reachable from the host (or the internet), we map a host port to a container port using -p.

# Map host port 8080 → container port 3000
docker run -d -p 8080:3000 my-app

# Map to a specific interface (only localhost, not external)
docker run -d -p 127.0.0.1:8080:3000 my-app

# Map a random host port
docker run -d -p 3000 my-app
docker port <container-id>   # see which port was assigned

Container-to-container communication

On the same custom network, containers can talk to each other using their container name as the hostname. No port mapping needed — they communicate over the internal network directly.

On different networks, containers are completely isolated from each other. We can connect a container to multiple networks if it needs to talk to containers on different networks.

# Connect a running container to another network
docker network connect backend-network my-app

# Disconnect from a network
docker network disconnect frontend-network my-app

# List all networks
docker network ls

# Inspect a network (see which containers are on it)
docker network inspect my-network

When to use each type

• Custom bridge — 90% of the time. Multi-container apps on a single host. Use this as the default.
• Host — when we need maximum network performance and don’t care about port isolation. Common for monitoring tools.
• None — for containers that should have zero network access (batch jobs processing local files).
• Overlay — multi-host setups with Docker Swarm or when containers on different machines need to talk.