On this page
What a reverse proxy does
A reverse proxy sits in front of your applications and receives every request from the internet. It decides which application should handle each request, based on the domain or path, and passes it along. It also handles HTTPS, so your applications do not each need to manage certificates, and it keeps internal services hidden from the public internet.
For example, app.example.com might go to a Node.js dashboard, api.example.com to a Python API and example.com/blog to a WordPress container, all on the same server with one set of certificates managed in one place.
When you need one
- A SaaS product with a marketing site, an app, an API and an admin panel on one or two servers.
- An agency hosting several client applications on one VPS.
- Self-hosted tools like automation platforms, dashboards or chat systems that listen on their own ports.
- An application that uses WebSockets for live updates, chat or notifications.
- A setup where apps are reachable on raw ports such as :3000 or :8080 and you want them behind proper domains.
What’s included
- Routing rules by domain, subdomain or path to each backend application.
- SSL termination with automatically renewed certificates.
- Correct forwarded headers so applications see the real visitor IP and know the request was HTTPS.
- WebSocket and long-lived connection support where required.
- Backends bound to localhost or a private network, never exposed directly.
- Sensible timeouts, upload limits and optional rate limiting per application.
- Documentation showing how to add, change or remove a route safely.
How we set it up
- List every application, the port it listens on and the domain or path it should use.
- Choose the proxy that fits: Nginx for most setups, Traefik or Caddy where automatic container discovery helps.
- Configure routes, certificates and headers, and move backends off public ports.
- Test each route from outside, including redirects, logins, uploads and WebSockets.
- Close the old direct ports in the firewall and document the result.
Tools we use
Our default is Nginx, which is well understood and very flexible. For Docker-heavy servers, Traefik can pick up new containers from labels or a file-based configuration. Certificates come from Let’s Encrypt. When Cloudflare is in front, the proxy is configured to restore real visitor IPs and, where appropriate, to accept traffic only from Cloudflare.
What affects timeline and cost
A few applications on one server is a short job. It takes longer when applications hard-code their own URLs, need path-based routing they were not designed for, span several servers, or require special handling such as sticky sessions or large streaming uploads.
If you already have a proxy that has grown messy over time, reorganising it is often part of the job. We tidy and document the existing routes before adding new ones, so the finished configuration is something your team can maintain without us.
Setups spanning several servers usually need private networking between them first, so traffic from the proxy to each backend never crosses the public internet. We include that in the plan when it applies.
An example routing plan
Before we touch any configuration, we write down the routing plan in plain terms so you can review it. For a typical SaaS product on one server, it might look like this:
| Public address | Goes to | Notes |
|---|---|---|
| example.com | Marketing site container | Static assets cached, www redirected to apex |
| app.example.com | Web application on localhost:3000 | WebSockets enabled for live updates |
| api.example.com | API service on localhost:8000 | Rate limiting on authentication endpoints |
| admin.example.com | Admin panel on localhost:8080 | Restricted to office IP or behind extra authentication |
| status.example.com | Uptime status page | Public, read-only |
This plan becomes part of your documentation. When you add a new service later, such as a help centre or a reporting tool, it is one more row in the table and one more small block in the proxy configuration. Nothing else on the server needs to change, and the new service never needs its own public port.
Common mistakes
- Leaving backend ports open to the internet after adding the proxy, so it can simply be bypassed.
- Missing forwarded headers, causing redirect loops or every visitor appearing with the proxy’s IP.
- Forgetting WebSocket upgrade headers, which breaks live features silently.
- Editing a dynamic proxy configuration by appending to it, which can leave the proxy running an older configuration without an obvious error.
Related: Nginx Configuration, Docker Deployment and SSL Installation. See Cloud & Server Management, the cloud and server guide, or contact us.
Frequently asked questions
Nginx, Traefik or Caddy: which is best?
Each works well. Nginx is the most flexible and widely known; Traefik suits servers running many Docker containers; Caddy is simple for small setups. We pick based on your stack and who will maintain it.
Can one server host apps on different domains?
Yes. The proxy routes by domain, and each domain gets its own certificate or shares a multi-domain one.
Does a reverse proxy slow things down?
The overhead is minimal for normal web traffic, and features like compression and caching often make sites feel faster.
Can the proxy route to apps on other servers?
Yes, ideally over a private network or VPN so traffic between servers is not exposed.
Can the proxy add authentication in front of internal tools?
Yes. Admin panels and internal dashboards can sit behind basic authentication, IP restrictions or a single sign-on layer at the proxy, adding protection without changing the tools themselves.
Talk to us about reverse proxy setup
Route multiple applications behind one domain with clean SSL termination.