Docker Network

Docker hub

A virtual network that Docker creates to enable communication between containers and between containers and the host. Docker provides several network drivers (bridge, host, overlay, none) for different connectivity requirements.

Docker Network — How Containers Connect

What Is a Docker Network in Simple Terms?

A Docker network is a virtual network that exists only in software — Docker creates it on top of the host's real network. Containers connected to the same Docker network can talk to each other. Containers on different networks cannot, unless explicitly connected to both.

Every time you start Docker, three default networks are created automatically: bridge (the default), host (uses host network directly), and none (no networking).

◈ DIAGRAM

+------------------------------------------+
| Docker Host                              |
|                                          |
|  Network: payment-network               |
|  +----------+    +----------+           |
|  | api      |----|  postgres |           |
|  | .0.2     |    | .0.3     |           |
|  +----------+    +----------+           |
|                                          |
|  Network: monitoring-network            |
|  +----------+    +----------+           |
|  | api      |----|prometheus |           |
|  | .1.2     |    | .1.3     |           |
|  +----------+    +----------+           |
|                                          |
|  api is on BOTH networks                 |
|  postgres cannot reach prometheus        |
|  (different networks = no communication) |
+------------------------------------------+

Managing Docker Networks

Bash

# List all networks
docker network ls
# NETWORK ID     NAME              DRIVER    SCOPE
# a84f9c2b1d3e   bridge            bridge    local  <- default
# b72c8a9f4e1d   host              host      local
# c91d8b3f2a5e   none              null      local
 
# Create a user-defined network
docker network create payment-network
docker network create --driver bridge --subnet 172.20.0.0/16 payment-network
 
# Connect a container to a network at run time
docker run -d --name api --network payment-network myapp:latest
 
# Connect a running container to another network
docker network connect monitoring-network api
# api is now on both networks
 
# Disconnect a container from a network
docker network disconnect payment-network old-container
 
# Inspect a network — see subnet, gateway, connected containers
docker network inspect payment-network
 
# Remove a network (containers must be disconnected first)
docker network rm payment-network
 
# Remove all unused networks
docker network prune

Network Drivers

Driver	Use Case	Key Characteristic
bridge	Single-host apps (default)	Private network, NAT to outside
host	Performance-critical tools	No isolation, uses host IPs directly
overlay	Multi-host Docker Swarm	Spans multiple Docker hosts
none	Complete isolation	No network access at all

Networks in Docker Compose

YAML

version: "3.8"
services:
  api:
    networks:
      - payment-network
      - monitoring-network
  postgres:
    networks:
      - payment-network
  prometheus:
    networks:
      - monitoring-network
 
networks:
  payment-network:
  monitoring-network:
# api can reach both postgres and prometheus
# postgres and prometheus cannot reach each other

Tip
Always create named user-defined networks for your applications instead of relying on the default bridge. User-defined networks provide automatic DNS (containers find each other by name), better isolation, and clear documentation of which services should communicate.

Common Mistake
Assuming containers on the same host can always communicate. They can only communicate if they are on the same Docker network. Two containers on the default bridge network cannot find each other by name — only by IP address.

Frequently Asked Questions

What's actually different between the bridge, host, and overlay network drivers?

Bridge (the default for standalone containers) creates an isolated virtual network on a single host with NAT to the outside world. Host mode removes network isolation entirely — the container shares the host's network namespace directly, which is faster but means no port mapping and no isolation from other host processes. Overlay extends a virtual network across multiple Docker hosts, encapsulating traffic so containers on different machines reach each other by IP as if on one LAN — the backbone of Docker Swarm's multi-host networking.

When would you deliberately choose host networking despite losing isolation?

Mainly for performance-sensitive workloads where the NAT translation overhead of bridge networking measurably matters, or for tools that genuinely need to see the host's real network interfaces (some monitoring agents, VPN clients). The tradeoff is real: host mode means a container can bind to any port on the host and there's no per-container network namespace protecting against port collisions, so it's a deliberate, narrow-use choice, not a default.