Build a Docker Network with docker network create

Two containers that cannot see each other by name are usually just missing a shared network, and docker network create fixes that in a few minutes.

You will create a user-defined Docker bridge network, check the subnet and gateway Docker assigned, attach containers to it, and remove it cleanly afterwards. The same workflow gives you a safe starting point for connecting application containers by name.

Before you start

• You need: Docker Engine and permission to talk to its daemon.
• Root is not automatic. Creating a network normally does not require a root shell; if your account cannot reach the Docker socket, ask an administrator rather than reaching for sudo, which can leave files and later commands using a different user context.
• Time: about five minutes. The examples use Docker Engine 29.8.1, installed here from the docker-ce-cli package.

Check your own client and server before relying on version-specific behaviour:

docker version
docker network create --help

The client and daemon both need to be available. The command accepts one network name, and names should be unique on the Docker host.

1. Create a user-defined bridge

A bridge network is local to one Docker Engine, and it is the normal choice when containers on one host need an isolated network. The driver defaults to bridge, but stating it explicitly makes the example easier to follow.

Choose a subnet that does not overlap the host, any VPN, the office network, or another Docker network. This example uses a private range reserved just for the test:

docker network create \
  --driver bridge \
  --subnet 172.30.240.0/24 \
  --gateway 172.30.240.1 \
  project-net

On success, Docker prints a long network ID, for example:

6c31b216ef527ea612289b559baf74c768c38e86bfd030e509954c71ea854320

If Docker reports the name already exists, inspect the existing network before deciding whether it is actually yours. Do not blindly reuse a name from another project.

2. Inspect what Docker created

Creation succeeding does not prove the addressing is what you intended, so inspect it before attaching services:

docker network inspect project-net

For a compact check of the fields that matter, use a format string:

docker network inspect \
  --format '{{.Name}} {{.Driver}} {{.Scope}} {{range .IPAM.Config}}{{.Subnet}} {{.Gateway}}{{end}}' \
  project-net

3. Attach containers by network name

Start a container with --network when you create it. This example uses two short-lived Alpine containers, so it does not leave a running service behind:

docker run -d --name project-one --network project-net alpine sleep 300
docker run -d --name project-two --network project-net alpine sleep 300

Verify both are connected:

docker network inspect \
  --format '{{range .Containers}}{{.Name}} {{end}}' \
  project-net

The output should list project-one and project-two. User-defined networks provide Docker DNS, so a container can address another by its name, but that resolution is scoped to the network: a container on a different network is not automatically a peer.

Stop and remove the examples once you have finished testing:

docker rm --force project-one project-two

Choose advanced options deliberately

• --subnet sets the network segment, --gateway sets its gateway, and --ip-range limits container address allocation to a sub-range. A bridge network accepts one subnet.
• Leaving them out lets Docker pick a non-overlapping subnet and gateway, but an implicit choice can collide with a later VPN or a second project. Pin them when repeatability matters.
• --internal lets containers talk to each other while blocking ordinary external connectivity. Treat it as a connectivity boundary, not a full security policy: applications, published ports and host access still need their own review.

Driver options go after --opt. This example sets the default host address a bridge network uses when it publishes container ports:

docker network create \
  --driver bridge \
  --opt com.docker.network.bridge.host_binding_ipv4=127.0.0.1 \
  local-only-published-ports

Check the result with docker network inspect local-only-published-ports. Do not copy driver options from a different driver without reading that driver's documentation first.

When an overlay network is the right answer

Do not pick overlay just because it sounds more capable. It is for networks spanning Docker daemons, and the hosts must be in Swarm mode, including standalone containers on different hosts. The participating hosts need the documented Swarm and overlay traffic ports open.

On a Swarm manager, a basic service network is:

docker network create --driver overlay project-overlay

By default, a Swarm-scoped overlay is for services only. Add --attachable when manually started containers need to join it too:

docker network create \
  --driver overlay \
  --attachable \
  project-overlay

Overlay networks use distributed networking, so subnet planning matters more here. Docker's current guidance is to keep the default /24 block for VIP-based endpoint mode, and use several smaller networks or DNS round-robin with an external load balancer when the design needs more addresses.

Undo the test network

Before removal, check which containers are still attached:

docker network inspect project-net

docker network rm project-net

Docker prints the removed network's name. If removal fails because containers are still connected, find them from docker network inspect and use docker network disconnect project-net CONTAINER only when that change is safe. The built-in default bridge network is different: Docker creates it for the daemon itself, and this command cannot remove it.