Tired of juggling IP addresses and port numbers to host multiple services on your VPS? This guide from a senior engineer breaks down how to use a reverse proxy to professionally manage and expose your applications, moving from messy quick fixes to scalable, production-ready setups.

So You Bought a VPS. Now What? A Senior Engineer’s Guide to Hosting Multiple Services.

I remember my first $5/month VPS. I felt like a king. I’d spun up a Minecraft server for my friends, a little PHP forum, and a static site to show off my “portfolio” (a single animated GIF of a spinning hamster). The problem hit me like a brick: how do I get people to all three? I ended up telling my friends, “Okay, for the website go to my-ip-address, for the forum go to my-ip-address:8080, and for Minecraft, well, that’s my-ip-address:25565.” It was a clunky, unprofessional mess, and every time I wanted to add something new, the mess grew. That experience taught me a fundamental lesson: having a server is easy, but using it well is a different beast entirely.

The “One Port to Rule Them All” Problem

So, why is this so complicated? The root of the issue is simple: on a public IP address, only one application can listen on a specific port at any given time. The default ports for web traffic are port 80 (for HTTP) and port 443 (for HTTPS). When someone types yourdomain.com into their browser, it’s trying to talk to your server on one of those two ports. If you have three different web applications all trying to grab port 443, they’re going to fight, and only one (if any) will win. The rest will fail to start. This is the fundamental bottleneck you’re up against.

You can’t just assign wiki.yourdomain.com to port 80 and blog.yourdomain.com to port 80 on the same machine. It’s a technical impossibility. So, we need a traffic cop. A bouncer. A system that sits on those precious ports and intelligently directs visitors to the right internal service. Let’s break down the ways to solve this, from the hacky fix to the way we do it in production at TechResolve.

Solution 1: The “Port Forwarding Shuffle” (The Quick & Dirty Fix)

This is the first thing everyone tries, and it’s what I did with my first VPS. You run each service on a non-standard, high-numbered port and just tell your users to tack it onto the end of the URL.

• Your Wiki runs on port 8081.
• Your Photo Gallery runs on port 9000.
• Your Monitoring Dashboard runs on port 3000.

Users access them like this: http://your.vps.ip:8081 and http://your.vps.ip:9000. It “works,” but let’s be honest, it’s terrible. It’s ugly, unprofessional, and a pain for users to remember. Worse, it makes handling SSL/TLS certificates a nightmare, as you’d need to configure them for each individual application. We can do better.

Darian’s Warning: Exposing application ports directly to the internet is a security risk. Many web frameworks are not hardened for direct exposure and assume they’ll be sitting behind a more robust web server. You’re increasing your attack surface with every port you open.

Solution 2: The Reverse Proxy (The Professional Standard)

This is the real solution and the bedrock of modern web hosting. A reverse proxy is a web server (like Nginx, Apache, or Caddy) that sits in front of your applications. It listens on the standard ports (80 and 443) and routes traffic to the correct backend application based on the hostname the user requested.

Here’s the flow:

1. User requests https://wiki.yourdomain.com.
2. Your DNS points wiki.yourdomain.com to your VPS’s IP address.
3. The reverse proxy (Nginx) running on your VPS receives the request on port 443.
4. Nginx looks at the hostname (“wiki.yourdomain.com”) and checks its configuration. It sees a rule that says “traffic for this domain goes to the service running internally on port 8081.”
5. Nginx forwards the request to your wiki application, which is listening on 127.0.0.1:8081 (localhost, not the public internet).
6. The wiki responds to Nginx, and Nginx sends the response back to the user.

The beauty of this is that the user never knows what’s happening behind the scenes. They just see a clean URL. Plus, you can handle all your SSL certificates in one place: on the reverse proxy. It terminates the encrypted connection and can pass traffic to your backend apps over plain old HTTP, which is much simpler to configure.

Example Nginx Configuration

Here’s a simplified Nginx config that routes two subdomains to two different backend services. This would typically live in /etc/nginx/sites-available/.

# /etc/nginx/sites-available/my-services
server {
    listen 80;
    server_name wiki.yourdomain.com;

    location / {
        proxy_pass http://127.0.0.1:8081; # Your wiki app
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    }
}

server {
    listen 80;
    server_name gallery.yourdomain.com;

    location / {
        proxy_pass http://127.0.0.1:9000; # Your gallery app
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    }
}

To enable SSL, you would use a tool like Certbot, which can automatically modify this configuration to listen on port 443 and handle the certificates for you. Caddy is another fantastic reverse proxy that does this automatically out of the box.

Solution 3: Containerization (The ‘Next Level’ Fix)

At TechResolve, we don’t just run applications directly on the server OS anymore. That way leads to dependency madness (“this app needs Python 3.8, but that one needs 3.10!”). We use containers, primarily Docker. Each application and its dependencies are packaged into a self-contained unit.

Using Docker with a tool called Docker Compose allows you to define all your services in a single file. You can define your wiki, your gallery, and even your reverse proxy as services that all live on a private, internal Docker network. The only thing exposed to the outside world is the reverse proxy on ports 80 and 443.

This approach gives you:

• Isolation: Services can’t interfere with each other’s dependencies.
• Reproducibility: Your entire setup is defined in code (`docker-compose.yml`), making it easy to tear down and bring back up.
• Scalability: While not a huge concern on a single VPS, this pattern is the foundation for scaling out to larger systems like Kubernetes.

A popular choice here is Traefik, a reverse proxy built specifically for containers. It can automatically detect when you start a new container and create the necessary routing rules and SSL certificates for it on the fly. It feels like magic.

Comparison of Approaches

My advice? Skip the port forwarding shuffle. Take an afternoon to learn the basics of Nginx or Caddy. It’s an investment that will pay dividends for the rest of your career. Once you’re comfortable with that, dip your toes into Docker. You’ll thank yourself later when you’re not trying to debug why installing one app broke three others on your server.

Darian Vance

Lead Cloud Architect & DevOps Strategist

With over 12 years in system architecture and automation, Darian specializes in simplifying complex cloud infrastructures. An advocate for open-source solutions, he founded TechResolve to provide engineers with actionable, battle-tested troubleshooting guides and robust software alternatives.

🤖 Frequently Asked Questions