Docker Networking Overview

You’ve already seen how Docker handles data — containers are ephemeral by nature, so you reach for bind mounts or volumes when you need something to survive a restart. Networking has a similar story. By default, Docker gives every container just enough connectivity to talk to the internet, but the moment your setup involves more than one container — say, an app talking to a database — you start running into questions Docker’s defaults don’t answer cleanly. Which network should they share? Can they find each other by name? Should the outside world even be able to reach them?

This section walks through Docker’s core networking drivers — how they work, when to use each one, and where they fall short — with real-world examples along the way instead of just theory.

Why Container Networking Needs Its Own Model

A regular process on your machine just uses the host’s network stack — it binds to a port, and it’s reachable. Containers can’t work quite the same way, because you might be running dozens of them, and they can’t all fight over the same ports on the same host interface.

So Docker gives each container its own network namespace by default — its own virtual interface, its own IP, its own routing table — and then uses network drivers to decide how that isolated namespace connects to everything else: other containers, the host, and the outside world.

That single design decision is what the rest of this section is really about.

Docker Network Drivers at a Glance

Docker ships with a handful of built-in drivers. You’ll use some of these daily and others only in edge cases, but it’s worth knowing the full lineup before we go deep on any one of them.

Driver	Isolation	Typical Use Case
`bridge` (default)	Containers isolated on a private internal network	Default for standalone containers
`bridge` (user-defined)	Same as above, plus DNS-based discovery	Multi-container apps on a single host
`host`	None — container shares the host’s network stack	Performance-sensitive or low-level networking tools
`none`	Total — no network access at all	Security-sensitive, offline, or batch jobs
`overlay`	Spans multiple Docker hosts	Swarm/cluster setups (out of scope here)
`macvlan`	Container gets its own MAC address on the physical network	Legacy apps expecting a real LAN presence (out of scope here)

Note

This section focuses on bridge, host, and none — the three drivers you’ll actually touch on a single Docker host. overlay and macvlan are multi-host / physical-network topics that deserve their own dedicated coverage later.

Here’s roughly how those three sit relative to the host, in terms of isolation:

    flowchart TB
    subgraph Host["Docker Host"]
        subgraph Bridge["bridge network"]
            C1["Container A"]
            C2["Container B"]
        end
        C3["Container C\n(host network)"]
        C4["Container D\n(none network)"]
    end
    Internet((Internet))

    Bridge -- NAT --> Internet
    C3 -- shares host stack --> Internet
    C4 -.no access.-x Internet

Notice container D isn’t even trying to reach the internet — that’s the whole point of none, and we’ll get to why that’s actually useful.

How This Section Is Organized

We’ll go driver by driver, and for the two you’ll actually use in practice — bridge and host — we’ll follow up the theory with a dedicated real-world example:

Default Bridge Network — what you get out of the box, and where it quietly falls short
User-Defined Bridge Network — the fix for that shortfall, and how containers find each other by name
Real-World Example: Bridge Network — a small multi-container app, built from a concrete problem statement
Host Network — dropping isolation for raw performance
Real-World Example: Host Network — a case where that trade-off actually makes sense
None Network — when no network is the correct answer
Managing Docker Networks — the lifecycle commands: create, inspect, connect, disconnect, prune

By the end, you won’t just know what docker network create does — you’ll know which driver to reach for when a real problem lands on your desk.

What’s Next

Next up: the network every container gets whether you ask for it or not — the default bridge — and the one limitation of it that trips up almost everyone the first time they try to run two containers that need to talk to each other.

Last updated on August 12, 2026

Default Bridge Network