Self-Hosted Gateway

Reverse proxy over VPN, honestly reviewed. No marketing fluff, just what you get when you deploy it yourself.

TL;DR

• What it is: A self-hosted alternative to Cloudflare Tunnels, ngrok, and Tailscale Funnel — it creates a WireGuard VPN tunnel between your local Docker containers and a public VPS, then proxies traffic through NGINX and Caddy [README].
• Who it’s for: Self-hosters running Docker behind CGNAT (Starlink, mobile internet), ISPs that won’t let you port-forward, or anyone who doesn’t want Cloudflare sitting in front of their traffic [README].
• Cost savings: ngrok paid plans start at $10/mo with connection limits; Cloudflare Zero Trust paid tiers start around $7/user/mo. Self-Hosted Gateway runs on a $4–6 VPS plus your domain. Data not available for exact Cloudflare Tunnel pricing on all plans.
• Key strength: No custom code — it orchestrates WireGuard, NGINX, and Caddy, all battle-tested components with years of production use behind them [README].
• Key weakness: You’re managing the VPS, the WireGuard keys, and the domain DNS yourself. Cloudflare Tunnel is genuinely easier to set up for simple HTTP services. This tool earns its place when you want zero third-party routing your traffic.

---

What is Self-Hosted Gateway

Self-Hosted Gateway is a thin automation layer on top of three existing open-source tools: WireGuard (the VPN), NGINX (the gateway-side reverse proxy), and Caddy (the client-side proxy with automatic HTTPS). You run the gateway half on a public VPS and the client half alongside your existing Docker Compose services. The result is a Reverse Proxy over VPN (RPoVPN) setup where traffic enters the public internet at your VPS, travels through an encrypted WireGuard tunnel, and lands on your local Docker container — without your home IP ever being exposed [README].

The project sits at 1,692 GitHub stars and is licensed AGPL-3.0 [merged profile]. There’s no dashboard, no SaaS component, no telemetry — just a Makefile that provisions WireGuard keys, generates Docker Compose snippets, and wires NGINX config on the gateway side [README].

The website gethomerun.app is listed as this project’s homepage, but it’s actually “Homerun Desktop” — a consumer Minecraft server app that appears to use the same underlying tunneling technology to let players host game servers without port-forwarding [website]. The GitHub repository description is cleaner: “Self-hosted Docker native tunneling to localhost. Expose local docker containers to the public Internet via a simple docker compose interface.” The Minecraft framing is the consumer pitch; the Docker tunneling is the actual tool.

---

Why People Choose It

The three problems Self-Hosted Gateway solves are ones the self-hosting community runs into constantly, and article [1] on homelab setup reflects all three:

CGNAT and double-NAT. Starlink, mobile internet providers, and a growing number of residential ISPs don’t give you a routable public IP. You can’t port-forward your way out of CGNAT. The standard workaround is either paying for a VPN service with port-forwarding, or doing exactly what this tool does: renting a $5 VPS that does have a public IP and routing traffic through it [README][1].

No port-forward access. Apartment networks, corporate firewalls, and some ISP modems block port-forwarding entirely. Same solution: a tunnel out to a VPS you control [README].

Privacy from third-party tunneling services. This is where Cloudflare Tunnel and ngrok fall short for some users. Both require your traffic to pass through their infrastructure. For services handling sensitive data — private file servers, internal dashboards, personal email — that’s a trust decision. Self-Hosted Gateway keeps traffic inside your WireGuard tunnel and your VPS; nobody else sees it [README].

The homelab context from [1] is instructive: serious self-hosters run WireGuard for off-site backups and VPN already. Self-Hosted Gateway fits naturally into that stack because it uses the same tooling, just automated for the expose-to-public-internet direction rather than private access.

---

Features

From the README, this is what you actually get:

Core tunneling:

• Reverse Proxy over VPN using WireGuard — encrypted tunnel from local container to public VPS [README]
• Automatic TLS cert provisioning via Caddy’s built-in ACME client (Let’s Encrypt or ZeroSSL) — no manual cert management [README]
• Remote client IP forwarding to local container via proxy protocol [README]
• Generic TCP/UDP proxying via socat — not just HTTP services [README]

Docker integration:

• Generates a ready-to-paste link service snippet for your existing docker-compose.yml [README]
• Generates a .env file alongside your compose file for the WireGuard credentials [README]
• Client-side setup is a single make link command that SSHes to your gateway, provisions keys, and outputs the config [README]
• Works with any existing Docker Compose service: point EXPOSE at the container name and port [README]

Security:

• Basic authentication via environment variable (username:password) — useful for services without their own auth [README]
• Docker network namespace isolation separates exposed services from the rest of your home network [README]
• WireGuard provides mutual key authentication; no central auth server to compromise [README]

