How Compose services reach each other by name

WHAT THIS TESTS It checks whether you understand how containers find each other in Compose without manual IP wiring.

A GOOD ANSWER COVERS When you run a Compose project, all services join a shared user-defined bridge network by default. Docker provides an embedded DNS server on that network that maps each service name to its container. So the web app uses the database service's name as the hostname in its connection string, for example postgres://user:pass@db:5432/mydb where db is the service key. Docker DNS resolves db to the database container's IP, which can change across restarts but is always reachable by name. This is why you never hardcode an IP: names are stable, IPs are not. Containers reach each other on their container ports directly on the internal network, independent of any host port published with ports.

COMMON WRONG ANSWERS Using localhost, which from inside the web container refers to that container itself, not the database. Hardcoding the database container's IP, which changes on recreate. Assuming you must publish the DB port with ports to let the web app reach it, when internal access needs no published port.

LIKELY FOLLOW-UPS Why does localhost not work between containers? Do you need to publish the DB port for internal access? How do aliases and depends_on relate to this?

ONE CONCRETE EXAMPLE The db service is named db. The web app's env sets DATABASE_URL=postgres://app:secret@db:5432/app. On startup the web container resolves db via Docker DNS to the database container and connects over the internal network, with no published host port required and no IP hardcoded anywhere.