Table of Contents
Overview of Bridge Networks
Bridge networks are the default networking model that Docker uses on a single host. When you start Docker for the first time, it automatically creates a built in bridge network, usually called bridge. Any container you run without special network options gets attached to this default bridge.
A bridge network acts like a private, internal network on your machine. Containers connected to the same bridge can communicate with each other using IP addresses that exist only inside that bridge. From the host point of view it is just a virtual network adapter. From the container point of view it looks like a normal network interface that can reach other containers and the outside world.
Bridge networks are only relevant to containers that run on the same Docker host. They do not cross machine boundaries. If you need multi host networking, that belongs to more advanced topics that are covered elsewhere.
Bridge networks provide a private, isolated network per Docker host. Containers on the same bridge can talk to each other directly. Containers on different bridge networks, or on different hosts, cannot communicate unless you explicitly configure it.
The Default Bridge Network
When Docker is installed it creates a default bridge network, commonly named bridge. If you start a simple container without specifying any network, Docker attaches it to this default network.
On this default bridge, each container receives a private IP address from a range that Docker manages. These addresses usually start with something like 172.17.x.x, but the exact range can vary depending on your system configuration.
Communication between containers on the default bridge is possible, but it has limitations. By default, Docker does not provide simple container name based DNS for containers on this built in bridge. That means containers on the default bridge usually have to talk to each other using IP addresses instead of stable names. Since IP addresses can change when containers are recreated, this quickly becomes uncomfortable for anything beyond quick experiments.
Because of these limitations, for most real applications you will use user defined bridge networks rather than the default one. The default bridge is suitable for simple tests, one off containers, or very small setups where you control all container lifecycles manually.
If you do not specify a network when running a container, Docker attaches it to the default bridge network, which offers limited name resolution and is not ideal for larger setups.
User Defined Bridge Networks
User defined bridge networks are custom bridge networks that you create yourself. They behave similarly to the default bridge, but Docker adds important extra features that make them much more useful in real projects.
When you create a user defined bridge network, Docker allocates a separate IP range for it and provides automatic DNS based name resolution for containers attached to that network. This means containers can reach each other using the container name, which is much more stable and human friendly than using IP addresses.
A user defined bridge network also improves isolation. Different applications or stacks can each have their own private bridge network. Containers in one bridge network cannot directly talk to containers in another bridge network unless you explicitly connect a container to both. This separation reduces accidental interference between different projects on the same host.
User defined bridge networks are also easier to reason about. Each network has its own set of containers, its own addressing range, and its own rules. You can inspect these networks to see what is connected and how Docker configured them.
For applications with multiple containers, always prefer user defined bridge networks. They provide:
- Automatic container name resolution.
- Better isolation between projects.
- A clearer view of which containers belong together.
How Containers Communicate on a Bridge Network
On a bridge network, Docker creates a virtual Ethernet interface for each container and connects it to the virtual bridge. Each container receives an IP address on that network. The host has an interface that is also attached to this bridge, which allows the host to reach the containers directly via the bridge IPs.
When one container sends traffic to another container on the same bridge network, the packets never leave the host machine. They travel only inside that virtual network and are switched by the bridge. This keeps the traffic local and avoids exposing it to the outside world by default.
On user defined bridge networks, containers usually communicate using each other’s names. Docker runs a small internal DNS service that maps these names to container IP addresses inside the same network. If you recreate a container and it receives a new IP address, Docker automatically updates this internal mapping so that other containers can still find it using the same name.
From the container perspective, the default route typically points to the bridge gateway IP on that internal network. When a container connects to the internet, the packets go to the virtual gateway on the bridge, then Docker performs Network Address Translation on the host so that the outside world sees the host’s IP, not the container’s private address.
On a bridge network, container names resolve to IP addresses only within the same user defined bridge. Name based communication works per network, not globally across all containers.
Isolation and Security Behavior
Bridge networks provide a basic level of isolation by placing containers into private IP ranges that are not directly reachable from outside the host. External clients cannot talk to a container on a bridge network unless you explicitly expose ports using the appropriate Docker options, which are covered in the port mapping section.
Different user defined bridge networks on the same host are isolated from each other. Traffic does not pass between them automatically. If a container should act as a kind of gateway between two such networks, you would deliberately attach it to both networks and configure routing or application level forwarding yourself.
The Linux firewall and NAT rules that Docker sets up on the host control how containers on bridge networks can reach the outside world and how the outside world can reach them. For most setups you do not need to modify these rules manually, but it is useful to know that this machinery exists and is entirely under Docker’s control as long as you use the Dockersupported networking features.
Bridge networks are not a strong security boundary on their own. They help with segmentation and reduce accidental exposure, but they are still part of the same kernel and network stack. For strict isolation requirements you would combine bridge networks with other security mechanisms that are discussed separately in the security part of this course.
Bridge networks limit exposure but do not replace security hardening. Assume that containers on the same bridge can reach each other freely unless you impose additional controls.
Default vs User Defined Bridge in Practice
In practice, you will often see two common patterns. For quick tests or running a single throwaway container, people rely on the default bridge network without thinking about it. For any meaningful application that needs multiple containers, teams define at least one dedicated bridge network and attach the relevant containers to it.
Using a user defined bridge makes the application topology clearer. You can inspect the network to see which containers belong to that application. When you remove the application containers, you can also remove the network to clean up. This avoids the situation where the default bridge slowly fills with containers and old network entries from many unrelated experiments.
Many orchestration tools and configurations, including Docker Compose which is covered later, use user defined bridge networks behind the scenes. When you see containers able to talk to each other using names like web or db on a single host, that is almost always powered by a user defined bridge network.
Treat the default bridge as a generic playground and user defined bridges as dedicated networks per project or stack. This habit keeps your Docker host organized and predictable.
Summary
Bridge networks are the foundational networking mode for Docker on a single machine. Every time you run a container without any special network configuration, you are relying on a bridge. The default bridge network is created automatically, but user defined bridge networks give you more features, clearer application boundaries, and easier service discovery through container names.
Understanding how bridge networks group containers, how they enable private communication, and how they interact with port mapping prepares you for more advanced networking patterns that you will encounter in later chapters.