Custom Networks

Default Network and Service Discovery

Every Compose project gets one bridge network (named <project>_default), and all services attach to it. Containers resolve each other by service name through the embedded DNS at 127.0.0.11:

docker network inspect apptest_default
# -> Services: web, api, db  (name -> container IP mapping)

That mapping is why DATABASE_URL=postgres://db:5432 works and why you must never hard-code container IPs: they change on every recreate, while the DNS entry follows. Container-to-container traffic on the same bridge flows directly — no host port round trip is involved.

Custom Bridge and Overlay Networks

Split traffic into explicit networks:

services:
  web:  { networks: [front] }
  api:  { networks: [front, back] }
  db:   { networks: [back] }
networks:
  front: {}
  back:  { internal: true }

Now web cannot reach db even by IP — back is internal, so its members also lose outbound internet. Bridge networks are single-host; overlay spans hosts but requires Swarm (services created by docker stack deploy or docker service create). Add aliases for extra DNS names, ipam to pin a subnet, and external: true to join a pre-existing network.

Pitfalls and Interview Angles

Service on two networks. api above is reachable from both sides; anything that must stay private should never join front.

Cross-project traffic. Networks are project-scoped, so projectA_web cannot dial projectB_api by default — declare the shared network as external: true in both files and attach the services explicitly.

Legacy links. Deprecated aliases that also create dependencies; service-name DNS replaces them entirely.

Interview: draw two networks and say which container can ping which, explain why internal: true is a security control, and state what overlay adds (and what it costs — Swarm).