Securely Exposing Self-Hosted Services via VPS: Architecture & Practical Guide

The "Last Mile" Problem of Self-Hosted Services

As self-hosting gains popularity, more and more enthusiasts are deploying applications like Mealie (recipe management), Immich (photo backup), and Plex (media center) locally. The self-hosting movement has grown rapidly in recent years alongside declining hardware costs and maturing open-source software — TrueNAS is an open-source network-attached storage operating system based on FreeBSD/Linux that supports ZFS for enterprise-grade data protection; Mealie is a self-hosted recipe manager written in Python that supports automatic recipe import from web pages and shopping list generation; Immich is an open-source alternative to Google Photos offering automatic photo classification, facial recognition, and mobile auto-backup; and Plex is one of the most full-featured private media servers, capable of automatically fetching media metadata and supporting real-time transcoding for streaming.

This movement's rise is closely tied to several technology trends. First, at the hardware level, ARM single-board computers (like the Raspberry Pi 5) and x86 mini PCs (like Intel NUC) have lowered the entry barrier to just a few hundred yuan. Second, the widespread adoption of containerization — Docker and Docker Compose allow anyone to deploy complex application stacks with just a few lines of YAML without understanding underlying dependencies. Third, communities like Linuxserver.io maintain hundreds of standardized container images with unified user permission mappings and persistent storage conventions. Together, these factors have spawned a massive self-hosting ecosystem: the r/selfhosted community has over 400,000 members, and the awesome-selfhosted project catalogs more than 1,500 open-source self-hosted applications.

But when you want to share these services with family and friends, a thorny problem emerges: How do you provide seamless access for non-technical users without compromising your home network security?

A recent Reddit user posed a highly representative question. He had just built a server from scratch using TrueNAS, and his family (mostly non-technical) wanted to access his services. He didn't want to open his local firewall to the public internet, nor did he think asking his parents to learn Tailscale was realistic. So he turned his attention to a VPS (Virtual Private Server) and raised several core questions — questions that are shared pain points for countless self-hosting enthusiasts.

Why a VPS Is the Ideal Secure Relay Layer

Direct port forwarding from your home network is the most primitive approach, but it carries extreme risk — your home IP is directly exposed to the public internet, and any vulnerability could lead to your entire internal network being compromised. Port forwarding essentially maps a port on your router's public IP to a corresponding port on an internal device, allowing external traffic to reach internal services directly. The risk is that once port scanning tools (like Shodan or Censys) discover open ports, attackers can attempt to exploit service vulnerabilities, and once a single point is breached, lateral movement across the entire home network faces virtually no resistance.

According to continuous monitoring by the Shadowserver Foundation, millions of devices worldwide are at risk due to improper port exposure. The Shodan search engine scans the entire IPv4 address space daily and can discover newly opened ports within hours. More dangerously, many self-hosted service web interfaces lack rate limiting and brute-force protection in their default configurations. The typical attack chain goes: port scan discovers service → identify software version → exploit known CVE or weak credentials → move laterally via ARP spoofing or SMB to other devices on the same subnet (NAS, cameras, smart home gateways). This is why the security community unanimously advises home users to never directly expose ports to the public internet.

While zero-trust networks like Tailscale and WireGuard are secure, they require every user to install and configure a client on their device — genuinely unfriendly for "technology-challenged" users (like parents). Zero Trust Networks follow the "never trust, always verify" security model, with core principles originating from the model proposed by Forrester Research's John Kindervag in 2010, later validated at scale in enterprise environments by Google's BeyondCorp project. The core assumption is that nothing inside or outside the network perimeter can be trusted, and every access must be authenticated and authorized.

Tailscale builds a Mesh VPN network on top of the WireGuard protocol, using NAT traversal to enable direct encrypted communication between devices, with its control plane handling key distribution and node discovery. Tailscale's implementation is particularly clever: it uses a centralized coordination server (Control Plane) to distribute WireGuard public keys and network topology information, but the data plane is fully decentralized — nodes establish direct peer-to-peer encrypted connections after NAT traversal via STUN/DERP servers. Traffic only routes through DERP relay servers for network environments where traversal isn't possible. This architecture means that Tailscale the company itself cannot decrypt user data traffic. WireGuard itself contains only about 4,000 lines of code, has been merged into the Linux 5.6 kernel mainline, and shows significantly better handshake latency and throughput compared to OpenVPN and IPSec.

