How do containers talk to each other?

Put them on the same user-defined bridge network. Containers on the same network can reach each other by container name — Docker provides automatic DNS resolution.

What is the difference between bridge, host, and none networks?

Bridge is an isolated virtual network — the default. Host removes isolation and shares the host network stack directly. None disables all networking for maximum isolation.

Why can't I reach localhost from inside a container?

Inside a container, localhost refers to the container itself, not your host. Use host.docker.internal (Docker Desktop) or the host's docker0 IP (172.17.0.1 on Linux) to reach services on the host.

Docker Networking | SkillByExample

Network Drivers

Docker ships with several network drivers:

Driver	Use case
`bridge`	Default — isolated network per host, containers communicate by name
`host`	No isolation — container shares host’s network stack
`none`	No networking — fully isolated container
`overlay`	Multi-host networking for Docker Swarm
`macvlan`	Assign a real MAC address — container appears as physical device on network

Bridge Networks

The default bridge network works, but user-defined bridge networks are better: they support DNS resolution by container name.

# Create a user-defined bridge network
docker network create my-network

# Run containers on the same network
docker run -d --name db --network my-network postgres:15
docker run -d --name api --network my-network myapi:1.0

# Inside 'api', reach 'db' by name:
# postgresql://db:5432/mydb   ← 'db' resolves automatically

# List networks
docker network ls

# Inspect a network (see connected containers, subnet, gateway)
docker network inspect my-network

# Connect a running container to a network
docker network connect my-network my-container

# Disconnect
docker network disconnect my-network my-container

# Remove unused networks
docker network prune

Host Network

Bypasses container network isolation — the container sees all of the host’s interfaces:

docker run --rm --network host nginx
# nginx listens directly on host port 80, no -p mapping needed

Useful for performance-sensitive apps or when you need the container to bind to a specific host interface. Not available on Docker Desktop (Mac/Windows) — only Linux.

Container-to-Container Communication

Same network (recommended)

docker network create app-net
docker run -d --name redis --network app-net redis:7
docker run -d --name worker --network app-net myworker:1.0
# worker connects to redis at: redis://redis:6379

Reaching the host from a container

# Docker Desktop (Mac/Windows)
curl http://host.docker.internal:8080

# Linux — use the docker0 gateway IP
ip addr show docker0   # usually 172.17.0.1
curl http://172.17.0.1:8080

DNS and Service Discovery

User-defined bridge networks have a built-in DNS server. Container names and network aliases resolve automatically:

docker run -d \
  --name postgres \
  --network-alias db \       # alternative name
  --network app-net \
  postgres:15

# Other containers on app-net can reach it as 'postgres' or 'db'

Port Publishing

# Publish on all interfaces (default)
docker run -p 8080:80 nginx           # 0.0.0.0:8080 → container:80

# Publish on localhost only (more secure)
docker run -p 127.0.0.1:8080:80 nginx

# Publish all EXPOSE'd ports to random host ports
docker run -P nginx

# Check published ports
docker port my-container

Practical Example: API + Database

docker network create backend

docker run -d \
  --name postgres \
  --network backend \
  -e POSTGRES_PASSWORD=secret \
  postgres:15

docker run -d \
  --name api \
  --network backend \
  -p 3000:3000 \
  -e DATABASE_URL=postgresql://postgres:secret@postgres:5432/mydb \
  myapi:1.0

# api connects to postgres using the container name 'postgres' as the hostname