--- title: '007. Setting up VPS Webproxy to #homelab servers using Tailscale' url: 'https://prozak.org/007-setting-up-vps-webproxy-to-homelab-servers-using-tailscale' markdown: 'https://prozak.org/007-setting-up-vps-webproxy-to-homelab-servers-using-tailscale.md' date: '2025-07-03' description: 'Hands-on guide for securely exposing self-hosted services without port forwarding by using a small VPS with Caddy and Tailscale.' taxonomy: category: - self-hosting tag: - cloud - tailscale - caddy archives_month: - jul_2025 archives_year: - '2025' --- # 007. Setting up VPS Webproxy to #homelab servers using Tailscale [ Blog Posts ](https://prozak.org/) 007. Setting up VPS Webproxy to #homelab servers using Tailscale 03 *Jul* #### [007. Setting up VPS Webproxy to #homelab servers using Tailscale](https://prozak.org/007-setting-up-vps-webproxy-to-homelab-servers-using-tailscale) [cloud](https://prozak.org/tag:cloud) [tailscale](https://prozak.org/tag:tailscale) [caddy](https://prozak.org/tag:caddy) ![](https://prozak.org/images/1/9/e/b/4/19eb44071fef112c86b114b78259a35f8106fe6a-diagramtailscale.jpeg) In the current age of remote access and #self-hosting, one of the most tempting solutions is to expose your local services directly to the internet — but that usually comes at a cost: security, complexity, and peace of mind. While opening ports and configuring dynamic DNS might feel like the "quick win," it introduces unnecessary attack surfaces to your home network. There is a different way, One that I personally prefer as it is simple, effective and secure. By combining a minimal [VPS](https://en.wikipedia.org/wiki/Virtual_private_server), [Caddy](https://caddyserver.com) as a reverse web proxy, and [Tailscale](https://tailscale.com) as the secure mesh layer between your external node and your LAN, you can enable access to your self-hosted services with zero ports exposed, fine-grained access control, and surprisingly low complexity and support upkeep. **Why not expose your LAN servers directly to the Internet?** Let’s start here. Hosting a personal dashboard, wiki, media player or any other #selfhosted solution? Exposing them directly to the internet means: - Dealing with NATs, port forwarding, and routers that may or may not support [hairpinning](https://en.wikipedia.org/wiki/Network_address_translation). - Needing external TLS termination and certificate renewal. - Being vulnerable to bots, scans, or brute-force attacks. - Constantly worrying about “what if I forgot to secure that one container?” The alternative? Keep all your services **inside your LAN**, and only allow access through a trusted and controlled tunnel. **The Stack: What You’ll Use** **Tailscale** – For secure mesh networking between your VPS and LAN machines. **Caddy Server** – A modern web server that handles automatic HTTPS and reverse proxying. **A VPS** – A simple, external node that acts as your gateway. Recommendation: Only Debian — no Ubuntu here thank you very much. **Why These (Not Self-Hosted)** You might ask: “If I'm into self-hosting, why rely on a VPS or external tools like Tailscale or Caddy?” It’s a fair question — and the answer lies in choosing the right battles. **Tailscale**Tailscale builds a secure, peer-to-peer mesh VPN using WireGuard. It handles key exchange, NAT traversal, IP allocation, and device discovery — without requiring a central VPN server or manual config. It works everywhere, including CGNAT environments, and can easily scale from 2 devices to 200+. **Caddy**Unlike nginx or Apache, Caddy is built with HTTPS by default — zero effort TLS provisioning and renewal using Let’s Encrypt. Its configuration syntax is intuitive, and it supports modern features like automatic reverse proxying, basic auth, and even Docker-aware plugins. For small setups, it’s everything you need and nothing you don’t. **VPS**You only need one small VPS — ideally located geographically close to your home — to act as your reverse proxy gateway. This node connects to your LAN over Tailscale, handles inbound HTTPS requests with Caddy, and relays them securely to your internal services. No need for port forwarding or dynamic DNS on your home router. **Why Debian?**We choose Debian over other distributions for a reason: it follows a strict free software philosophy, it’s community-governed, stable, and transparent. Unlike Ubuntu, which often introduces proprietary blobs, Snap packages, and telemetry by default, Debian aligns with the self-hosting and privacy-first ethos. It's our preferred base for any #homelab or infrastructure node. **Architecture Overview**![diagram_tailscale](https://prozak.org/images/7/d/b/5/1/7db51e1ca3cd2ec9b1df469efb56d4d0bdb1a66c-diagramtailscale.jpeg "diagram_tailscale") ``` [Client] → https://yourdomain.com → [VPS + Caddy] → Tailscale Tunnel → [Your LAN service] ``` The VPS becomes the only entrypoint to your services. It’s connected to your home network via Tailscale, and acts as a forward-only relay to just the services you want. Step-by-Step Guide **Set up Tailscale on your LAN Devices** [Install Tailscale](https://tailscale.com/kb/1174/install-debian-bookworm) on your home server(s): (simplified way, check the official documents) ``` curl -fsSL https://tailscale.com/install.sh | sh sudo tailscale up ``` Once online, label them for easier identification. **Set up Tailscale on your VPS** Same install process: (simplified way, check the official documents) ``` curl -fsSL https://tailscale.com/install.sh | sh sudo tailscale up --ssh ``` You don’t need to enable “exit node” — the VPS is just a controlled relay. **Configure Access Control Rules (ACLs)** Visit Tailscale Admin ACLs and restrict the VPS to only talk to specific IPs/ports in your LAN: ``` { "ACLs": [ { "Action": "accept", "Users": ["autogroup:admin"], "Sources": ["vps-tailnet-ip"], "Destinations": ["192.168.1.100:3000", "192.168.1.101:8000"] } ] } ``` This ensures the VPS can only talk to your defined services. **Install & Configure Caddy on the VPS** Install Caddy on Debian: ``` sudo apt install -y debian-keyring debian-archive-keyring apt-transport-https curl -1sLf 'https://dl.cloudsmith.io/public/caddy/stable/gpg.key' | sudo tee /etc/apt/trusted.gpg.d/caddy.gpg > /dev/null curl -1sLf 'https://dl.cloudsmith.io/public/caddy/stable/debian.deb.txt' | sudo tee /etc/apt/sources.list.d/caddy-stable.list sudo apt update sudo apt install caddy ``` Then, create a Caddyfile to proxy requests to the LAN via Tailscale: /etc/caddy/Caddyfile ``` service.yourdomain.com { reverse_proxy 100.101.102.103:3000 # Tailscale IP of LAN host } ``` Reload Caddy: ``` sudo systemctl reload caddy ``` Optional: Add Basic Auth (if semi-public) ``` service.yourdomain.com { basicauth / user JDJhJDEwJGxqT... //[HASHED Password] reverse_proxy 100.64.0.50:9000 } ``` Hash your password using: ``` caddy hash-password ``` **Conclusion**This method enables secure, low-friction access to your #homelab services without exposing your LAN, relying only on tools that do one thing and do it well. [ Next Post](https://prozak.org/008-the-web-is-meant-to-be-personal) [Previous Post ](https://prozak.org/006-why-selfhosting-should-be-preferred) #### Related Posts - 100 [011. Deploying Centralized TLS Certificates Node + Docker Application](https://prozak.org/011-deploying-centralized-tls-certificates-node-docker-application "011. Deploying Centralized TLS Certificates Node + Docker Application") - 100 [010. Centralized Wildcard Certificate on Debian with Let’s Encrypt + deSEC](https://prozak.org/010-centralized-wildcard-certificate-on-debian-with-lets-encrypt-desec "010. Centralized Wildcard Certificate on Debian with Let’s Encrypt + deSEC") - 100 [009. Caddy Server Auth Crunch Plugin](https://prozak.org/009-caddy-server-auth-crunch-plugin "009. Caddy Server Auth Crunch Plugin") - 90 [005. Oracle Cloud Always Free Instance Ubuntu -> Debian Conversion](https://prozak.org/005-oracle-cloud-always-free-instance-ubuntu-greater-than-debian-conversion "005. Oracle Cloud Always Free Instance Ubuntu -> Debian Conversion") - 80 [006. Why #SelfHosting should be preferred](https://prozak.org/006-why-selfhosting-should-be-preferred "006. Why #SelfHosting should be preferred") #### Links - [< ](https://webring.obeythesystem.com/page?=previous)[OBEY THE SYSTEM Webring](https://webring.obeythesystem.com/)[ >](https://webring.obeythesystem.com/page?=next) - [rc64k@Github](https://github.com/rc64k) - [Prozak's Mastodon](https://mastodon.social/@prozak) #### Popular Tags [self-hosting](https://prozak.org/tag:self-hosting) [linux](https://prozak.org/tag:linux) [python](https://prozak.org/tag:python) [caddy](https://prozak.org/tag:caddy) [cloud](https://prozak.org/tag:cloud) [privacy](https://prozak.org/tag:privacy) [Philosophy](https://prozak.org/tag:Philosophy) [Quote](https://prozak.org/tag:Quote) [emby](https://prozak.org/tag:emby) [tailscale](https://prozak.org/tag:tailscale) [influxdb](https://prozak.org/tag:influxdb) [network](https://prozak.org/tag:network) [unifi](https://prozak.org/tag:unifi) [artificial intelligence](https://prozak.org/tag:artificial%20intelligence) #### Archives - [ 1 October 2026 ](https://prozak.org/blog/archives_month:oct_2026) - [ 2 July 2026 ](https://prozak.org/blog/archives_month:jul_2026) - [ 3 March 2026 ](https://prozak.org/blog/archives_month:mar_2026) - [ 3 July 2025 ](https://prozak.org/blog/archives_month:jul_2025) - [ 1 May 2025 ](https://prozak.org/blog/archives_month:may_2025) - [ 1 March 2025 ](https://prozak.org/blog/archives_month:mar_2025) - [ 1 September 2024 ](https://prozak.org/blog/archives_month:sep_2024) - [ 1 February 2024 ](https://prozak.org/blog/archives_month:feb_2024) - [ 1 August 2023 ](https://prozak.org/blog/archives_month:aug_2023) - [ 1 March 2021 ](https://prozak.org/blog/archives_month:mar_2021) - [ 2 February 2021 ](https://prozak.org/blog/archives_month:feb_2021) #### RSS & Atom Feeds [ Atom 1.0](https://prozak.org/blog.atom) [ RSS](https://prozak.org/blog.rss) --- ## Navigation - Parent: [Blog Posts](https://prozak.org/index.md) - Previous: [008. The Web Is Meant to Be Personal](https://prozak.org/008-the-web-is-meant-to-be-personal.md) - Next: [006. Why #SelfHosting should be preferred](https://prozak.org/006-why-selfhosting-should-be-preferred.md)