Struggling with the limitations of public exposure for your homelab? Initially, Cloudflare Tunnels seemed like a magic bullet for accessing my self-hosted services—until latency, free-tier restrictions, and security anxieties began to mount. This article delves into the journey of moving beyond Cloudflare Tunnels to a more robust, private, and secure remote access solution. Discover how Tailscale, a zero-config VPN, combined with Caddy, an automatic HTTPS reverse proxy, transformed my homelab security and remote experience, providing a “boring” setup that consistently works.
The Cloudflare Tunnel Conundrum for Self-Hosted Services
Setting up Cloudflare Tunnels for the first time in my homelab felt like unlocking a kind of superpower. I didn’t want to open ports, deal with SSL renewal hassles, or wrestle with dynamic DNS. With Cloudflare Tunnels, I could access my self-hosted instances of Immich, NextCloud, Jellyfin, Vaultwarden, and other services from anywhere. I happily mapped all of them to my subdomain and figured it was the best way to run my homelab. Over time, small frustrations accumulated until they became impossible to ignore. Here’s why I switched from Cloudflare Tunnels to Tailscale and Caddy — and haven’t looked back.
Like many homelab beginners, I started by exposing my Pi-hole dashboard. Soon, I had Home Assistant, Jellyfin, Immich, Portainer, and a few other network tools like NetAlertX, all mapped to subdomains via Cloudflare Tunnels. I often noticed latency when accessing my self-hosted services away from home. It was tolerable for viewing dashboards, but it became a real problem when using Home Assistant, streaming videos remotely, and transferring files.
I have always felt anxious about the Terms of Service that Cloudflare lays down for Tunnels. The free tier discourages streaming large video files through the tunnels and is often considered a “gray area.” Though penalties are rare, an abuse report can take down my services at any time. That low-key fear existed like a mild headache. On the free tier, I couldn’t upload files larger than 100 MB at a time, severely hampering file transfers from my laptop to the home server. On top of that, the outages also took down my access to my homelab. In the end, I realized I was the only one accessing my homelab remotely, making public exposure unnecessary.
Tailscale: Redefining Private Remote Access for Your Homelab
Building Your Secure Mesh Network
I realized I didn’t really need to expose my homelab to the internet, at least not all of its services. My primary goal was secure remote access to my self-hosted services, dashboards, and home server. Tailscale assigns every device a private IP and a MagicDNS hostname within your tailnet, creating a secure, private mesh network.
Setting up Tailscale on my phone, computer, and home server took less than 15 minutes. Each device got a specific IP address in a private mesh network, and I enabled the MagicDNS as well. After that, I can reach my home server from anywhere using Tailnet names, eliminating the need to remember complex IPs.
The free tier is sufficient for my homelab and the services running on it. Yes, Tailscale still has a third-party dependency for its coordination server, but I’ve experienced few outages so far. The best part is that my devices get to communicate directly over WireGuard even if the coordination layer hiccups, ensuring robust connectivity. **Tip:** Tailscale recently introduced “subnet routers” which allow you to expose entire subnets behind a Tailscale node, making it even easier to provide private access to multiple devices without installing Tailscale on every single one.
My homelab and self-hosted services were no longer publicly accessible. I didn’t have to change anything on my router or open ports. Since I am the only one who can remotely access my homelab, Tailscale checks all the boxes for my enhanced homelab security needs.
Caddy: The Intelligent Reverse Proxy for Internal Services
Eliminating Browser Security Warnings with Automatic TLS
Browser security warnings were annoying enough, but Immich’s mobile app refused to work with plain HTTP. So I added Caddy as an internal reverse proxy. It handles TLS termination on port 443 and issues internal certificates through its own Certificate Authority. Then, it routes everything by hostname.
That frees me from having to remember the IP address and port for every service running in my homelab. Once I trusted Caddy’s root CA on all my devices, the browser warnings disappeared everywhere, providing a seamless user experience.
I battled with NGINX configs before, and wasn’t going back to using it as a reverse proxy. Traefik would make sense if I were running Docker Swarm with dynamic service discovery while running dozens of containers. But I have a stable and small stack, making Caddy’s simplicity and automatic TLS a perfect fit.
Lastly, I pointed Caddy at Tailnet names instead of hardcoding the IP addresses. Since it resolves hostnames dynamically via MagicDNS, IP address changes in my Tailscale network don’t break anything, adding another layer of resilience.
The Optimal Homelab Stack: Tailscale + Caddy
A Focus on Privacy and Reliability
I finally have a stack of self-hosted services that I can access remotely without an issue. All thanks to Tailscale and Caddy, there’s no public footprint of my homelab anywhere, significantly boosting my homelab security. Also, I haven’t experienced any outages since my setup no longer depends on third-party public services for access.
Balancing Convenience and Sharing Needs
The only drawback is that I had to give up the simplicity of simply sharing public access or links to media in my homelab. However, I run the homelab for myself and not for others. If I ever have to share a file or folder with public access, I prefer to serve it through Tailscale Funnel. After all, it’s my personal homelab, and your use case for remote access might be different.
Related
5 reasons I dumped Nginx Proxy Manager for Caddy
I’ve made the switch from Nginx Proxy Manager to Caddy, and I’m not looking back.
Achieving a “Boring” Yet Robust Self-Hosting Experience
Switching to Tailscale and Caddy changed the way I think about remote access for my self-hosted services. I no longer publish services in my homelab publicly and then try to secure them. Instead, I keep them private and connect to them securely, enhancing overall homelab security. This setup feels leaner and safer, and it aligns with how I want to run my homelab. Cloudflare Tunnels were the wrong long-term solution for me. After using Tailscale and Caddy, my homelab no longer feels like it’s hosted on the internet, but rather a secure, private extension of my personal network.
FAQ
Question 1: Why not just use a traditional VPN for remote access?
Answer 1: While traditional VPNs provide secure remote access, they often require manual configuration on your router, dealing with port forwarding, and maintaining a dynamic DNS service. Tailscale simplifies this immensely with zero configuration, automatic peer-to-peer WireGuard connections, and MagicDNS, making it far more user-friendly for homelab environments without compromising homelab security.
Question 2: Is Caddy suitable for very large, complex self-hosted setups with many services?
Answer 2: Caddy excels in simplicity and automatic TLS for small to medium self-hosted services stacks. For very large deployments with hundreds of microservices, dynamic service discovery, and complex traffic routing, tools like Traefik or even NGINX with extensive custom configurations might offer more granular control and features. However, for most homelabs, Caddy’s ease of use as a reverse proxy is unbeatable.
Question 3: What if I occasionally need to share a specific self-hosted service publicly, even with this setup?
Answer 3: If you have a specific need to share a service publicly, even temporarily, Tailscale offers a feature called “Funnel.” This allows you to expose a particular service from your Tailscale network to the public internet via Cloudflare (handled by Tailscale), without exposing your entire homelab or requiring complex port forwarding. It’s a great way to retain the privacy of most services while offering selective public access when necessary.