A VPS (Virtual Private Server) is an isolated computing instance created through virtualization technology (KVM, Xen, etc.) on a physical server, with its own public IP and full operating system privileges. The underlying virtualization technology directly affects performance and isolation: KVM (Kernel-based Virtual Machine) is Linux's native full-virtualization solution where each VPS has its own kernel, can run any operating system, and performs close to bare metal; OpenVZ/LXC is container-level virtualization where all instances share the host kernel, with lower resource overhead but weaker isolation, and inability to load custom kernel modules (meaning you can't run the WireGuard kernel module on an OpenVZ VPS — only the wireguard-go userspace implementation, which has reduced performance). When purchasing a VPS, prioritize KVM-virtualized providers and pay attention to network quality — choosing a geographically nearby data center significantly improves the experience for latency-sensitive access.

The value of a VPS lies in serving as a publicly reachable secure relay node. The core logic is:

• The VPS has its own public IP; what's exposed to the internet is the VPS, not your home network;
• Your home server proactively establishes an encrypted tunnel to the VPS (outbound connection), requiring no inbound ports to be opened on your home firewall — your home router only needs to allow outbound UDP traffic (typically allowed by default), with no inbound rules configured;
• External users access domain names on the VPS, and requests are forwarded through the tunnel to the corresponding services at home.

The reverse proxy on the VPS side listens on port 443 and routes requests to the internal IP on the other end of the WireGuard tunnel based on SNI (Server Name Indication) or Host headers. SNI is a TLS extension where, during the ClientHello phase of the TLS handshake, the client sends the target domain name in plaintext. The reverse proxy uses this information to host multiple different domain HTTPS services on the same IP and port. The specific flow is: client connects to port 443 on VPS → reverse proxy reads the SNI field to determine the target domain → routing rules decide whether to forward to a local Docker container or send through the WireGuard tunnel to the home server → response is returned to the client. It's worth noting that since SNI is plaintext, network intermediaries can see which domain the user is visiting (but not the specific content). ECH (Encrypted Client Hello) is a privacy-enhancing solution being standardized that may address this in the future.

The entire chain achieves dual protection with TLS termination at the VPS + WireGuard encryption within the tunnel. This way, family members only need to type a URL in their browser to access services — no client installation required — while your home IP remains hidden behind the VPS.

Hybrid Deployment: Service Distribution Strategy Between Local and VPS

The original poster proposed a smart architectural idea: migrate some services directly to the VPS while keeping others local with VPS pass-through. This hybrid model is entirely feasible in practice and is the mainstream approach.

Lightweight Services Suitable for VPS Deployment

Lightweight applications like Mealie with small data volumes and minimal storage requirements can be deployed directly on the VPS. This way, they don't depend on your home network being online — even if your home loses power or internet, the recipe service remains available. Similar lightweight services include Vaultwarden (a lightweight Rust implementation of Bitwarden, a self-hosted password manager), Uptime Kuma (service status monitoring), etc. Their resource consumption is extremely low, and a VPS with 1-2GB of RAM can stably run multiple such applications.

Heavy-Data Services That Should Stay Local

Services like Plex and Immich involving large media files and private data should remain on local servers. There are two reasons:

1. Data sovereignty and storage costs: VPS storage is expensive and limited (typically SSD pricing is $0.1-0.2 per GB/month), making it impractical to move several TB of photos and videos there; in contrast, local NAS using HDDs has long-term storage costs one to two orders of magnitude lower;
2. Privacy protection: Private photos stored on hard drives in your own home are more reassuring than on a cloud provider's servers — you have complete control over the physical hardware without needing to trust a third party's data handling policies.

For these services, the VPS only does reverse proxy pass-through — traffic passes through the VPS encrypted tunnel back to local, and the VPS itself stores no media data. Note that in this pass-through mode, video streaming bandwidth is limited by the smaller of the VPS's network throughput and your home upload bandwidth, so Plex remote streaming quality may need to be adapted through transcoding to lower bitrates.

Data Backup Strategy for Hybrid Deployments

