Docker Port Reference
Default exposed ports for the container images you'll actually run — databases, web servers, queues, monitoring stacks — for writing docker-compose files, Kubernetes service definitions, and firewall rules without hunting through five different image docs.
How port publishing actually works
Containers run in isolated networks by default, invisible from outside unless you explicitly publish a port. -p 8080:80 maps host port 8080 to container port 80 — in docker-compose that's the ports key, and in Kubernetes it's handled through Service objects (ClusterIP, NodePort, LoadBalancer) instead of a direct flag.
Practices that actually keep containers from being the weak point
- Only publish what genuinely needs external access — a database backing your app should never have a published port at all, full stop
- Bind to a specific interface when you do need something reachable locally:
127.0.0.1:3306:3306keeps MySQL local-only, not exposed to the wider network - Use Docker's internal networking for container-to-container traffic — containers on the same network reach each other by service name, no published port required, no external exposure at all
- Put a reverse proxy (nginx, Traefik, Caddy) in front of everything public-facing, and only publish 80 and 443 externally — every other service stays behind it
- Secrets belong in Docker secrets or an env file, never a command-line flag — a database with a published port and a weak password baked into a shell history is a genuinely common way these get compromised
What a sane stack actually looks like
In a typical web app, only the reverse proxy has a published port. The app server, database and cache all talk to each other over an internal Docker network with nothing published — which means even a misconfigured host firewall doesn't accidentally expose the database directly, because there's no published port for the firewall to fail to protect in the first place.