Network Drivers: Bridge, Host & None

In one line

Docker gives you three fundamentally different ways to wire up a container's networking — picking the right one is a five-second decision once you know what each one actually does.

0/3 · 0%

Think of it like this

BRIDGE is like an apartment building with its own internal phone extension system — each apartment (container) has a private extension, and a receptionist (Docker's network) routes calls in and out. HOST is like giving a tenant a direct outside line with no receptionist at all — they share the building's actual main line directly. NONE is like a room with no phone whatsoever.

Key ideas

01
BRIDGE (the default): Docker creates a private, isolated virtual network on your host. Every container gets its own internal IP address on this network and can reach other containers on the SAME bridge network by their container name (Docker's built-in DNS resolves names to IPs automatically). This is what you use for the vast majority of real work.
02
HOST: the container shares the host machine's network stack directly — no isolation, no port mapping needed (a container listening on port 8080 IS listening on your host's port 8080 directly). Faster (no network address translation overhead) but no isolation, and you lose the ability to run multiple containers on the same port.
03
NONE: the container gets no network interface at all beyond a loopback — completely isolated, useful for pure batch-processing tasks that only touch local files and need zero network access whatsoever, for security or simplicity.
04
The default bridge network (literally named bridge) has a limitation worth knowing: containers on it CANNOT resolve each other by NAME, only by IP — which is inconvenient and a common source of 'why can't my containers talk to each other' confusion. The FIX is creating your OWN user-defined bridge network, which DOES support automatic name-based DNS resolution between containers on it.
05
docker network ls lists all networks. docker network create mynetwork creates a user-defined bridge network. docker run --network mynetwork ... attaches a container to it at creation time. docker network inspect mynetwork shows exactly which containers are attached and their IPs.

In your stack

→
A typical real setup: a user-defined bridge network containing a Postgres container (named db) and a Spring Boot container. The Spring Boot app's application.properties sets spring.datasource.url=jdbc:postgresql://db:5432/mydb — using the container NAME db as the hostname, which only resolves correctly because both containers share a user-defined bridge network, not the default one.

Code & diagrams

user-defined-bridge.shmarkdown

The fix for 'my containers can't find each other by name.'

# Create your own bridge network (NOT the default "bridge")
docker network create mynetwork

# Run Postgres attached to it, named "db"
docker run -d --name db --network mynetwork -e POSTGRES_PASSWORD=secret postgres:16

# Run your app attached to the SAME network — it can now reach Postgres by NAME
docker run -d --name myapp --network mynetwork \
  -e SPRING_DATASOURCE_URL=jdbc:postgresql://db:5432/postgres \
  myapp:v1

# Proof: exec into myapp and ping "db" by name — this only works on a user-defined network
docker exec myapp ping -c 2 db

# Inspect the network to see both containers listed with their IPs
docker network inspect mynetwork

NetworkDriversdiagram

Three drivers, three very different isolation stories.

Rendering diagram…

Explain it without notes

Why can't two containers on Docker's DEFAULT bridge network reach each other by container name, while two containers on a USER-DEFINED bridge network can?

Why would you choose --network host for a specific container, and what do you explicitly give up by doing so?

Practice

Reproduce this topic's user-defined-bridge exercise, and then try the SAME ping command between two containers on the DEFAULT bridge network (no --network flag) — confirm it fails by name but works by IP.

Run a container with --network none and confirm it has no usable network interface (try to curl anything from inside it).

Trade-offs

↔
User-defined bridge networks cost nothing extra to set up (one extra docker network create command) and solve a real, common problem — there's essentially no reason to ever rely on the default bridge network for a multi-container setup once you know this.

Done when you can

I always create a user-defined bridge network for any multi-container setup.
I can explain why the default bridge network doesn't support name-based resolution.
I know what host and none networking modes trade away.

Command Palette