In hybrid deployment mode, you also need to consider backup strategies for lightweight services on the VPS. Although Mealie's data is small (typically under a few hundred MB), VPS provider disks can also fail. The recommended approach is to use deduplicating encrypted backup tools like restic or borgbackup to periodically back up VPS application data to your home NAS through the WireGuard tunnel. restic supports incremental backups and client-side encryption, meaning even if the backup target is compromised, attackers cannot read the backup contents. For services like Immich that stay local, implement a 3-2-1 backup strategy locally (3 copies, 2 media types, 1 offsite), and ZFS's snapshot and send/receive features can achieve near-zero-cost incremental backups.

Practical Considerations for VPS Elastic Scaling

The original poster also had a very practical need: he wanted to temporarily spin up a game server — for example, upgrading to 16GB or 32GB RAM one month, then dropping back to 4GB the next, without disrupting Mealie and pass-through applications.

Here, a reality check is needed. Traditional VPS "elastic scaling" isn't as seamless as imagined.

• Most VPS providers (including Ionos) allow configuration upgrades, but downgrades are often restricted — some don't even support online downgrades, or require instance recreation;
• Even if online adjustments are supported, disk capacity typically "can only go up, never down" — because filesystem shrinking operations are extremely risky and time-consuming;
• Frequent configuration changes mean potential downtime, which interrupts your pass-through services.

A more robust approach is service separation:

• Use a small, always-on VPS (e.g., 4GB) to run Mealie and the reverse proxy, ensuring long-term stability;
• When a game server is needed, spin up a separate hourly-billed high-spec instance. Hetzner Cloud is the cloud platform from the established German hosting provider, known for European data centers and exceptional value — their CPX31 instance (4vCPU/8GB) costs only about €0.02 per hour. DigitalOcean and Vultr offer clean APIs and consoles for developers, supporting instance creation and destruction in seconds via Terraform or CLI. This "use it and delete it" model is particularly suited for burst workloads like game servers: a Minecraft server needs 8-16GB RAM but might only be used a few hours per week — on-demand creation saves over 90% compared to monthly billing.

The workflow for on-demand game server creation can be highly automated. Terraform is an Infrastructure as Code (IaC) tool developed by HashiCorp that defines cloud resources through declarative configuration files — running terraform apply creates a configured VPS instance in seconds. Combined with cloud-init (the automation configuration standard for first boot of cloud instances), you can automatically install game server software, restore world saves from object storage (like S3/MinIO), configure firewall rules, and notify a Discord channel via webhook when the instance is created. After gaming, a script automatically uploads saves to object storage and destroys the instance. The entire workflow can be wrapped into a simple Shell script or Discord Bot command, allowing even non-technical users to start and stop with one click.

This approach saves money without impacting core services. Compared to repeatedly scaling a single instance up and down, this "disposable compute" mindset better aligns with cloud computing best practices.

Tunnel Solution Comparison: WireGuard vs Pangolin vs Cloudflare Tunnel

Regarding the connection between the VPS and home network, the original post mentioned two options: WireGuard and Pangolin.

WireGuard: Low-Level but Powerful Tunnel Protocol

WireGuard is the de facto standard for modern VPNs — excellent performance, strong encryption (using the Noise protocol framework, Curve25519 key exchange, ChaCha20-Poly1305 symmetric encryption), and concise configuration. If you choose it, the typical approach is: establish a WireGuard tunnel between your home server and VPS, then pair it with Nginx, Caddy, or Traefik as a reverse proxy to forward domain requests to internal services on the other end of the tunnel.

For reverse proxy selection, Caddy has been widely popular in the self-hosting community in recent years. Its standout feature is built-in ACME protocol support for automatically requesting and renewing Let's Encrypt TLS certificates, with extremely concise configuration — just a few lines to complete an HTTPS reverse proxy setup. Traefik is better suited for containerized environments, automatically discovering Docker containers and generating routing rules through Labels for "zero-config-file" dynamic routing.

The advantage is complete self-control with no third-party dependencies; the disadvantage is needing to manually configure tunnels, routing, and reverse proxy rules, which has a learning curve for beginners.

Pangolin: Out-of-the-Box Self-Hosted Tunnel Solution

