7.1.2.3 Service Internal Ports

Service internal ports are the ports a dependent service's application actually listens on inside its own container, which other containers on the same network communicate with directly, entirely independent of whether (or how) that service's port is published to the host.

Communicating Directly With a Service's Internal Port

Containers on the same user-defined network can reach each other's internal ports directly, without that port needing to be published to the host at all.

docker network create app-network
docker run -d --name db --network app-network postgres:16
docker run -d --name api --network app-network -e DATABASE_URL=postgres://db:5432/app myapi:1.0

Here, api reaches db's internal port 5432 directly, since both containers share the same network — no host-level port publishing is needed for this internal communication to work.

Why Publishing Is Unnecessary for Purely Internal Communication

Port publishing exists specifically to make a container's port reachable from outside the Docker network entirely; for communication between containers that already share a network, this step serves no purpose and is generally omitted for services that don't need to be externally reachable.

docker run -d --name db --network app-network postgres:16

This database container has no published ports at all, yet remains fully reachable by other containers on app-network via its internal port.

Why This Matters for Security

Not publishing a service's port to the host, when that service only needs to be reached by other containers, reduces its exposure — a database reachable only from within its private network is meaningfully more protected than one also reachable from the host or external network.

docker ps --filter "name=db"

Reviewing this confirms db has no host-published ports, consistent with it being intended purely for internal, container-to-container communication.

Why Understanding Service Internal Ports Matters

Recognizing that internal, container-to-container communication relies on a service's internal port directly — without requiring host-level publishing — clarifies why many backend services in a multi-container application correctly have no published ports at all, while still being fully reachable by the other containers that actually need to communicate with them.