One Reverse Proxy for Every App on the Box
How one reverse proxy routes every app on a self-hosted box, handling TLS, domains, and routing, so adding a new site is a config entry instead of new infrastructure.
Run one reverse proxy in front of every app on a box and it handles all the shared work at once: routing each domain to the right app, terminating TLS, redirecting to HTTPS, and letting a dozen sites share one machine and one public IP. It is the single piece that turns a bare VPS into a platform that can hold a whole portfolio. Once it is set up, adding a new app is a config entry, not a new server. Here is how the pattern works and why it is the backbone of an owned stack.
The core idea: your apps do not each need a public port and a certificate. They sit privately on the box, and one proxy out front decides which request goes where and speaks HTTPS to the world for all of them.
What a reverse proxy actually does for you
Four jobs, bundled into one always-on service.
Routing by domain. A request for one site and a request for another both hit the same box on the same port, and the proxy reads the hostname and forwards each to the right app running privately behind it. That is what lets many sites live on one machine, the packing that makes portfolio hosting cheap, the same economics behind one Postgres box under every app.
TLS termination. The proxy holds the certificates and handles HTTPS, so your individual apps speak plain HTTP internally and never deal with certs. Many proxies fetch and renew certificates automatically, which removes an entire category of "the certificate expired" outages.
Redirects and headers. HTTP to HTTPS, security headers, compression, all applied in one place instead of reimplemented in every app.
How adding an app becomes a config entry
This is the payoff. With the proxy in place, shipping a new site is not standing up infrastructure. It is a few lines.
Run the new app on the box on a private internal port. Add a block to the proxy config: this domain forwards to that port. Point the domain's DNS at the box. The proxy fetches a certificate and starts routing. The new site is live over HTTPS, sharing the same machine and IP as everything else, and you added no new server, no new load balancer, no new certificate chore. That is the compounding that makes a solo portfolio possible, the same reason a git-push deploy scales, which I cover in git push deploy on your own box.
Does one proxy become a single point of failure
Worth addressing, because it is true that if the proxy is down, every site behind it is unreachable. Two things make that acceptable.
First, the proxy is simple and stable. A mature reverse proxy doing routing and TLS is not where outages come from; app bugs and database problems are. A well-configured proxy runs for months without touching it. Second, it restarts in seconds and its config is a plain file in your repo, so recovering it is trivial and rebuilding it on a fresh box is part of the same scripted setup I use for disaster recovery when you self-host. The shared proxy concentrates a little risk in exchange for removing enormous per-app complexity, and for a fleet that trade is clearly worth it.
Put a CDN in front and the layers click
The proxy is the box-level layer. Above it sits the edge. Cloudflare or a similar CDN in front of the box handles caching and absorbs attacks, then forwards to your proxy, which routes to your apps. Each layer has one job and stays swappable.
That layering is the whole owned-stack shape: edge on top for reach and protection, proxy in the middle for routing and TLS, apps and shared database underneath. I walk through the edge layer in how to put Cloudflare in front of your own server. None of these layers locks you in, because each is standard and replaceable, which is the test I hold everything to in what no vendor lock-in actually requires.
The backbone you build once
The reverse proxy is the quietest, most important piece of the stack. It is what makes "many apps, one box" real instead of a slogan, and it is what makes the marginal cost of the next app almost nothing. Build it once, keep its config in your repo, and every future product rides on it for free.
I made this proxy layer a default in my hosting stack, HostSSH, so a new app on the fleet gets domain routing and automatic HTTPS the moment its config entry lands, no per-app networking to design. One proxy, many apps, owned outright. That is the piece that turns a rented-feeling server into a platform you actually control.