security

Plan public Docker ports and reverse-proxy boundaries

The reverse proxy should be a deliberate public boundary, not an afterthought added after every service already has a host port.

Publish the smallest useful surface

For a public web application, the HTTPS entry point normally needs public access while application and database services remain on private Docker networks. Add other ports only for an explicit workflow such as Git over SSH.

Decide the route owner

Choose one reverse-proxy pattern and document its certificate storage, hostname routing, and restart behavior. Use the separate Reverse Proxy application when configuration generation is the next task.

Test from outside the host

Verify redirects, HTTPS, application login, uploads, websocket-like behavior where relevant, and that internal services remain unreachable from the public network.

Sources and scope

Last reviewed 2026-07-13. This page separates the decision it supports from the facts that still require a platform or model-specific check.

Applies to

Single-host Docker Compose planning and the deployment boundary described by this guide.

Does not cover

A complete application-specific configuration, host administration procedure, or a substitute for upstream documentation for the exact image and release you use.