Publishing Ports

A container's ports are reachable from other containers on its network, but not from the host or the outside world until you publish them. -p 8080:80 tells the daemon to install an iptables DNAT rule that forwards a host port to a container port. That is the whole mechanism: a forwarding rule the kernel applies on the way in.

Publishing is a deliberate decision about attack surface, not a checkbox you tick on every container. proxy publishes 80 and 443 because the world must reach it; web and db publish nothing, because only sibling containers on driftwood-net need them. Every published port is a door, and the fewer doors the better.

The -p hostPort:containerPort Syntax

-p 80:80 maps host port 80 to the container's port 80 by way of a DNAT rule. The left side is the host port a client connects to; the right side is the port the process is listening on inside the container. They need not match — -p 8080:80 lets a client connect to host port 8080 while the container's server listens on 80, which is how you run several containers' port-80 services on one host by mapping each to a different host port.

Publish vs Expose

EXPOSE in a Dockerfile — and the --expose flag — is documentation only. It records which ports the image listens on and changes nothing about reachability. Only -p/--publish (or Compose's ports:) actually opens a host port. Conflating the two is the single most common port complaint: "I exposed 8000 in the Dockerfile but I can't reach it." EXPOSE never published anything; without a matching -p there is no host port at all.

The Bind Address: 0.0.0.0 vs 127.0.0.1

-p 80:80 binds to 0.0.0.0 by default — every host interface — so the service is reachable from anywhere that can route to the host. On a cloud VM with a public IP, that means the public internet, immediately, the moment the container starts. Prefixing the host with a loopback address — -p 127.0.0.1:5432:5432 — binds only to the host's loopback, so the port is reachable from the host itself but not from the network. The difference between those two forms is the difference between a local-only database and one exposed to the entire internet.

# proxy: the single public entry point — publish 80 and 443 on all interfaces
docker run -d --name proxy --network driftwood-net -p 80:80 -p 443:443 nginx

# web and db: reached only over driftwood-net by siblings — publish nothing
docker run -d --name web --network driftwood-net driftwood:latest
docker run -d --name db  --network driftwood-net postgres:16

# a host-only admin port, never exposed to the network
docker run -d --name adminer --network driftwood-net -p 127.0.0.1:8081:8080 adminer

The stack's exposure is one container wide. proxy takes 80 and 443 on 0.0.0.0; web and db take no host ports and are reachable only by name over driftwood-net; the admin tool binds 127.0.0.1 so it answers the host's own browser and nothing on the LAN.

Why Publish Only proxy

proxy is the single entry point, so it is the only container that publishes anything — 80 and 443. web (gunicorn on :8000) and db (postgres on :5432) are reached only over driftwood-net by their siblings, by name, and publish nothing to the host. The result is that the application's entire externally reachable attack surface is the reverse proxy. Anything trying to reach the database has to first get through proxy and then through web — there is no direct door.

Host Port Conflicts and Ranges

Two containers cannot publish the same host port at once — the second fails to bind, because a host port is a single resource. When you do not care which host port is used, -p 80 with no host port lets the daemon assign a random high one, and docker port web shows what it chose. That is handy for ephemeral test containers where you just need a port, not a specific one, and want to avoid collisions across many short-lived runs.