Table of Contents
Why Create Custom Networks
Custom Docker networks let you design how containers see and reach each other instead of relying only on the default bridge network. With a custom network, you can control isolation, assign readable hostnames, group related services, and prepare configurations that behave more like real production setups.
On the default bridge network, containers can communicate, but you have less control over naming, reachability, and isolation between groups of containers. Custom networks solve this by letting you create distinct network environments that you explicitly attach containers to.
Custom networks give you control over which containers can talk to each other. Only containers on the same user defined network can use container names as hostnames to connect.
Types of Custom Networks
Docker supports several network drivers, but for most beginners, the key one is the user defined bridge network. It behaves similarly to the default bridge network, but with more predictable DNS and isolation.
User defined bridge networks provide automatic DNS based on container names, and they keep containers isolated from other networks unless you explicitly connect them. There are other drivers like host or none, and specialized ones for clustering, but those belong to more advanced topics outside this chapter.
When you create a custom bridge network, Docker assigns it its own IP subnet and gateway. Each container attached to this network receives an IP inside that subnet, and Docker provides name resolution so that containers can reach each other by name instead of IP.
Creating a Custom Network
To start using a custom network, you first create it before starting containers or you attach existing containers to it. You specify a name and optionally a driver and other settings if you need them.
The usual process is to create a user defined bridge network with a simple command. Once created, this network persists until you remove it, even if no containers are attached. Containers can be started with an option that directly attaches them to that network so they join the same isolated environment.
You can create multiple custom networks, for example one for frontend services and another for backend services, and attach containers to one or more of them according to your design. This separation helps you reason about what can communicate and what should be kept apart.
Connecting Containers to Custom Networks
When you run a container, you can choose the network it belongs to. Containers on the same custom network can talk to each other using their container names as hostnames, which removes the need to track IP addresses.
Inside a container attached to a custom network, using a client library or command line tool that connects over TCP to another container on the same network usually just needs the other container's name and port. This feels similar to connecting to a service by hostname in a traditional network.
If a container should be reachable from multiple groups of services, you can connect it to more than one network. This is useful for things like a shared logging container that several application networks should reach, or a reverse proxy that needs to see both public facing and internal services.
You can also connect or disconnect containers from networks after they are already running. This lets you adjust the network design over time, move services between environments, or temporarily isolate a container for debugging.
Name Resolution and Service Discovery
Custom bridge networks provide built in DNS that resolves container names to their IP addresses. This means that once two containers share the same network, they can communicate as if the other container were a normal host in a private network, using clear names instead of raw IPs.
The internal DNS updates as containers start and stop, so name resolution reflects the current state. This built in service discovery is one of the main benefits of using custom networks instead of ad hoc linking or manual IP management.
If you restart a container, it may get a new IP, but as long as other containers use its name, connections still work. This behavior encourages you to design communication around stable service names rather than addresses, which aligns well with container based deployments.
Isolating Application Components
Custom networks are a simple way to isolate components of an application within the same Docker host. Suppose you have a database container and an application container that need to talk to each other, but you do not want other random containers to reach the database. Placing them on a dedicated network provides a basic level of isolation.
A container not attached to that network cannot reach services inside it using the internal IP space or names, even if it exists on the same Docker host. You control membership explicitly, which helps reduce unintended access paths between containers.
For more complex setups, you can design several networks and allocate containers like building blocks. For example, you might create a public network for services exposed to the outside world, and a private network that only backend components share. Containers that must bridge the two can be connected to both networks and act as controlled gateways.
Inspecting and Managing Custom Networks
Once you work with several networks, it becomes important to understand how to inspect them and see which containers belong where. Docker offers ways to query network configuration and membership so you can verify your design.
Inspecting a network shows its driver, subnet, gateway, and the list of attached containers along with their IP addresses. This information helps you confirm that containers actually join the networks you intended and helps during troubleshooting connectivity issues.
You can remove a custom network when you no longer need it, but only after all containers have been detached. If a network still has containers attached, you must disconnect or remove those containers first. This safeguard avoids accidentally breaking live communication while services are running.
Use Cases for Custom Networks
Custom networks are especially helpful in small multi container setups that mimic real applications. A typical pattern is to place a web application and its database on a private network. The database is only reachable from within that network, while the web application may also publish ports to the host so users can access it.
Another common use case is local development where you run multiple services that should not accidentally interfere with each other. Putting each project into its own custom network limits cross talk so one project's database service does not get mixed up with another's.
You can also prepare network layouts that closely resemble the environments used in staging or production. Even if the actual deployment platform manages networking differently, building habits around clear network boundaries and named services in Docker simplifies the transition to more advanced container orchestration later.