Lesson 9 of 30

Docker Networking: Drivers & Isolation

Q: A teammate says their container 'can't see' a database server running on their own laptop, even though the same connection string works fine when they run the app outside Docker. Walk through why, and how you'd fix it.

A strong answer covers: Identifies that the default bridge network gives the container its own network namespace, so `localhost` inside the container refers to the container itself, not the host machine; Names a concrete fix: using the host's reachable address from inside the container (e.g. `host.docker.internal` on Docker Desktop, or the bridge gateway IP), not `localhost`; Distinguishes this from a firewall or credentials problem — correctly diagnoses it as a network-namespace addressing issue, not a connectivity or auth failure; Can articulate why this is different from container-to-container communication on a Compose network, where service names resolve automatically.

Compose's service-name DNS feels like magic until you know what it's built on — a specific network driver, chosen from a small set of options, each with a genuinely different isolation model.

12 min read

Check your understanding

Every option explains itself — why the right one is right, and why each wrong one is wrong. Miss one and it comes back later on a spaced-repetition schedule.

Question 1 of 3

A container is run with `--network host`. What happens to `-p 3000:3000` on that same command?

It's meaningless — the container already shares the host's network stack directly, with no boundary to map acrossIt makes the container additionally reachable on a second, isolated port 3000Docker rejects the command, since `-p` and `--network host` are mutually exclusive flagsIt restricts the container to only accepting traffic on port 3000

Stuck? Ask the AI tutor

Hints without spoilers, and a plain explanation of why a wrong answer was wrong — answered only from this lesson. Free account, no card.

Interview questions on Docker Networking: Drivers & Isolation

What interviewers actually ask about this, and what a strong answer has to cover.

A teammate says their container 'can't see' a database server running on their own laptop, even though the same connection string works fine when they run the app outside Docker. Walk through why, and how you'd fix it.

A strong answer covers

Identifies that the default bridge network gives the container its own network namespace, so `localhost` inside the container refers to the container itself, not the host machine
Names a concrete fix: using the host's reachable address from inside the container (e.g. `host.docker.internal` on Docker Desktop, or the bridge gateway IP), not `localhost`
Distinguishes this from a firewall or credentials problem — correctly diagnoses it as a network-namespace addressing issue, not a connectivity or auth failure
Can articulate why this is different from container-to-container communication on a Compose network, where service names resolve automatically

Likely follow-ups

If they just ran the same container with `--network host` instead, would that fix it — and what would they be giving up to get that fix?
How would the answer change if the database were another container on the same Compose file instead of a process running directly on the host?

The plain-language idea

Every container gets attached to a network, and which driver that network uses decides what the container can actually reach — this is the layer underneath Compose's automatic service-name DNS from the earlier lesson, not a replacement for it. Docker ships four drivers that matter for a working developer:

bridge — the default. Docker creates a private, isolated virtual network on the host; containers on it get their own IP and can reach each other, but nothing outside that bridge can see in, and the container can't see the host's other processes either.
host — no isolation at all. The container shares the host machine's network stack directly — no virtual network, no port mapping needed, localhost inside the container is the host's localhost.
none — no networking whatsoever. The container is fully isolated, useful for pure computation with zero network surface.
overlay — spans multiple Docker hosts, stitching containers on different machines into one virtual network. This is what Swarm (and similar multi-host setups) uses; a single-host bridge network can't do this at all.

Isolation is the concrete, specific idea underneath all four: a bridge-network container has its own network namespace, so localhost inside it refers only to itself, never to the host machine or to a dev server running on the host's port 3000. This is exactly why the Compose lesson called out localhost as a trap — that trap is bridge-mode isolation working correctly, not a bug.

See it in a real thing: the same container, two modes

# bridge (default): isolated network, needs explicit port mapping to reach it
docker run -d -p 3000:3000 myapp:dev

# host: no isolation, no mapping needed — and no isolation from anything else either
docker run -d --network host myapp:dev

Bridge isolates. Host doesn't.Step 1 of 3

The same container, run two different ways — watch what it can reach change.

In bridge mode, -p 3000:3000 exists because the container is isolated — Docker has to explicitly forward the host's port 3000 into the container's own private network for anything outside to reach it. In host mode, that flag is meaningless: the container is already listening directly on the host's own network stack, so a host-machine process on port 3000 and a --network host container trying to bind port 3000 will collide, because they're not actually separate anymore.

What people usually miss

Watch out

A bridge-network container reaching a host-machine dev server needs the host's actual address, not localhost. host.docker.internal (on Docker Desktop) or the bridge gateway IP is the real answer — localhost:3000 inside a bridge container never reaches a server running on the host's own port 3000, no matter how obvious it feels that it should.
none isn't a niche option — it's the correct choice whenever a container has no legitimate reason to touch a network at all, minimizing attack surface for something like an offline batch job.
Overlay networks solve a problem bridge networks structurally cannot — bridge is scoped to one Docker host by design, so multi-host container communication needs a driver built for it, not a bigger bridge.
Custom bridge networks (not the default one) are what give containers DNS-by-name. Docker's automatic service-name resolution — the mechanism Compose relies on — only works on a user-defined bridge network; containers on the original default bridge network can only reach each other by IP.

Why this matters in interviews

"Why can't my container reach localhost:5432 on my machine?" is one of the most commonly actually hit Docker bugs, and answering it well means naming the mechanism — bridge-mode network namespace isolation — rather than guessing at a firewall or a typo. It's also the natural follow-up to any Compose question, since Compose's service-name DNS is this driver model with the isolation problem already solved for you.