Tailscale Peer Relays exits beta, now generally available

Tailscale Peer Relays reach general availability

Tailscale launched Peer Relays for general availability on February 18, 2026, providing a production-ready way for users to run their own high-throughput relay nodes. This release moves the feature out of beta and introduces several performance optimizations designed for restrictive enterprise environments. Any Tailscale node can now function as a relay to maintain connectivity when direct peer-to-peer paths are blocked by firewalls or complex NAT configurations.

The service previously relied on a global network of Designated Encrypted Relay for Packets (DERP) servers to bridge connections. While DERP servers ensure connectivity, they are shared resources that can introduce latency depending on a user's physical distance from the nearest Tailscale-managed data center. Peer Relays allow organizations to host these relay points within their own infrastructure, keeping traffic on private hardware and improving throughput for internal users.

This update addresses the "hard NAT" problem where two devices cannot establish a direct WireGuard tunnel. By deploying a Peer Relay on a node with a more permissive network configuration, users can route encrypted traffic through that node to reach isolated peers. The system maintains end-to-end encryption, meaning the relay node cannot inspect the contents of the packets it forwards.

Improving throughput and connection quality

The general availability release includes significant code optimizations to increase the volume of data a single relay can handle. Tailscale engineers reduced lock contention within the relay software, allowing the application to process packets more efficiently across multiple CPU cores. This change is most noticeable in high-traffic environments where dozens of clients connect through a single relay simultaneously.

Tailscale now spreads relay traffic across multiple UDP sockets where the operating system supports it. This architectural change prevents the networking stack from becoming a bottleneck during peak usage. By utilizing multiple sockets, the relay can better handle the high-frequency packet delivery required for video streaming, large file transfers, and real-time database replication.

Connecting clients have also received an intelligence upgrade for selecting the best path to a relay. When a relay node offers multiple interfaces or address families, such as IPv4 and IPv6, the client now automatically selects the most optimal route. This faster bootstrapping process reduces the "time to first packet" and ensures that the connection remains stable even if one network path experiences degradation.

• Lock contention fixes: Reduces internal software delays under heavy load.
• Multi-UDP socket support: Increases total bandwidth capacity per relay node.
• Optimized path selection: Clients pick the fastest available address family.
• End-to-end encryption: Relays forward packets without access to private keys.

Solving restrictive cloud networking issues

Public cloud environments like AWS, Google Cloud, and Azure often present unique challenges for peer-to-peer networking. Strict security groups and network load balancers can prevent Tailscale’s automatic endpoint discovery from working correctly. In these scenarios, instances might be hidden behind layers of NAT that standard STUN (Session Traversal Utilities for NAT) requests cannot penetrate.

Tailscale introduced a new flag, --relay-server-static-endpoints, to solve this specific discovery failure. Administrators can now use the tailscale set command to manually advertise fixed IP:port pairs to the rest of the tailnet. This allows a Peer Relay to sit behind an AWS Network Load Balancer (NLB) or a static firewall rule while remaining reachable by external clients.

This feature effectively replaces the need for complex subnet router configurations in certain high-security zones. Because Peer Relays are "tailnet-native," they support core features like Tailscale SSH and MagicDNS out of the box. Users can now maintain a full-mesh feel even when the underlying physical network is strictly hierarchical or siloed into private subnets.

Better visibility for network admins

The move to general availability brings Peer Relays into Tailscale’s primary observability stack. Network administrators no longer have to guess why a specific connection is slow or whether a relay is currently active. The tailscale ping command now explicitly identifies if a relay is in use and provides real-time latency data for that specific path.

For long-term monitoring, Peer Relays now export detailed telemetry that integrates with Prometheus and Grafana. These metrics allow teams to track the health and load of their relay infrastructure over time. This data is essential for capacity planning, as it reveals when a specific relay node is reaching its bandwidth or CPU limits.

Specific metrics now available for export include:

• tailscaled_peer_relay_forwarded_packets_total: The cumulative number of packets handled.
• tailscaled_peer_relay_forwarded_bytes_total: Total data volume processed by the relay.
• Reachability status: Real-time confirmation that the relay is accessible to the tailnet.
• Latency tracking: Measurement of the overhead added by the relay hop.

These tools make it easier to audit network traffic and troubleshoot connectivity issues. If a user reports a slow connection, an admin can quickly check the Grafana dashboard to see if the traffic is being relayed and if that relay is currently saturated. This level of transparency is a requirement for enterprise teams managing hundreds or thousands of nodes.

Deploying relays across all plans

Tailscale is making Peer Relays available to all users, including those on the Personal free plan. This decision ensures that individual developers and hobbyists can bypass restrictive home or university networks without relying solely on Tailscale’s public DERP infrastructure. For larger organizations, the feature is included in Starter, Premium, and Enterprise tiers without additional per-node fees.

The deployment process is designed to be incremental. Organizations can start by enabling a single Peer Relay in a problematic branch office and slowly expand the footprint as needed. Because the system is controlled through Access Control Lists (ACLs), admins can use grants to restrict which users or tags are allowed to use a specific relay. This prevents unauthorized nodes from consuming the relay's bandwidth.

Peer Relays represent a shift in how Tailscale handles "uncooperative" networks. By giving users the tools to build their own reliable paths, the company is reducing the reliance on central infrastructure while maintaining the ease of use that defines the product. It is a pragmatic solution for the messy reality of modern corporate firewalls and cloud security policies.

To get started, users must update to the latest Tailscale client version and enable the relay functionality via the CLI. Detailed documentation is now live, covering everything from basic setup to advanced load balancer integration. For teams with specific high-throughput requirements, Tailscale is offering direct deployment support to ensure the relays meet production performance targets.