Exposure boundary

Plan public Docker ports and reverse-proxy boundaries

Treat the reverse proxy as a deliberate public boundary: decide what reaches the internet, what stays private, and how TLS and recovery are operated before launch.

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 another port only for an explicit workflow, such as Git over SSH, and record why that port cannot remain private.

Decide the route owner

Choose one reverse-proxy pattern for the host and document who owns certificate storage, hostname routing, redirects, and restart behavior. The operating model matters more than the proxy name: a configuration is useful only when its public boundary, state location, and renewal path are understood together.

Keep application and data services off the host network

Use the Compose network as the default boundary. The proxy can reach the application service by its service name; the application can reach the database on the same private network. Publishing an application or database port to the host should be an explicit exception, not a convenience setting copied into every service.

Treat TLS material as recoverable state

Certificate and proxy state are part of the deployment. Record the volume or host path that stores certificate data, the hostname set, renewal behavior, and the recovery order after a host replacement. A successful container restart is not proof that the public route can be recovered.

Validate the whole request path

Before sending users to a service, test the public hostname, HTTP-to-HTTPS redirect, login flow, upload path, and any websocket-like connection the application relies on. Then confirm from outside the host that the application and database ports are not reachable directly.

Use upstream configuration references for the final implementation

This planning guide defines the boundary and verification checklist. Select the final proxy configuration from the current upstream documentation for the exact proxy, application image, and Compose release you operate.

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. Repeat the same checks after a proxy, certificate, host, or application-image change.