Traditional VPNs are a pain. You need a VPN server to manage and maintain, you need to configure firewall rules every time your infrastructure changes, and the user experience of connecting — especially on mobile or in environments with restrictive firewalls — is unreliable enough that half your team avoids it.

Tailscale takes a different approach. Rather than routing all traffic through a central server, it builds a direct encrypted peer-to-peer mesh between your devices using WireGuard. Every device in your Tailscale network (your “tailnet”) can reach every other device directly, authenticated by identity, without you managing any servers or firewall rules.

For developer teams, this turns out to solve several annoying problems at once.

The Basics of How It Works

When you install the Tailscale client on a device, it authenticates via your identity provider (Google Workspace, GitHub, Microsoft, or Tailscale’s own auth) and gets a stable IP address in the 100.x.x.x range (the Carrier-Grade NAT range Tailscale uses). Every device in your organisation gets such an address, and they can all reach each other using those addresses — or, more usefully, using Magic DNS hostnames like laptop.your-org.ts.net.

The direct peer-to-peer connections are established using STUN and DERP (Tailscale’s relay infrastructure for when direct connections aren’t possible). In most cases you get direct, low-latency connections. Where NAT or firewalls prevent direct connections, traffic routes through Tailscale’s relay servers with minimal added latency.

The control plane (authentication, key distribution, access policy) runs on Tailscale’s servers. The actual traffic flows directly between your devices — Tailscale can’t read it.

Remote Development Access

Here’s the thing: accessing a remote development server or staging environment with SSH usually means either a bastion host (another thing to manage), IP whitelisting (breaks when you work from a coffee shop), or a traditional VPN (painful to set up and maintain).

With Tailscale, you add the development server to your tailnet, and it’s reachable from any device also on your tailnet using its Magic DNS hostname. No static IPs. No firewall rules. No bastion.

# SSH to dev server from anywhere
ssh user@dev-server.your-org.ts.net

# Port forward a remote database for local development
ssh -L 5432:localhost:5432 user@db-server.your-org.ts.net

This also works for services running on the server — if your staging environment runs on port 8080, you can reach it at http://dev-server.your-org.ts.net:8080 from your laptop without any tunnel setup or port forwarding configuration.

For teams with remote developers or multiple offices, this is a significant quality-of-life improvement. It also works well for IoT and edge devices — a Raspberry Pi or industrial edge device added to your tailnet is accessible for SSH and debugging from anywhere without any networking gymnastics.

Sharing Localhost

One of the more immediately useful Tailscale features for development is the ability to share a locally running service with a colleague or a webhook endpoint without deploying anything.

Funnel (available on paid plans) exposes a local service to the public internet via a Tailscale-managed URL with TLS. This is Tailscale’s answer to ngrok:

# Expose local port 3000 to the internet
tailscale funnel 3000
# Your service is now at https://laptop.your-org.ts.net/

For testing webhooks from Stripe, GitHub, or any other service that needs to reach your local development environment, Funnel works cleanly without the rate limits or session duration issues you hit on ngrok’s free tier.

Serve (available to all plans) exposes a local service within your tailnet only — visible to your team but not the public internet. Useful for sharing a work-in-progress feature with a colleague without deploying to staging.

Subnet Routing and Service-to-Service Networking

Beyond device-to-device access, Tailscale can route traffic to entire subnets through a designated node acting as a subnet router. This means your cloud VPC or on-premises network can be reachable to all devices on your tailnet without adding the Tailscale client to every individual machine in the network.

# On the subnet router, advertise your VPC subnet
tailscale up --advertise-routes=10.0.0.0/16

After approving the route in the admin console, any device on your tailnet can reach your VPC’s private IPs directly. This is how you connect developer laptops to a private RDS database in AWS, or reach an internal Kubernetes cluster from CI without opening firewall ports.

For inter-service communication in distributed systems — microservices that need to reach each other across different cloud regions, environments, or even different cloud providers — Tailscale provides a persistent, authenticated network layer without the complexity of service meshes for simpler use cases.

Access Control

Tailscale’s ACL system lets you define which devices and users can reach which others, expressed in a declarative JSON policy. This is where it starts to look like real network security rather than a convenience tool:

{
  "acls": [
    {"action": "accept", "src": ["group:developers"], "dst": ["tag:dev-servers:*"]},
    {"action": "accept", "src": ["tag:ci-runners"], "dst": ["tag:staging:443"]}
  ]
}

Production databases can be restricted to specific users or groups. CI runners can be allowed to reach only staging environments, not production. This is useful governance for teams that are growing and need to be more deliberate about who has access to what.

Pricing and When It’s Worth It

Tailscale has a free tier for personal use (up to 3 users, 100 devices). The Personal plan at $48/user/year adds more devices and features like subnet routing approvals and Funnel. Teams plan adds SSO integration, user management, and priority support.

For teams already paying for a VPN solution or spending time managing bastion hosts and firewall rules, Tailscale’s pricing is usually cost-neutral or cheaper when you factor in the reduced operational overhead. The main question is whether your team’s networking needs are simple enough that Tailscale handles them, or complex enough that you need more traditional enterprise network tooling.

Fair enough — if you have dedicated network engineering resources and complex multi-cloud networking requirements, Tailscale is one layer in a larger picture. For a team of 5-50 developers who want remote access, localhost sharing, and service connectivity without managing infrastructure, it’s a strong default choice.