What is a Reverse Proxy? Why Every Homelab Needs One (2026 Guide)

By Joe | Part 1 of the Complete SWAG Infrastructure Series 🇨🇦

Every homelab eventually reaches the same point. You've got a dozen-plus services running already somehow: Jellyfin, Vaultwarden, a *arr stack, maybe a dashboard, maybe Immich - and every single one of them wants its own port. You're bookmarking 192.168.1.50:8096, 192.168.1.50:8080, 192.168.1.50:9443, and trying to remember which one is which.

This is the exact moment every homelabber discovers they need a reverse proxy. Not "should consider." Need.

This post is an architecture review, to answer questions like:

1. What a reverse proxy actually does under the hood.
2. The open-source (FOSS) landscape you will encounter when shopping for hardware armour.
3. Why Core Lab has settled on SWAG as the foundational reverse proxy driving our entire infrastructure roadmap.
4. The deployment blueprint to take you from a isolated localhost to exposing your first secure web service to the web (Parts 2 through 5).

What a Reverse Proxy Actually Does (Architecture 101)

Strip away the enterprise marketing speak, and a reverse proxy has one fundamental job: it sits directly between the public internet and your private internal local area network (LAN), acting as an authoritative traffic cop to decide exactly where an incoming request goes.

• Public services (like a Blog) are accessible to the world.
• Private services (like Obsidian) are accessible only to you.
• Authentication is handled centrally, not by every individual app.

Without a proxy, your home network architecture is a security hazard:

Internet ──> Router (port forward per service) ──> Service A:8096
                                                 ──> Service B:8080
                                                 ──> Service C:9443

In this legacy configuration, every single application requires its own forwarded port on your router. Each container must handle its own Transport Layer Security (TLS) certificates (or worse, run unencrypted over plain HTTP), and your router's port-forwarding table turns into a graveyard of forgotten security exposures.

The Choke Point Strategy

When you introduce a reverse proxy, you collapse that chaotic attack surface into a single, unified entry point.

Think of the internet as a continuous threat environment, and your WAN perimeter as the edge of the battlefield. A reverse proxy acts as a classic Choke Point - a tactical bottleneck where you force external attackers to funnel into a localized zone of absolute control.

This isn't just hobbyist advice. The Canadian Centre for Cyber Security’s (CCCS) Top 10 IT Security Actions lists its number one priority as: Consolidate, monitor, and defend internet gateways. A reverse proxy is exactly how you execute that mandate in a self-hosted environment.

How a Reverse Proxy Improves Your Homelab

Internet (User)
      ⬇
[ Cloudflare DNS ]  <-- "Where does yourdomain.com live?"
      ⬇
[ OPNsense Firewall ] <-- "Port 443 is Open"
      ⬇
[ Nginx Proxy Manager ] <-- "The Traffic Cop"
      ⬇    ⬂ (Is this Private?)
      ⬇       [ Authelia ] <-- "Halt! ID Please."
      ⬇           ⬇
[ Docker Container ] (Ghost / Obsidian / Uptime Kuma)

Why You Eventually Need a Reverse Proxy

In a corporate environment, this is solved by teams of personnel with dedicated security budgets. In a homelab, it's just you - which is exactly why the reverse proxy earns its keep:

• Attack surface collapses: Instead of a dozen services each running their own listener with their own (often mediocre) security posture, you have one component in front of all of them. Harden that one thing well and everything behind it benefits.
• Automated Certificate Management: Wildcard or per-subdomain Let's Encrypt certs, auto-renewed, means you're never clicking through a browser security warning at 11pm because a self-signed cert expired.
• Centralized Security Hardening: Rate limiting, fail2ban, geo-blocking, WAF rules - none of that is practical to bolt onto every individual container. It's trivial to apply once at the proxy layer.
• Clean, Memorable URLs: vault.yourdomain.com beats 192.168.1.50:9443 for you, and it's mandatory if you ever want to hand a service to someone else in your household without a support call.

If you're running Docker behind something like a SWAG or Traefik setup already, none of this is news. If you're still juggling forwarded ports, this is the single highest-leverage upgrade you can make to a homelab this year!

What a Reverse Proxy Does NOT Do

To design your infrastructure cleanly, you must understand what a reverse proxy is not:

