As much as I adore all my self-hosted tools, there are certain services that I simply couldn’t survive without. Pulse, for instance, is the sole monitoring utility for my home lab, especially since it pairs well with my server rigs, Docker hubs, and Proxmox workstations. Likewise, my Kopia, PBS, and TrueNAS instances are the sole reason I haven’t lost any data despite some catastrophic failures in my experiments.

Then you’ve got Tailscale, which is the most essential aspect of my network stack, even though it’s technically a third-party service that relies on external servers. That’s because it single-handedly solved my port-forwarding and dynamic DNS problems – all while providing an ultra-simple setup procedure.

As a mesh VPN, Tailscale bridges my local and remote nodes

Perfect for bypassing CGNAT restrictions without compromising my security (or my wallet)

As much as I’d love to self-host my own virtual private network, the Carrier Grade NAT provisions used by my ISP act as a major bottleneck. Since my network stack is locked behind CGNAT, I share the same public IP address with a bunch of other folks – and this is a massive problem when I need to enable port forwarding, let alone deploy a local VPN for safer remote access.

Between renting a VPS with a static public IPv4 address and tinkering with paid VPNs, there are a couple of solutions at my disposal. But nothing is as cost-effective or simple as installing Tailscale on a node, connecting it to my tailnet using the official admin console, and calling it a day.

The best part? Despite its simple nature, Tailscale is extremely secure for home lab operations. Since my tailnet can only be accessed by the devices connected to it, I don’t have to worry about my systems getting compromised by the scary recesses of the Internet. The Tailscale admin console also supports robust access control mechanisms, and I can fine-tune the rules to grant selective permissions to certain rigs. Plus, I’ve configured the Tailscale lock for my tailnet to further bolster my security. If you haven’t heard of it, this neat trick forces new nodes to get approved by certain pre-configured devices before they can connect to my tailnet.

MagicDNS makes accessing my virtual guests a cakewalk

Considering that Tailscale supplies its own IP addresses for the devices in my tailnet, I’d have to remember yet another set of IPv4 numbers when I try to access my home lab from external networks. Fortunately, Tailscale supports MagicDNS to solve this conundrum. Similar to the reverse proxy + local DNS records combo, MagicDNS lets me create easy-to-input domain names for my container arsenal. Except, it’s significantly easier to use, as all I have to do is remember the machine name (which I can modify on Tailscale’s admin console) and the tailnet name associated with my network. Better yet, I can even use the machine name to quickly SSH into the devices paired with my tailnet when I need to troubleshoot broken services.

Tailscale Funnels solve my dynamic DNS woes

An easy way to share my self-hosted tools with friends

CGNAT is already my biggest hurdle for accessing my home lab remotely, and it’s just as problematic when I need to share my self-hosted tools with friends and family. Without Tailscale, I’d have to configure dynamic DNS to assign a static domain name to the ever-changing public IP address of a self-hosted utility, on top of enabling port-forwarding on my router.

Now, I always configure Tailscale tunnels with extra authentication tools and robust ACLs when I want to share my apps with other folks for long periods. But when I need to grant them temporary remote access, I rely on Tailscale Funnels instead. You see, Funnels assign full-fledged URLs to any services I link with my tailnet, allowing any device to access them – including systems that aren’t connected to my account. Of course, exposing apps on my LAN to the Internet would make them vulnerable to hackers, botnets, and other malicious entities, which is why it’s a temporary solution. But even then, Authentik (or another SSO server), Fail2Ban, and other authentication platforms can curb the chances of hackers laying siege on my home network.

A Tailscale subnet router works well for my entire home lab

And it makes my tailnet more organized

I’ve got numerous virtual guests, server rigs, NAS units, and everyday machines hooked up to my tailnet. Truth be told, I probably wouldn’t hit the max 100 device limit unless I go bonkers with my Tailscale installations. But managing my tailnet becomes a pain when I need to sift through numerous devices on the admin console. Not to mention, all the extra time I have to waste when installing Tailscale on new rigs, containers, and virtual machines.

That’s when I came across the neat concept of a Tailscale subnet router. Rather than deploying Tailscale manually on every home lab-centric machine, I could install it in a single system in my home lab and use it to access everything on my LAN. In my case, the system in question is an unprivileged LXC deployed on Proxmox. Of course, I still need to install Tailscale on the remote NAS in my 3-2-1 backup workflow and the devices I carry with me when I have to stay out of my goblin lair for extended periods. But since it single-handedly makes my entire home lab accessible to every device in my tailnet, I’d say it’s one of the most essential tools in my self-hosted arsenal.