The network engineer's perpetual headache goes something like this: You've got distributed systems that need to talk to each other, but they're stuck behind strict firewalls or carrier-grade NAT. Your security team has grudgingly opened exactly one UDP port, and that's all you're getting. Good luck maintaining reliable connections.
For years, the workaround has meant routing everything through centralized relay servers—functional, sure, but hardly elegant. Tailscale, the San Francisco-based networking startup, believes it has found something better.
On February 18, the company quietly made Peer Relays generally available, marking the final announcement of its Winter Update Week. The feature does something deceptively simple: it transforms any device in your Tailscale network into a high-throughput relay when direct connections won't form. End-to-end encryption stays intact. In some cases, the approach could even replace subnet routers entirely.
The Problem Tailscale Is Solving
Direct UDP connections between distributed systems fail more often than most people realize. Sometimes it's carrier-grade NAT. Sometimes it's a cloud environment where network administrators have locked down port access. Sometimes it's just the reality of enterprise networks in 2026.
Until now, Tailscale handled these failures by falling back to DERP—Designated Encrypted Relay for Packets, a TCP-based relay infrastructure the company operates. DERP works reliably, but TCP introduces throughput constraints that UDP avoids.
Peer Relays rewrite the fallback sequence. When a direct UDP path fails, Tailscale now attempts to route traffic through another device in your tailnet before touching DERP servers. Your data remains WireGuard encrypted end-to-end; the relay node simply forwards packets without any ability to decrypt them.
"Available on all Tailscale plans, including the free Personal plan," the company announced. That's a shift—perhaps more generous than some expected. During the beta period last October, Tailscale promised "two peer relays, for free, forever." The GA announcement doesn't restate specific quotas, which has left some users wondering whether paid tiers unlock additional capacity. The company hasn't clarified.
Four Months From Beta to Production
Tailscale first introduced Peer Relays in public beta on October 29, 2025. The path to general availability included unglamorous but essential infrastructure work: vertical scaling improvements, support for multiple UDP sockets where operating systems permit, better interface selection by connecting clients.
The December release (v1.92.1) added a feature that might seem niche but matters tremendously in production environments. Static endpoint support, exposed through a CLI flag, addresses scenarios where automatic discovery fails. If you're running relay nodes behind an AWS Network Load Balancer—not uncommon—you can now specify fixed IP and port pairs: tailscale set --relay-server-port=40000 --relay-server-static-endpoints="192.0.2.2:40000".
Observability arrived with GA as well. Two Prometheus-compatible metrics now let you track relay usage: forwarded packets and forwarded bytes. The ping UI across multiple platforms shows whether you're traversing a peer relay, a direct path, or DERP. Small touches, but they matter when you're debugging connection issues at 2 a.m.
Configuration Is Straightforward, Authorization Less So
Setting up a peer relay requires Tailscale v1.86 or newer. Any supported OS can run as a relay—except iOS, Apple TV, or Android, though devices on those platforms can still use relays without issue.
Designating a relay takes one command: tailscale set --relay-server-port=40000.
Authorization is where things get more involved. Tailscale handles this through its grants system using the tailscale.com/cap/relay capability. You specify which devices can use which relays, typically scoped by tags to prevent traffic from routing through unintended nodes. Only devices within the same tailnet can access your configured relays, and they still need policy authorization.
Connection selection happens automatically. Tailscale prefers direct UDP paths, falls back to peer relays when those fail, then hits DERP servers as a last resort. You can verify the active path with tailscale status, which displays "peer-relay" when in use. The tailscale ping command validates latency across different routes.
Real-World Deployment Patterns
Tailscale's announcement outlined three primary scenarios, though practitioners are already finding more.
First: sites with strict NAT or firewall policies where network teams will authorize exactly one UDP exception and not a port more. Second: constrained cloud environments, particularly infrastructure behind load balancers like AWS Network Load Balancer, where static endpoints become critical. Third: private subnet full-mesh topologies, where peer relays might replace subnet routers while preserving access to Tailscale SSH and MagicDNS.
That third use case sparked considerable discussion on Hacker News, where the announcement accumulated 464 points and 247 comments by February 20. Multiple practitioners described replacing DERP paths with in-datacenter peer relays to eliminate throughput bottlenecks—exactly the kind of architectural problem that doesn't make headlines but consumes hours of engineering time.
A Tailscale founder joined the thread to explain operational differences. DERP requires every server be reachable by all nodes, which makes self-hosting tricky without risking network splits. Peer relays are opportunistic. DERP uses TCP; peer relays stick with UDP. A staff member added that DERP still brokers initial connectivity, with connections "upgraded" to peer relay or direct when available. Peer relays are lightweight to deploy and fail gracefully.
How This Compares to Alternatives
Other mesh VPN tools offer relay capabilities, though with different architectural choices.
ZeroTier falls back to TCP relay service over HTTPS when UDP won't work—explicitly documented as slower. Nebula, from Defined Networking, added relay support in version 1.6.0. Any host can act as a relay, though the company recommends using nodes with public IPs and inbound UDP access.
Tailscale's differentiation comes down to integration. Relays are built into the client. They're authorized through the same policy system governing everything else. Selection happens automatically before the system touches external DERP infrastructure. The UDP data plane and WireGuard end-to-end encryption remain consistent regardless of connection type.
What We Still Don't Know
Some questions linger after GA. Tailscale's announcement includes a demo video but no performance benchmarks comparing peer relay throughput to DERP paths. Does routing through a peer node in the same datacenter deliver meaningfully better performance than hitting a geographically close DERP server? The company hasn't published numbers.
The pricing question persists as well. Does the beta's "two free relays" quota still apply, or do all plans genuinely support unlimited relay nodes? Reddit users have asked; official clarification hasn't emerged yet.
Still, for network teams managing distributed infrastructure across cloud providers, branch offices, or restrictive environments, peer relays address a tangible problem. Any well-connected node in your tailnet can become routing infrastructure without sacrificing security or requiring centralized relay deployments.
It's the kind of incremental infrastructure improvement that might not fundamentally transform how companies build networks. But it could eliminate enough architectural workarounds—and late-night debugging sessions—to matter considerably to the people actually running these systems.