What’s not included: There’s no web UI, no flow for rotating WireGuard keys without reprovisioning the link, no multi-user management, and no monitoring. It’s infrastructure plumbing, not a product.

---

Pricing: SaaS vs Self-Hosted Math

The alternatives:

• Cloudflare Tunnel (Zero Trust): Free for personal use with some limits; $7/user/mo for Teams tier with additional features. The free tier works for many HTTP services but routes all traffic through Cloudflare’s network.
• ngrok: Free tier limited to 1 online ngrok process, randomized URLs, no custom domains. Paid starts at $10/mo for custom domains and more agents. Pro at $25/mo.
• Tailscale Funnel: Free for personal (3 users, 100 devices). Teams starts at $6/user/mo. Funnel (public exposure) is available on all tiers.
• Bore / frp / rathole: Free open-source alternatives that also require a VPS but have different architectures.

Self-Hosted Gateway:

• Software: $0 (AGPL-3.0) [merged profile]
• VPS to run the gateway: $4–8/mo on Hetzner, Contabo, or DigitalOcean (2GB RAM is fine for moderate traffic)
• Domain: $10–12/yr, which you likely already have

Annual math for a solo self-hoster with 5 exposed services:

Option	Annual cost
ngrok Pro	$300/yr
Cloudflare Teams (1 user)	$84/yr
Tailscale Teams (1 user)	$72/yr
Self-Hosted Gateway	~$72/yr VPS + domain

At one user the cost math is close. Self-Hosted Gateway wins on control and privacy, not price. The real savings show up when you’re running multiple services for multiple people — Tailscale and ngrok scale per user or per agent; your VPS doesn’t care how many services you tunnel through it.

---

Deployment Reality Check

What you need before starting:

• A Linux VPS with a public IP address — Hetzner, DigitalOcean, Vultr, or similar. The README specifies ports 80/443 open plus the UDP port range from /proc/sys/net/ipv4/ip_local_port_range open to the internet [README]. That last part requires a firewall rule most first-timers will miss.
• A domain where you control DNS. You’ll point a wildcard A record (*.yourdomain.com) at the VPS [README].
• SSH access to the VPS, plus docker, git, and make installed there.
• An existing docker-compose.yml on your local machine with at least one service you want to expose.

Gateway side setup:

git clone ... && cd selfhosted-gateway
make docker
make setup
make gateway

Client side — generating a link:

make link [email protected] FQDN=service.yourdomain.com EXPOSE=container-name:80

This SSHes to the gateway, provisions a WireGuard keypair, and outputs a Docker Compose snippet to paste into your local compose file [README]. Each service you want to expose gets its own link container added to your compose.

What can go sideways:

• The UDP port range requirement is easy to miss. Most VPS providers default-block all UDP traffic unless you explicitly open it in their firewall panel and the OS-level firewall (ufw/iptables). You’ll get a working WireGuard connection over the management interface but nothing on the tunnel if you skip this.
• AGPL-3.0 license means if you embed or distribute this software in a network service, you’re required to provide source code to users. For private self-hosting this doesn’t matter. For a managed hosting business built on this, it’s a legal consideration [merged profile].
• The GitHub metadata fields for last commit returned as “n/a” in the provided data, which raises a question about maintenance activity. The project appears to be maintained by a single developer (hintjen). For infrastructure you depend on, single-maintainer projects carry abandonment risk.
• No automatic key rotation. If you need to reprovision a link (new VPS, new domain), you run the make link command again and update your compose file. This is manual but not painful.

Realistic setup time for someone comfortable with Docker Compose and Linux VPS: 45–90 minutes, including DNS propagation wait time. For someone new to Linux servers: half a day minimum, and the UDP firewall rules will be the sticking point.

---

Pros and Cons

Pros

• No code, just configuration. The project is a thin Makefile and bash scripts wrapping WireGuard + NGINX + Caddy — all components with decade-long track records [README]. You’re not betting on a niche codebase.
• Automatic HTTPS. Caddy handles cert provisioning and renewal via Let’s Encrypt with zero configuration [README]. This is genuinely easier than setting up Certbot.
• TCP/UDP support. ngrok’s free tier is HTTP only. Self-Hosted Gateway proxies generic TCP/UDP via socat — useful for game servers, MQTT brokers, database tunnels [README].
• Traffic stays in your infrastructure. No Cloudflare, no ngrok, no Tailscale relay server sees your data [README].
• Docker-native. Adding a tunnel is literally adding one service to your existing compose file. No sidecar agent to manage separately [README].
• Network isolation. Docker network namespaces keep exposed services separated from your home network and other local containers [README].
• Free at scale. One VPS handles unlimited services and users.

Cons

