Understanding Container Networking: Bridges, Overlays, and Host Mode

How Containers Communicate

Containers need to talk to each other (app to database) and to the outside world (users to app). Container networking makes this possible through several modes.

Bridge Networking (Default)

The default mode creates a virtual network bridge on the host. Containers connect to this bridge and can communicate with each other using container names as hostnames.

When you run a web app and a database, both connect to the same bridge network. The web app reaches the database at db:5432 — the container name resolves to the container's IP on the bridge.

Port Mapping

To make a container accessible from outside the host, you map a host port to a container port. Port 80 on the host maps to port 3000 inside the container.

Host Networking

The container shares the host's network directly. No port mapping needed — the container listens directly on host ports. Better performance but less isolation.

Use for: Performance-critical applications, monitoring tools that need to see all host network traffic.

Overlay Networking

Spans multiple hosts, allowing containers on different servers to communicate as if they were on the same network. Used by Docker Swarm and Kubernetes.

Use for: Multi-server deployments, microservices across hosts.

DNS-Based Service Discovery

Modern container runtimes include built-in DNS. Containers on the same network can reach each other by name. No hardcoded IP addresses, no service discovery tools.

This is why Docker Compose is so powerful — define services by name and they automatically discover each other.

TinyPod Networking

TinyPod creates isolated Podman networks for each project. Services within a project communicate freely. Services across projects are isolated. Only services marked as public get a subdomain and external access.

This provides security (projects can't access each other) and convenience (services find each other automatically).