What a Reverse Proxy Does and Why Self-Hosted Apps Need One
Almost every serious self-hosting guide, once someone is running more than a single application, eventually introduces a reverse proxy — Nginx Proxy Manager, Traefik, or Caddy being among the most common choices — and for someone new to self-hosting, understanding what problem this extra piece of infrastructure actually solves clarifies why it appears so consistently across setups running multiple self-hosted apps together.
The Problem: Multiple Apps, One Set of Ports
A server has exactly one set of standard web ports (80 for HTTP, 443 for HTTPS) available for incoming traffic, but a typical self-hosting setup often runs several different applications simultaneously — a Nextcloud instance, a password manager, a media server, a home automation dashboard — each of which, left to its own default configuration, would want to claim those same standard ports for itself. Without something coordinating this, only one application could realistically use the standard, expected web ports at a time, forcing visitors to remember and type unusual, non-standard port numbers for every other application.
What a Reverse Proxy Actually Does
A reverse proxy sits in front of every other application on the server, being the only thing that actually listens on the standard web ports, and routes each incoming request to the correct backend application based on which hostname or subdomain the request was addressed to — a request for cloud.example.com gets forwarded internally to the Nextcloud container, a request for vault.example.com gets forwarded to the password manager, all while every visitor interacts with clean, standard, memorable URLs rather than needing to remember which unusual port number corresponds to which specific application.
The Second Major Job: Centralized SSL/TLS Handling
Beyond routing, a reverse proxy typically also handles SSL/TLS termination for every hosted application in one centralized place — obtaining and renewing certificates (often through automated Let's Encrypt integration, discussed elsewhere on this blog) for each hostname, and handling the actual encryption and decryption of traffic — meaning individual backend applications don't each need their own separate certificate configuration at all. This is a considerable simplification: rather than configuring HTTPS separately inside every single self-hosted application, it's configured once, centrally, at the proxy layer, with backend applications typically communicating with the proxy over plain, unencrypted HTTP on the server's internal, private network, where that lack of encryption is genuinely fine since the traffic never leaves the server itself.
Why This Also Improves Security
Beyond convenience, routing all external traffic through a single reverse proxy means individual backend applications don't need to be directly exposed to the public internet at all — they can be configured to listen only on the server's internal, private network, reachable exclusively through the proxy, which considerably narrows the actual attack surface an external attacker can directly probe. If a specific application has a known vulnerability in its own built-in web server component, that vulnerability is meaningfully less exploitable if the application was never directly reachable from the outside internet in the first place.
Nginx Proxy Manager vs Traefik vs Caddy: Different Approaches to the Same Job
Nginx Proxy Manager provides a friendly, visual web interface for configuring routing rules and certificates, making it particularly approachable for someone newer to self-hosting who prefers clicking through a dashboard over editing raw configuration files. Traefik takes a more automated, "discovery-based" approach, particularly popular in Docker-heavy setups, automatically detecting new containers and their routing requirements through labels defined directly in the container's own configuration, requiring less manual reconfiguration each time a new service is added. Caddy is known specifically for defaulting to automatic HTTPS with minimal configuration required, appealing to users who want sensible, secure defaults without extensive manual setup.
The Learning Curve This Introduces
It's worth being honest that a reverse proxy introduces its own genuine layer of complexity and its own category of things that can go wrong — a misconfigured routing rule, a certificate that fails to renew specifically at the proxy layer, or confusion about which internal port a given backend application is actually listening on. This complexity is a real, if generally worthwhile, tradeoff for anyone running more than one or two self-hosted applications together, though it can feel like a genuinely steep learning curve for someone encountering the concept for the very first time.
When You Might Not Need One Yet
For someone running genuinely just a single self-hosted application, with no near-term plans to add more, a reverse proxy's routing benefit specifically doesn't yet apply — though even in this single-application case, many self-hosters still adopt one early specifically for its centralized, automated SSL/TLS handling and the security benefit of not directly exposing the backend application to the internet, treating it as sensible groundwork for whatever gets added to the same server later.
The Takeaway
A reverse proxy solves two related but distinct problems for anyone self-hosting more than a trivial single application: routing multiple applications cleanly through the server's single set of standard web ports, and centralizing SSL/TLS certificate management in one place rather than configuring it separately inside every individual application. The added configuration complexity is real, but it's foundational infrastructure that becomes increasingly valuable, rather than optional, as a self-hosted setup grows beyond a single application.
Tags: Nginx Proxy Manager, reverse proxy, self-hosting infrastructure, Traefik