What is your primary use case for Tailscale?

My main use case for Tailscale is connecting to company internal systems due to GDPR requirements. The company is located in Germany with private servers in Germany, and I stay in the UK, so I use it to connect a point-to-site VPN connection from my home laptop to the private servers in Germany. I use Tailscale to create a secure connection. Apart from connecting to the internal systems, my main use case also provides a very nice interface with the CI pipeline. I connect Tailscale with my CI on GitHub Actions to allow me to do automatic deployments through the company's internal systems.

My main use case for Tailscale is access to internal resources and supporting clients, having replaced two different VPN products I was using previously. I have a number of applications that are running within my network. I have used the split DNS for accessing internal resources or supporting clients. Using split DNS with Tailscale has helped me manage access and support my clients by being able to use my internal DNS servers easily within the network without needing to have full tunnel connections. It has worked great for exposing particular applications to clients who are shared to particular nodes on my tailnet.

I use Tailscale to securely access remote Linux servers for tasks like SSH and system management without exposing services to the public internet. I also access a Linux server with the help of the RDP protocol.

I have been using Tailscale for three to four years now for personal use and for my volunteer and business work. My main use case for Tailscale is maintaining my personal network that I use for family and friends. It is easy to set up on pretty much any device. I use it for getting around port forwarding restrictions. For example, if I have a network on my school computer that I cannot port forward from, I can plug a VPN into it and port forward onto the VPN. Tailscale has been beneficial for hosting game servers with friends online. It is useful for situations where you need to get around firewalls and restrictions. You need a VPN to secure your networking because many of these game servers do not have encryption by default when they are small games. It is helpful to be able to set that up.

I mainly use Tailscale for remote access to my services. I have my whole server setup at home, which is a Proxmox cluster where I have a couple of services running on the backend, and I want to access those services remotely such as websites, some Docker containers, and some stacks. I install Tailscale on those applications so that I can access them remotely from my PC, whether at home or somewhere else. I turn on Tailscale and use it. I have a mixed environment in my backend, which includes a couple of Windows VMs, all my servers being Linux-based, my Mac environment, my iPhone, and my MacBook that I bring outside, so I install Tailscale on those devices. I also have my router in pfSense where I install Tailscale as well. I use Tailscale mostly on-premises to access all of my services. I could deploy it on cloud services such as AWS or Azure, but I already have my own environment, so everything is just within the premise.

We use Tailscale because we work for so many companies and each company has their own way of allowing their employees to connect to their infrastructure. We use Tailscale primarily for this purpose. For example, if there are Kubernetes clusters and engineers need to connect to the cluster to run their local applications against it, they connect using Tailscale. Additionally, we sometimes establish connections between on-premises and cloud environments. The first case involves ensuring that clients' employees have access to resources such as Kubernetes clusters, and the second case involves making connections between on-premises and cloud infrastructure, which makes it easier to connect. Let me give you a quick simple example of how I've used Tailscale for one of my clients. One of our clients wanted their engineers to be able to connect to the cluster internally instead of going through the public internet. We introduced them to Tailscale and set up the tailnet in Tailscale. The tailnet in Tailscale enabled us to install a Tailscale operator on each cluster. For instance, if our client has ten clusters, we install the Tailscale operator to expose the subnet router of each environment to the tailnet. Users can connect to the tailnet, and since the subnet router is already exposed to the tailnet, they can have access to their clusters through the subnet routers that are already exposed to the tailnet. This is how they can connect to the Kubernetes cluster. The reason is because we don't want users to connect through the public internet, and in the setup of the Kubernetes cluster, we only allowed one or two specific VPN connections. The only way we can allow employees to connect is through the tailnet. We installed a Tailscale subnet router on each cluster, which exposed the cluster VPC and networks in the tailnet. When employees connect to the tailnet, since the subnet router is already exposed to the tailnet, they can connect through the tailnet. There is another scenario where clients are trying to access their on-premises data to the cloud. Instead of using a cloud VPN, which would be a headache and could cost a lot, we decided to use Headscale. Headscale is similar to Tailscale because Tailscale is the enterprise version while Headscale is the open source alternative. We set up Tailscale for them on-premises and on the cloud. We set up a Tailscale tailnet on the cloud, and we set up a subnet router on-premises and another subnet router on the cloud. Both subnet routers will connect to the tailnet on the cloud and expose their VPCs. The one on the cloud will expose its VPC to the tailnet and the one on-premises will expose its VPCs to the tailnet. Machines on-premises can connect to machines on the cloud through the tailnet connection. The machine in the tailnet that is on-premises serves as a subnet router, and the one on the cloud also serves as a subnet router that routes traffic from the cloud to the tailnet, while the one on-premises serves as a subnet router that routes traffic from the on-premises to the tailnet. When a connection needs to be established, for example from the cloud to the on-premises, we create a routing policy that says if you want to talk to a specific IP which is on on-premises, go through the subnet router. The same thing applies with the on-premises as well. If you want to talk to a specific IP on the cloud, go through the on-premises subnet router. This way, it connects to the tailnet which has exposure of the cloud IPs, and the connection is made.