• It is not a VPN: A VPN creates an encrypted network tunnel allowing an external device to join your home network entirely. A reverse proxy selectively publishes specific web applications to the public internet without granting access to the underlying local network.
• It is not a Firewall: While a proxy can filter traffic, your hardware firewall (like OPNsense or pfSense) is still required to drop malicious packets at the WAN hardware boundary before they hit your application stack.
• It is not DNS: DNS simply maps a domain name to your public IP address. The reverse proxy takes over only after the request arrives at your IP, determining which internal container receives it.
• It is not Cloudflare: Cloudflare runs a massive global edge proxy network. While it can complement your homelab by masking your home IP and providing DDoS protection, an internal reverse proxy is still required to route that incoming traffic to your specific target Docker containers.

The FOSS Reverse Proxy Landscape

Here's where it gets interesting and there isn't one obvious answer, and the "best" reverse proxy genuinely depends on what you're optimizing for and/or your use cases. Let's walk the battlefield and examine the shields you have to choose from.

NGINX

The OG. Rock solid, battle-tested, infinitely configurable. But "infinitely configurable" cuts both ways - you're hand-writing server blocks, managing certbot renewal cron jobs yourself, and there's no guardrails stopping you from misconfiguring something into a security hole. Great if you want full control and don't mind the maintenance. Rough as a daily-driver homelab tool.

HAProxy

The performance king, especially for TCP/layer-4 load balancing. If you're doing serious traffic shaping or need sub-millisecond routing decisions, HAProxy is what the big boys use. For a homelab serving a handful of users, it's overkill - and its config syntax has a steeper learning curve than almost anything else on this list for comparatively little homelab-specific benefit.

Nginx Proxy Manager (NPM)

The gateway drug for most homelabbers. It wraps nginx and certbot in a clean web UI - click to add a proxy host, click to request a cert, done. Genuinely great for onboarding. The tradeoffs show up over time: the UI abstracts away the underlying nginx config in a way that makes advanced customization awkward, the SQLite-backed config can drift from what you'd expect, and it doesn't ship with any real security hardening out of the box - you're on your own for fail2ban, WAF rules, or bot mitigation.

Traefik

The Docker-native darling. Traefik watches your Docker socket and auto-discovers services via container labels - no manual config file editing when you spin up a new container, it just picks up the labels and routes accordingly. That dynamic config model is genuinely elegant for docker-compose-heavy setups. The cost is a real learning curve around Traefik's own concepts (routers, entrypoints, middlewares) and a YAML/label syntax that trips up a lot of newcomers. Security add-ons (CrowdSec, fail2ban-equivalents) exist but require assembling them yourself as middleware plugins.

Caddy

The simplicity champion. Automatic HTTPS is the default behavior, not a bolt-on - Caddy just gets you a valid cert with almost no configuration. The Caddyfile format is genuinely the easiest to read and write of anything on this list. Where it falls short for homelab use is the security tooling ecosystem: there's no equivalent to a mature fail2ban or CrowdSec integration baked in, and the plugin ecosystem, while growing, is smaller than what you get around nginx.

SWAG (Secure Web Application Gateway)

SWAG is actually built on NGINX, and it's built differently from the rest of this list: instead of a from-scratch proxy, SWAG is nginx plus everything you'd otherwise have to assemble by hand - certbot auto-renewal, fail2ban, CrowdSec bouncer integration, geo-blocking, ModSecurity, and a library of community-maintained sample proxy configs for hundreds of popular self-hosted apps.

That last part matters more than it sounds. Spinning up a new service behind SWAG usually means uncommenting a pre-written config snippet rather than writing one from scratch - someone in the LinuxServer.io community has almost certainly already solved the "how do I proxy this specific app correctly" problem for you.

📊 2026 Homelab Reverse Proxy Comparison Matrix

Why Core Lab Uses SWAG

It's the only option that treats security as the default, not an add-on.