• You manage the VPS. Updates, security patches, uptime monitoring — all yours. Cloudflare Tunnel is zero-infrastructure on your end; this is not.
• Single-maintainer project. 1,692 stars is modest. If the maintainer stops updating it, you own the problem [merged profile].
• AGPL-3.0, not MIT. More restrictive than MIT for commercial use [merged profile]. The Activepieces review in this series is MIT; this one isn’t.
• No UI. Pure CLI/Makefile. Non-technical founders will need help setting this up.
• No documentation site. The README is the documentation. It’s good, but not the same as a searchable docs site with troubleshooting guides [README].
• No key rotation workflow. Reprovisioning a link requires rerunning the setup command and updating compose files.
• Requires a domain. Cloudflare Tunnel can work without a custom domain; Self-Hosted Gateway requires DNS control [README].
• No monitoring or alerting built in. If your WireGuard tunnel drops, nothing tells you.

---

Who Should Use This / Who Shouldn’t

Use Self-Hosted Gateway if:

• You’re behind CGNAT (Starlink, mobile ISP) and need to expose Docker services publicly without a static home IP.
• You already rent a cheap VPS for other purposes and want to consolidate your tunneling there.
• You don’t want third-party infrastructure (Cloudflare, Tailscale) handling your traffic.
• You need TCP/UDP tunneling, not just HTTP — game servers, custom protocols, non-HTTP services.
• You’re comfortable reading a README and editing Docker Compose files.

Skip it (use Cloudflare Tunnel) if:

• You want zero-maintenance tunneling for standard HTTP/HTTPS services and you’re fine with Cloudflare seeing your traffic.
• You don’t want to manage a VPS.
• Setup time matters more than privacy.

Skip it (use Tailscale Funnel) if:

• You’re already using Tailscale for private network access and want public exposure too — Funnel is built in.
• You need a multi-user team setup with a proper admin console.

Skip it (use ngrok) if:

• You need temporary tunnels for development and testing, not permanent production exposure.
• You want a browser-based traffic inspector (ngrok’s traffic dashboard is useful for debugging webhooks).

Not for you if:

• You want a UI, a dashboard, or managed ops — this tool has none of that.
• Your threat model requires no VPS at all (end-to-end from your server to the client with no relay). In that case, port-forwarding directly or using a private Tailscale network is the right answer.

---

Alternatives Worth Considering

• Cloudflare Tunnel — easier setup, free, HTTP-focused, routes traffic through Cloudflare’s network. The obvious first stop for non-technical users.
• Tailscale Funnel — best option if you’re already using Tailscale for internal access. Free tier covers most solo use cases.
• ngrok — better for temporary dev tunnels than permanent production exposure. Good HTTP inspector.
• frp (Fast Reverse Proxy) — similar architecture (client-server VPN tunnel), more stars (~90K), more configuration options, Chinese-language community, no automatic HTTPS out of the box.
• Rathole — newer alternative to frp written in Rust, focused on performance and simplicity. Worth evaluating if frp feels heavy.
• Bore — minimal Rust tunnel server. Simplest possible option, no automatic HTTPS, good for TCP tunneling experiments.
• Headscale + Tailscale Funnel — fully self-hosted Tailscale control plane. More complex setup but completely removes the Tailscale cloud dependency.

For a non-technical founder who needs to expose a Docker service from behind CGNAT, the realistic decision is Cloudflare Tunnel vs Self-Hosted Gateway. Pick Cloudflare Tunnel if simplicity is the priority. Pick Self-Hosted Gateway if privacy, AGPL control, or TCP/UDP support is the priority.

---

Bottom line

Self-Hosted Gateway is a competent piece of infrastructure plumbing for a specific problem: exposing Docker services to the public internet when you can’t port-forward. It earns its 1,692 stars by doing one thing well — automating the WireGuard + NGINX + Caddy setup that experienced self-hosters would build manually anyway. The caveats are real: single maintainer, no UI, you’re managing a VPS, and the AGPL license matters if you’re building a commercial product on top of it. But for a self-hoster behind CGNAT who doesn’t want Cloudflare in their traffic path, this is a cleaner solution than stitching together the components yourself. The setup takes under two hours if you know what a firewall rule is. If you don’t, budget more time or get help — the documentation stops at the README.

---

Sources

1. NerdyArticles.com — “Welcome to My Homelab: Your Gateway to Self-Hosting!” (homelab setup overview, WireGuard and self-hosting context). https://nerdyarticles.com/my-homelab-a-general-overview/

Primary sources:

• GitHub README — hintjen/selfhosted-gateway, AGPL-3.0, 1,692 stars. https://github.com/hintjen/selfhosted-gateway
• Official website — Homerun Desktop / Self-Hosted Gateway. https://gethomerun.app