Docker Networking: Bridging, Host, and Overlay

Hello, and welcome to this comprehensive tutorial on Docker networking. In this tutorial, I will explain three essential concepts: bridging, host, and overlay. By the end of this guide, you will learn what each type entails, why they’re essential, and how to use them effectively.

To learn more about Docker, please check Docker Tutorials page.

Understanding Docker Networking

Before we delve into the different types of Docker networking, it’s essential to understand what Docker networking is. Docker networking enables communication between docker containers and other systems. The networking features in Docker allow us to create a secure environment for our applications to interact and connect with each other seamlessly.

Bridging in Docker Networking

Bridging is the default network type when you install Docker. It’s also referred to as a user-defined bridge. When we create a new docker container without specifying any network, it gets connected to this default bridge network.

Let’s create a bridge network:

docker network create --driver bridge my_bridge_network

With this command, we’ve created a new bridge network named ‘my_bridge_network’. Any container that we start in this network can communicate with other containers in the same network.

Next, let’s run a Docker container in this network:

docker run -it --network=my_bridge_network ubuntu bash

This command starts a new container within the ‘my_bridge_network’. This container can now communicate with other containers within the same network.

Host in Docker Networking

In host networking, a container shares the network stack of the Docker host and can directly communicate without any isolation. This network mode is typically used when you want to run a network service in a container.

Let’s create a container with host networking:

docker run -it --network=host ubuntu bash

In this scenario, our container is directly using the host’s networking. It’s as if the processes running in the container are running on the host itself, from a networking perspective.

How is host networking different from bridging in Docker?

Understanding the distinction between host and bridge networking in Docker is crucial as you delve further into the world of Docker networking.

When we talk about bridge networking, it’s essentially a private network internal to the host, so your Docker containers are isolated and secure. It’s like your containers are living in their own secluded apartment complex, communicating with each other within that complex, but not with the outside world unless specified.

To give you an example, let’s say you have a Docker container running a web server on port 80. If you’re using a bridge network, that port 80 is only exposed to other containers connected to the same network. If you want to access it from outside the host or give access to the outside world, you would have to map the container’s port to the host’s port during container creation.

On the contrary, host networking removes the network isolation between the Docker host and the Docker containers to use the host’s networking directly. It’s as if your container moved out of its apartment complex and is now living freely in the city. In host networking, if a container exposes a port, it’s available on the host’s IP address without any need to map ports.

Let’s take the same example. If you have a Docker container running a web server on port 80, and you’re using host networking, then port 80 is exposed to the entire network that your Docker host is connected to. There’s no need to map any ports; it’s as if the service running in your container is running directly on the host itself.

In summary, bridge networking provides isolation and security to your Docker containers, while host networking provides ease of communication and less network latency by removing that isolation. The choice between the two would depend on the specific requirements of your application.

Overlay in Docker Networking

Overlay networks allow docker containers running on different hosts to communicate as if they were on the same host. This type of network is essential in swarm mode, where you have multiple Docker hosts running interconnected containers.

To create an overlay network, we first need to initialize Docker swarm:

docker swarm init

After initializing the swarm, we can create an overlay network:

docker network create -d overlay my_overlay_network

Now, any service that we create within this network can communicate with other services within the same network, even if they’re running on different Docker hosts.

For example, let’s create a new service within this network:

docker service create --network=my_overlay_network --name my_service nginx

In this scenario, our service ‘my_service’ is running within the ‘my_overlay_network’ and can communicate with other services within the same network.


Congratulations! You’ve learned the basics of Docker networking: bridging, host, and overlay. Understanding these concepts is vital for managing and scaling your Docker applications effectively.

However, this is just the beginning. Docker networking is a vast topic, and there’s much more to explore. So, keep experimenting, keep learning, and you’ll continue to enhance your Docker skills!