Fail2ban is enabled the moment you deploy it, CrowdSec is simply 1 plugin & config away, not something you're assembling from three different GitHub repos after the fact. For a homelab that's exposed to the internet (which, if you're reading this, yours probably is), that's not a nice-to-have.

The sample proxy-conf library is a genuine time machine. Whatever self-hosted app you're adding next, there's a very good chance someone's already written and tested the correct (optimized even!) nginx config for it. That collapses the single biggest friction point in reverse proxy management - writing correct per-app configs - into a copy, uncomment, and restart.

It's Docker-native without hiding the nginx underneath it. Unlike Traefik, which asks you to learn its own routing abstraction, SWAG is still just nginx - which means when you need to drop into a raw server block and do something custom, you can, using decades of nginx documentation and Stack Overflow answers instead of a newer, smaller ecosystem.

LinuxServer.io's maintenance track record is excellent. Regular image updates, multi-arch support, and an active community means this isn't a project you have to worry about going stale.

Traefik and Caddy are both genuinely good software, and if your priority is pure Docker-label elegance or dead-simple config, they're defensible choices. Even moreso if you're a developer or really want to focus on IaC (Infrastructure as Code). But for a homelab where you're the only security team you've got, SWAG's batteries-included approach to hardening is the deciding factor. It's what's running my own infrastructure, and it's what we'll be building future Core Lab guides around.

🗺️ Next Steps: The SWAG Deployment Pathway

This architectural review establishes the "why." Next, we roll up our sleeves and move directly into hands-on implementation. Prepare your environment for the upcoming modules in this flagship series, starting with:

• Part 2 - Self-Hosting SWAG: The Ultimate NGINX Reverse Proxy Guide (2026 Edition)
  From a bare-metal docker-compose file to routing your very first live, secure web service.

If you're already running WireGuard or Vaultwarden in your homelab, SWAG is the missing piece that ties your remote access and internal services together securely - we'll be cross-linking those guides as this series comes together.

Got a reverse proxy setup that's working for you? Hit reply on this newsletter or drop a comment. Always curious what the community's running.

Frequently Asked Questions

What is a reverse proxy?

A reverse proxy is a server or application that sits between the internet and your self-hosted services. Instead of exposing each application directly, all incoming web traffic first passes through the reverse proxy. It examines the request and securely forwards it to the correct internal service.

In addition to routing traffic, modern reverse proxies can automatically manage HTTPS certificates, enforce authentication, apply security rules, and hide your internal infrastructure from public view.

Do I really need a reverse proxy for a homelab?

If you're only running services on your local network, a reverse proxy isn't strictly required.

However, as soon as you want secure HTTPS, custom subdomains, remote access, or multiple web applications, a reverse proxy becomes one of the most valuable pieces of your infrastructure.

Instead of exposing numerous ports and configuring each application individually, you manage everything through a single secure entry point.

Is a reverse proxy the same as a VPN?

No.

A VPN creates an encrypted tunnel that allows you to securely join your home network from another location.

A reverse proxy publishes specific web applications to the internet while adding security features such as HTTPS, authentication, rate limiting, and request filtering.

Many homelab owners use both together. A VPN provides secure access to their entire network, while a reverse proxy safely exposes selected services like Nextcloud, Jellyfin, or Vaultwarden.

Is Cloudflare a reverse proxy?

Cloudflare can function as a reverse proxy for websites that use its proxy service.

However, in a typical homelab, Cloudflare handles DNS, caching, and DDoS protection at the edge, while an internal reverse proxy like SWAG, Traefik, or NGINX routes requests to your Docker containers or servers.

The two complement each other rather than replace one another.

Which reverse proxy is best for Docker?

There isn't a single "best" reverse proxy—only the best one for your needs.

• NGINX offers maximum flexibility and performance.
• NGINX Proxy Manager is excellent for beginners who prefer a web interface.
• Traefik excels at automatic Docker service discovery.
• Caddy makes HTTPS incredibly simple.
• SWAG combines NGINX with automated certificates, Fail2ban, CrowdSec integration, ModSecurity, and hundreds of ready-made application configurations, making it one of the most complete solutions for self-hosted homelabs.

For the remainder of this series, I'll be using SWAG because it provides an excellent balance between security, flexibility, and ease of maintenance.

Should I choose SWAG or Traefik?

Both are excellent choices.

Traefik shines in highly dynamic Docker environments where services are frequently created and destroyed automatically.

SWAG is ideal for homelab users who want the power of NGINX together with production-ready security features, extensive community-maintained proxy configurations, and a straightforward file-based configuration system.

If you're new to reverse proxies or value security-first defaults, SWAG is an outstanding starting point.

Can I run multiple reverse proxies?

Yes.

Many larger environments run several reverse proxies for different purposes.

For example, Cloudflare may proxy internet traffic, SWAG may handle HTTPS termination and authentication inside your homelab, and another reverse proxy could sit in front of a Kubernetes cluster.

For most home labs, however, a single well-configured reverse proxy is simpler to manage and more than capable of handling dozens of services.

Is SWAG only for Docker?

No.

Although LinuxServer.io distributes SWAG as a Docker container and that's how this series uses it, the underlying technology is still NGINX.

SWAG can proxy traffic to Docker containers, virtual machines, physical servers, NAS devices, or any other system reachable over your network.

This makes it an excellent choice for mixed homelab environments.

Why does every guide recommend opening only port 443?

Modern web traffic is expected to use HTTPS over port 443.

A reverse proxy allows every public web application to share this single secure entry point while routing traffic internally based on the requested hostname. Instead of opening dozens of different ports through your firewall, you typically only need ports 80 (for certificate validation) and 443 (for secure HTTPS traffic).