Networking

docker run <image>
# Container joins the default bridge network

docker run -d --name web nginx:alpine
docker run -d --name api myapp:1.0
# These are on the default bridge but cannot resolve each other by name

Note The default bridge network assigns each container an IP, but DNS resolution by container name does NOT work. You must use IP addresses or create a custom bridge network for name-based communication.

docker run --network host <image>

docker run -d --network host myapp:1.0
# App is directly accessible on host port 3000 — no -p needed

Note The container shares the host's network stack directly. No port mapping is needed or possible. This gives the best network performance but zero isolation. Only works on Linux — Docker Desktop on macOS/Windows does not support host networking.

docker run --network none <image>

docker run --network none --rm alpine:3.19 ping google.com
# ping: bad address 'google.com'

Note Completely disables networking. The container only has a loopback interface. Use this for batch processing or security-sensitive workloads that should never make network calls.

docker network create [options] <name>

docker network create app-net
docker network create --subnet 172.20.0.0/16 app-net

a1b2c3d4e5f6...

Note Custom bridge networks provide automatic DNS so containers can find each other by name. This is almost always what you want for multi-container setups outside of Compose.

docker network connect <network> <container>
docker network disconnect <network> <container>

docker network connect app-net web-api
docker network disconnect bridge web-api

Note A container can be connected to multiple networks simultaneously. This is useful for gateway containers that need to communicate with two isolated groups of services.

# On the same custom network, use container names as hostnames

docker network create app-net
docker run -d --name db --network app-net postgres:16
docker run -d --name api --network app-net -e DB_HOST=db myapp:1.0
# api can connect to db:5432 by name

Note DNS resolution by container name only works on user-defined networks, not on the default bridge. This is the number one networking gotcha for Docker beginners. In Compose, services automatically get DNS names matching their service key.

docker network ls
docker network inspect <name>

docker network ls
docker network inspect app-net --format '{{range .Containers}}{{.Name}} {{end}}'

NETWORK ID     NAME      DRIVER    SCOPE
a1b2c3d4e5f6   bridge    bridge    local
b2c3d4e5f6a7   app-net   bridge    local
c3d4e5f6a7b8   host      host      local
d4e5f6a7b8c9   none      null      local

Note Inspect shows the subnet, gateway, and which containers are connected. Useful for debugging connectivity issues between containers.

docker run -p <host_port>:<container_port> <image>
docker run -P <image>

docker run -d -p 8080:80 -p 8443:443 nginx:alpine
docker run -d -P nginx:alpine

Note -P (uppercase) publishes ALL exposed ports to random high-numbered host ports — check the mapping with docker port. Docker's port forwarding bypasses iptables/firewall rules on Linux, which can unexpectedly expose services. Use 127.0.0.1:port:port to restrict to localhost.