Learn Tailscale - Latest Stable Features (1.96 - 1.102)

#Introduction

Tailscale moves fast. If you've ignored the changelog for a few months, you'll miss a lot of new features — and some of them change how a tailnet works fundamentally.

Episode 19 covers the latest stable features from releases 1.96 to 1.102: Peer Relays for peer-to-peer relaying, Tailscale Services with virtual IPs, Aperture as an AI gateway, the windowed macOS UI, group sync for Entra ID and Google Workspace, and OAuth device provisioning. We also trace client evolution with auto-update and the fast release model.

Understanding the latest features helps you make the right architecture decisions — because many old patterns now have better replacements.

#Modern Features in Recent Stable Releases

#Tailscale Peer Relays

Peer Relays let a node act as a relay for other nodes in the tailnet, forwarding traffic for devices that can't do a direct connection. The difference from DERP: relaying happens between peers, so operators can choose a hop that's geographically closer.

In 2026 this feature reached GA and can be configured via ACLs, so you can limit which nodes are allowed to relay:

{
  "groups": {
    "relay-nodes": ["user1@example.com"]
  },
  "nodeAttrs": [
    {
      "target": ["tag:server"],
      "attr": ["peer-relay"]
    }
  ],
  "acls": [
    {
      "action": "accept",
      "src": ["tag:server"],
      "dst": ["tag:server:*"]
    }
  ]
}

The ACL file above marks nodes tagged tag:server with the peer-relay attribute via nodeAttrs. Marked nodes may serve relays, and everyone else automatically gets a healthier path with no per-client configuration.

#Tailscale Services

Tailscale Services introduces the concept of a virtual IP for services, not just devices. A service is represented by a stable virtual address, so applications don't have to track physical node IPs that may move around.

This pattern is reminiscent of Services in Kubernetes (episode 16): clients call one address, and Tailscale handles routing to a healthy node. For microservices workloads, this eliminates the hardcoded IPs that have long been a source of failures.

#Aperture by Tailscale

Aperture by Tailscale is a gateway for AI workloads. Aperture provides a shared gateway that can restrict access to AI models and keep data encrypted on a private network — a natural companion for tailnets running self-hosted LLMs or using external APIs in a controlled way.

#Windowed macOS UI and Group Sync

For macOS users, Tailscale now provides a windowed UI that replaces the menu bar app and shows node status, traffic, and exit controls in a single, tidier window.

Group sync connects groups from Entra ID or Google Workspace directly to tailnet ACLs. Once synced, identity provider groups can be used directly as a policy source:

{
  "groups": {
    "group:engineering": ["engineering@example.com"]
  },
  "acls": [
    {
      "action": "accept",
      "src": ["group:engineering"],
      "dst": ["tag:dev-server:*"]
    }
  ]
}

With this pattern, members who leave a group in the provider automatically lose tailnet access — without touching the admin console.

#OAuth Device Provisioning

OAuth apps (covered in episode 17) can now be used for device provisioning at scale: devices request a token through the OAuth flow instead of using a static auth key that could leak. This makes mass provisioning safer and more auditable.

#Client Evolution and Releases

#Auto-Update

Manually keeping up with fast releases is a burden. The solution:

sudo tailscale set --auto-update=true
tailscale set --auto-update=true --help

The sudo tailscale set --auto-update=true command makes the node update itself to the latest stable release. For large fleets, the auto-update policy can be enforced from the ACL with nodeAttrs, so all nodes with a certain tag are always up to date.

#Fast Releases and the Stable Support Model

From v1.98 to v1.102, Tailscale shipped stable features more often than before. The consequence: you need to choose your mode — following the latest stable release to enjoy features, or holding back to an older version for maximum stability on critical devices.

For production servers, combine auto-update with testing in staging first. Don't let production nodes fall too far behind, because large version gaps often complicate debugging.

#Verifying Features on Your Nodes

#Make Sure Your Version Supports the Feature

tailscale version
tailscale version --json
tailscale update

The combination of tailscale version and tailscale update helps ensure your node is on the latest release supporting the features above. Note this version in your team runbook so everyone knows the baseline in use.

#Practices for Using New Features

• Always verify the version before using a new feature.
• Document the features you use in the team runbook.
• Enable auto-update on non-critical devices first.
• Take advantage of group sync to reduce manual ACL changes.
• Evaluate Peer Relays and Services before adding new nodes.

#Closing

Episode 19 closed the knowledge gap: you now know the latest stable features from 1.96 to 1.102 and how to adopt them safely.

Key takeaways:

• Peer Relays enable peer-to-peer relaying and are now GA.
• Tailscale Services offer virtual IPs for services.
• Aperture is an AI gateway you can integrate into a tailnet.
• Group sync connects Entra ID and Google Workspace to ACLs.
• Auto-update keeps fleets on the latest stable release.
• The fast release model demands a disciplined adoption strategy.

In the next episode, episode 20, we'll cover ecosystem integrations — Tailscale on Synology DSM, Proxmox, OpenWrt routers, and headless servers, use on VPS, AWS, and GCP, plus Headscale as a self-hosted control plane alternative for full control.