Docker Networking Explained: Bridge, Host, and Overlay Networks

How Docker Networking Works

Every container gets its own network namespace — it has its own network interfaces, IP address, and routing table, isolated from the host and other containers by default. Docker manages virtual networks that selectively connect containers to each other and to the outside world.

Understanding Docker's network drivers is essential for building multi-container applications that are both functional and secure.

The Four Built-In Network Drivers

1. Bridge (Default)

The bridge driver is the default for containers on a single host. Docker creates a virtual network interface (docker0) on the host; containers connect to it and can communicate with each other by IP.

# Run two containers on the default bridge network
docker run -d --name app1 nginx
docker run -d --name app2 nginx

# They can reach each other by IP but NOT by name on the default bridge
docker exec app1 ping 172.17.0.3

The limitation: containers on the default bridge can only reach each other by IP, not by name.

The solution: create a user-defined bridge network:

docker network create my-network

docker run -d --name api --network my-network my-api:latest
docker run -d --name db --network my-network postgres:16-alpine

# Now 'api' can reach 'db' by container name
docker exec api ping db

User-defined bridge networks provide automatic DNS resolution — containers find each other by service name. This is how Docker Compose networking works under the hood.

Inspecting a Network

docker network ls
docker network inspect my-network

2. Host

The host driver removes network isolation between the container and the Docker host. The container shares the host's network stack directly.

docker run -d --network host nginx
# nginx listens on host's port 80 directly — no -p mapping needed or possible

When to use it: high-performance applications where network overhead matters (e.g., certain monitoring agents, network scanners). Avoid it for regular web services — it bypasses all port isolation.

3. None

Completely disables networking for the container:

docker run --network none alpine sh

Useful for batch jobs that process local files and need no network access, reducing attack surface.

4. Overlay

The overlay driver connects containers across multiple Docker hosts (used in Docker Swarm). For single-host setups, bridge is sufficient.

Docker Compose Networking

Compose automatically creates a user-defined bridge network for your stack and connects all services to it. Services can reach each other by service name:

services:
  api:
    build: .
    ports:
      - "3000:3000"   # expose port 3000 to the host
    # api can reach 'db' at db:5432

  db:
    image: postgres:16-alpine
    # NOT exposed to host — only accessible within the Compose network

ports publishes to the host. Omitting ports keeps a service internal — the database is reachable by api but not from your laptop or the internet.

Connecting Containers on Different Compose Stacks

Use an external network to connect services from separate Compose files:

docker network create shared-network

# stack-a/docker-compose.yml
services:
  api:
    networks:
      - shared-network

networks:
  shared-network:
    external: true

# stack-b/docker-compose.yml
services:
  worker:
    networks:
      - shared-network

networks:
  shared-network:
    external: true

Isolating Networks for Security

Apply the principle of least privilege to networks — only connect services that need to talk to each other:

services:
  frontend:
    networks: [public]

  api:
    networks: [public, internal]

  db:
    networks: [internal]    # db is NOT on the public network

networks:
  public:
  internal:

The db service is completely unreachable from the frontend — even if the frontend container is compromised, it can't directly attack the database.

Port Mapping Reference

# Map host:container
docker run -p 8080:3000 my-app    # host 8080 → container 3000
docker run -p 127.0.0.1:3000:3000 my-app  # bind to localhost only
docker run -P my-app              # auto-map all EXPOSE'd ports to random host ports

Production Networking on PandaStack

When you deploy containerized applications on PandaStack, networking between your containers and managed services (PostgreSQL, MySQL, Redis, MongoDB) is handled by the platform — services communicate over a private internal network using connection strings injected as environment variables. You don't manage Docker networks in production; PandaStack does.

Install the CLI with npm install -g @pandastack/cli and read the deployment guide at [docs.pandastack.io](https://docs.pandastack.io). Manage your services from [dashboard.pandastack.io](https://dashboard.pandastack.io).