Docker and Compose
Reverse proxy and HTTPS for a Docker Compose app
Route domains to internal services, terminate TLS and publish only the edge ports a Compose application needs.
By AppLaunch Editorial · Reviewed 2026-08-25
Direct answer
Normally only the reverse proxy publishes web ports. Application and database services stay on internal Compose networks; the proxy selects a backend by service name, handles certificates and forwards the headers the application is configured to trust.
What this means in plain English
A reverse proxy is the public front door for a web application. It receives requests for a domain, handles HTTPS and sends each request to the correct private container. The application and database normally do not need their own public host ports.
The proxy also sends information such as the original scheme and visitor address. Configure the app to trust those headers only from the real proxy; trusting them from anybody can let a visitor pretend a request came through a secure path.
Which container should be public?
| Public edge | Ports 80/443 where required |
|---|---|
| Internal app | Service name and container port |
| Trust boundary | Explicit proxy headers and allowed proxy source |
A simple example
Only the proxy publishes ports 80 and 443. It sends app.example.com to web:8080 on the private Compose network. The database has no public port. Certificates renew at the proxy, and an external monitor warns well before expiry.
What to do, step by step
1. Point DNS at the reachable host.
Start here before buying anything or changing several settings at once. It gives you a clear starting point based on public edge: ports 80/443 where required. Write the result down so you can compare it later.
2. Publish only proxy ports.
Use the same files, versions and settings that the real project will use. A quick test with an empty or different setup can look successful while completely missing the problem you are trying to solve.
3. Configure certificate issuance and renewal.
Try the busiest realistic situation, not the easiest one. Include the people, data, traffic or background work you genuinely expect, then watch for slowdowns and errors rather than relying on a single headline number.
4. Test redirects, client IP handling and backend isolation.
Finish by checking the result against trust boundary: explicit proxy headers and allowed proxy source. Keep the old setting or release available until you know the change works and can be reversed safely.
One more useful tip
Test certificate renewal, not only the first certificate. Automatic HTTPS that works today can still fail months later after DNS or firewall rules change.
Common mistakes and how to avoid them
Publishing database ports.
This gives a misleading or unsafe result because it leaves out public edge. A better approach is to point dns at the reachable host, then check the result before making the change permanent.
Trusting forwarded headers from any source.
This gives a misleading or unsafe result because it leaves out internal app. A better approach is to publish only proxy ports, then check the result before making the change permanent.
Forgetting certificate renewal failure alerts.
This gives a misleading or unsafe result because it leaves out trust boundary. A better approach is to configure certificate issuance and renewal, then check the result before making the change permanent.
Words explained
- container
- A packaged, isolated way to run an application with the files and software it needs.
- Compose
- Docker Compose is a file-based way to describe several containers, their settings, storage and networks as one application.
- reverse proxy
- A public-facing service that receives web traffic and sends it to the correct private application container.
Quick checklist
- Point DNS at the reachable host.
- Publish only proxy ports.
- Configure certificate issuance and renewal.
- Test redirects, client IP handling and backend isolation.
Common questions
What is the simple answer?
Normally only the reverse proxy publishes web ports. Application and database services stay on internal Compose networks; the proxy selects a backend by service name, handles certificates and forwards the headers the application is configured to trust.
What should I check first?
Start with public edge: ports 80/443 where required. That is usually more useful than choosing from a marketing label or copying somebody else’s setting.
How can I make the change safely?
Point DNS at the reachable host. Then change one thing at a time, keep a backup or old version, and use the same real-world test after each change.
What is the easiest mistake to avoid?
Publishing database ports. Avoiding that one mistake makes the rest of the comparison much more trustworthy.