My main use case of Tailscale is for creating a VPN between Kubernetes services in Oracle Cloud, other servers, and my PC to connect with them, and I also use it to expose some services, so instead of port forwarding some services of Kubernetes, I use Tailscale, which makes things very easy and usable. Regarding exposing services, I use Grafana and for Tailscale, I expose that service so I can access it through the VPN instead of port forwarding the service. I also use it to expose a Kafka UI service, and I use Kafka in my job.

I use Tailscale to connect from outside my local network. I set it up on my server and on multiple clients, including my smartphone (iPhone), laptop, MacBook, and TVs, as well as my parents' TVs which are far from my home. Basically, all the devices that I use to connect to my server. For the most part, I use it to connect to my media server, which contains a collection of media. I also use it as a DNS server. Since my server has DNS, it spreads to all the devices which I am connected to. I also use it to connect via SSH to start other clients via Wake-on-LAN. I have been using it every day since June 2025, and it has never given me a problem. I also contacted support for some questions, and the support was great. I am actually really impressed by the product and its support.

Our main use case for Tailscale is to provide a VPN service where we can remotely log in or SSH into other devices on our network on Tailscale. We're using Headscale. We use it to perform updates, send information, ping certain cameras, and connect devices. The company did use ZeroTier before, but we chose Tailscale for this use case because it has definitely been the better option of the two, providing faster service and easier installation. I believe I have covered everything about our main use case. Tailscale is a very solid framework and is very useful for smaller companies if they want to start out or even bigger companies who want to have a robust network of devices that they want to manage.

My main use case for Tailscale is remote access to devices across networks. In my church context, I can give you a quick specific example of how I use Tailscale for remote access: we have a Reolink doorbell that I access over the local network via the Reolink client apps or MPV, and it also has a cloud solution that is slow and unreliable. I use Tailscale to remotely connect to the doorbell and its NVR, and it is quick, nice, smooth, and great. Another example is in my homelab, where I have many devices in a rack, and I use Tailscale to connect to any of them for fast, reliable access since they can all be in one Tailnet. In the church context, I can use subnet routing to fully expose the entire subnet that the doorbell is on and access various other server computers remotely. In the church context, I have a number of server computers running virtual machines on a Proxmox device, and I generally SSH into the Proxmox host or the virtual machines through Tailscale when I am outside of the church network. Tailscale gives me a list of all devices on the Tailnet, making it easy to copy the IP addresses and access everything flawlessly.

My main use case for Tailscale is accessing my home network when I'm outside. Essentially, it functions as a VPN. I use Tailscale to access my home network by connecting to a main machine that runs Tailscale, which is separate from my home server. This allows me to connect to it even when my home server goes down, and it serves as a subnet router so I can access my home network through that single machine instead of connecting every single virtual machine to the same Tailscale network.

Honestly, my main use case for Tailscale is my home lab and being able to access my home network devices using a Zero Trust platform that's fully secure. It has been so useful, especially for sharing some of my self-hosted services with family and friends. For example, I use Tailscale in my home lab by having it installed on all of my devices, like my personal laptop and PC, as well as on my servers. On my servers themselves, let's say I'm hosting a web page on port 3000. I could just use my Tailscale MagicDNS name and then the port, or I could just use the Tailscale IP and the port to access those web pages. So for example, I host things like VIQUINIA and some other things I can easily access. Another use case that I have for Tailscale in my home lab is I have it installed on my firewall, which is built with OPNsense. What I do is I have it set as an exit node and I also broadcast my entire subnet. So that way, it's as if I'm connecting to a regular VPN and have access to my full home network, not just the devices that have Tailscale installed on them. I can also funnel my traffic through my home network if I'm elsewhere. Since I have my own custom DNS set up, if I am using my network as an exit node, I get free ad-blocking wherever I go. For my organization, we use Tailscale for our database as a secure way to access our VPC. It's really great. It's an easy way for everyone to connect and disconnect. Nothing clunky, nothing being left behind, very lightweight, very nice UI, and very useful. For my home lab, it has been great because there are services you want to host, but you don't want to expose them to the public network, and using Tailscale gives you a very nice way of actually accessing that without having to deal with exposing things to public ports. I also really appreciate Tailscale services, which I forgot to mention, which involves hosting a service on Tailscale itself. Regarding metrics, I guess a lot of times it saves hours. Sometimes I forget something at home and if I use Tailscale, I can easily access my network and grab it, whereas usually I would have to drive back home. I feel that in itself is really huge.

We have been using Tailscale for about four or five months, and we have been using it from the beginning. For our main use case, we use Tailscale because it creates a peer-to-peer VPN mesh where we host our AWS infrastructure behind it, so the general web cannot directly access it. It is only accessible from authorized systems, such as the one that I have. A specific example of how we use Tailscale for this peer-to-peer VPN mesh in my daily work is that the entirety of our AWS infrastructure and systems that we use to build at Flyra are behind a private VPN that is accessible using Tailscale. The general web cannot access it, so we ensure that there is nothing unauthorized accessing our servers. Authorized and recognized systems are only able to access the infrastructure and the resources that we want restricted, and that is where Tailscale comes in. About my main use case, I am fully aware that it is end-to-end encrypted. We maintain access using ACLs, which allows us to fine-tune the fine-grained rules for who can connect and to what.