The virtual networks in Docker are a secure and isolated communication channel that allows containers to exchange data with each other, with the host system, or with the outside world.
Your applications typically need connectivity. But in the case of Docker, these applications live inside isolated containers.
So in Docker, the network is not a physical cable, but rather a software component. In this post, we are going to learn how to use them.
Default Isolation
The first thing we need to remember is that a container is a sealed environment, isolated from your computer.
When you start a container, Docker assigns it:
- Its own network stack (Network Stack).
- Its own IP address (private and internal).
- Its own port range (from 1 to 65535).
This means if you have a container running Nginx on port 80, that port 80 belongs to the container.
It has nothing to do with port 80 on your computer (Host). In fact, your computer doesn’t even know that Nginx exists.
To break this isolation in a controlled way, Docker uses Network Drivers.
Network Drivers
Docker has several ways to connect these islands. Let’s look at the three fundamental ones that come standard and cover 95% of use cases.
| Driver | Isolation | Performance | Recommended Use |
|---|---|---|---|
| Bridge | 🟢 High (NAT) | 🟢 Good | Standard. 99% of your containers. |
| Host | ❌ None | 🟢 Native | Specific performance cases or complex network protocols. |
| None | 🟢 Total | ❌ N/A | Extreme security / Isolated jobs. |
This is the default mode. If you don’t specify anything, your container is born here.
Imagine a virtual Switch inside your computer. All containers connect to this switch.
- ✅ Among themselves: They can talk to each other if they know their IPs (or names, as we’ll see later).
- ✅ With the outside: They use your computer as a gateway (NAT) to access the Internet.
- ❌ From outside: No one can get in! They are protected behind the NAT.
It’s like your home WiFi network. Your devices have private IPs (192.168…) and access the internet through the Router. From the internet, no one can access your printer directly unless you configure the router.
This is the driver we will use almost always, combining it with port publishing (-p) to selectively allow traffic in.
This mode removes network isolation. The container shares directly the network card of your computer (Host).
If the container listens on port 80, it is occupying the real port 80 of your network card.
- Advantage: Maximum performance (no NAT or intermediate layers).
- Disadvantage: You can only run one container that uses a specific port. You cannot have two Nginx containers in host mode because they would both fight for port 80 on your PC.
docker run --network host nginx
The host driver works natively on Linux. On Docker Desktop for Windows and Mac, due to the intermediate virtual machine, this driver has limitations and does not work exactly the same (the port is not exposed directly to Windows).
As its name suggests: No network.
The container has a loopback interface (localhost) and that’s it. It has no network cable. It cannot access the internet, it cannot talk to other containers, and no one can talk to it.
What is it for? For maximum security tasks or batch processes that only need to process local files and we want to guarantee they do not leak data to the internet.
Seeing It in Practice
Let’s use our management commands to see what networks we have right now in our Docker. The command is:
docker network ls
You should see something like this:
NETWORK ID NAME DRIVER SCOPE
a1b2c3d4e5 bridge bridge local
f6g7h8i9j0 host host local
k1l2m3n4o5 none null local
There are the three we just explained. Docker creates them automatically upon installation.
Inspecting the Network
If you want to see the technical details of the bridge network (for example, what IP range it is using or what containers are connected to it), we use the inspect command:
docker network inspect bridge
This will return a huge JSON. Don’t be scared. Look for the "Containers" section. If you have any container running, you will see it there with its assigned internal IP (usually of the 172.17.0.x type).
The Bridge Driver Problem
The bridge driver is great because it protects our containers. But it has a problem: If they are protected, how do I see my webpage from the browser?
This is where the concept of Port Publishing (Port Forwarding) comes in, that famous -p 80:80 flag we have used without thinking. In the next article, we are going to understand what that command actually does.