Pangolin is an open-source tool gaining significant attention in the self-hosting community. It's essentially a self-hosted tunnel + reverse proxy management platform built on WireGuard. Its architecture has three components: the Server running on the VPS (containing the reverse proxy and management API), the Agent running on the home server (responsible for establishing the WireGuard tunnel and registering local services), and a Web management panel. When the Agent starts, it automatically negotiates WireGuard key pairs with the Server, establishes a persistent tunnel, and reports local service information to the Server. The Server integrates Traefik-like dynamic routing capabilities, automatically generating reverse proxy rules and TLS certificates based on domain names.

It packages the "VPS as entry point, home server as backend" architecture into a solution with a Web interface, and integrates an OIDC-based authentication gateway that can add login protection to any backend service without the backend itself needing to support authentication.

In the "self-hosted tunnel + reverse proxy" niche, there are several other notable projects besides Pangolin. frp (Fast Reverse Proxy) is a high-performance reverse proxy tool developed by Chinese developers, supporting TCP/UDP/HTTP/HTTPS and other protocol forwarding, extremely widely used in Chinese communities, but lacking integrated authentication and Web management interfaces. Rathole is a Rust rewrite of frp with lower resource usage. Caddy's cloudflare and tailscale plugins can also achieve similar functionality. The commercial ngrok offers a free tier but with traffic limits and random subdomains. Pangolin's differentiation is that it's a complete self-hosted platform rather than a single tool, integrating certificate management, authentication, traffic monitoring, and multi-site management into one package.

For users who want to reduce manual configuration without relying on third-party services like Cloudflare Tunnel, Pangolin is an excellent middle ground. It preserves WireGuard's secure foundation while significantly reducing operational complexity.

How to Choose the Right Tunnel Solution

• If you pursue maximum control and enjoy tinkering, choose native WireGuard + Caddy/Traefik;
• If you want an integrated solution with a UI that's easy to manage, choose Pangolin;
• If you don't even want to rent a VPS, you can also consider Cloudflare Tunnel (free, but data passes through Cloudflare's edge nodes, meaning Cloudflare can theoretically see your plaintext traffic; and their Terms of Service explicitly restrict large video streaming transfers — services like Plex may violate ToS and risk being banned).

Recommended Architecture: The Golden Balance of Security and User Experience

Returning to the original poster's core requirement: provide a great user experience while ensuring home network and data security. Based on the analysis above, the recommended architecture is:

1. Rent a small always-on VPS (4GB RAM is sufficient);
2. Deploy Mealie and other lightweight services on the VPS, serving them directly;
3. Use a WireGuard or Pangolin tunnel to pass Plex and Immich traffic back to local — no inbound ports open on the home firewall;
4. Place a reverse proxy in front of the VPS for unified HTTPS certificate and domain management;
5. Add an authentication layer for sensitive services (e.g., Authelia, Authentik) — Authelia is written in Go with minimal resource usage, supporting two-factor authentication (TOTP, WebAuthn/FIDO2), single sign-on (SSO), and fine-grained access control policies; Authentik is a full-featured Identity Provider (IdP) built with Python/Django, supporting SAML, OAuth2/OIDC, LDAP, and other protocols.

The technical implementation of a front-end authentication gateway typically relies on the reverse proxy's forward-auth mechanism. Using the Traefik + Authelia combination as an example: when a user request reaches Traefik, before forwarding to the backend, Traefik sends a verification subrequest to Authelia carrying the user's Cookie or Authorization header. Authelia validates the session token — if valid, it returns a 200 status code with HTTP headers containing user identity information (like Remote-User, Remote-Groups), and Traefik injects these headers into the request sent to the backend; if invalid, Authelia returns 401, and Traefik redirects the user to Authelia's login page. The entire process is completely transparent to backend applications, meaning even simple web applications without any authentication mechanism can receive enterprise-grade access control protection. The advantage of this "front-end authentication" model is that even if a backend service has unpatched vulnerabilities, unauthenticated attackers cannot reach it.

6. Temporary compute needs (game servers) are addressed with separately hourly-billed instances.

This solution lets family members access services simply by remembering a URL, while your home IP and data remain protected at all times — this is precisely the golden balance point for "secure sharing" of self-hosted services.

Key Takeaways