Tailscale Release Notes

Less memory overhead for small packets

If you’ve been following Tailscale at all, you know we’re really just a bunch of geeks who care a lot about internet connectivity. One thing we love to talk about is NAT Traversal. That’s one of the core value-adds with Tailscale: we tamed NAT. Not every network is friendly, but Tailscale can still find a path in a wide range of conditions. That’s not the only important thing for an internet protocol: the data plane also has to be performant.

Over the years we’ve been investing in making Tailscale fast. We started by increasing TCP throughput on Linux devices. Then we made significant breakthroughs in wireguard-go to surpass 10Gb/s on bare metal. We later leveraged segmentation offloads to increase throughput over 4x for UDP-based applications. Alongside these improvements to our data plane, we built primitives like Tailscale Peer Relays, which can improve network performance in tricky conditions.

All of this has made Tailscale practical for more performance-sensitive workloads. It means you can use Tailscale for continuous integration, agentic workflows, remote development environments, robotic edge devices, heavy data and telemetry workloads, and more. Tailscale helps those devices connect across a wide range of network conditions.

So yeah, we think Tailscale is fast. But we also think we can make it faster.

Today we’ll detail how we’re boosting throughput for app connectors, subnet routers, and exit nodes, with some multi-queue technology (landing in the second half of 2026). We’ll also preview some throughput and memory overhead improvements we’re deploying in upcoming stable client releases. And we’ll look at some performance tooling issues we want to solve for our customers.

Most network packets are tiny, like 1 KiB. But to use Linux’s most efficient throughput tools, like Generic Receive Offload (GRO), Tailscale has to be ready to accept 64 KiB of traffic at once. It’s a bit like container shipping: the ports, ships, and trucks are built for one container shape, however full it happens to be.

Tailscale has to unpack those containers—every packet gets decrypted and delivered on its own. The wireguard-go implementation that informs Tailscale’s cryptography and networking essentials, only offers one 64 KiB buffer size to unpack into. So a 1 KiB packet is copied into its own 64 KiB buffer, every time. That’s a rich optimization target.

On Linux and Android, Tailscale now leaves those packets where they landed. It identifies where each one starts and ends inside the single large read instead of copying it somewhere new. Small packets stay small in memory, many share one allocation, and they spend less time being copied. In itself, this led to a roughly 5% speed-up in many network configurations.

Separately, we shortened packet queues—the lines packets wait in between stages of the pipeline. The queues are there to absorb bursts of traffic. Testing showed that most of that depth went unused, while shorter queues meant less waiting time and less memory overhead.

What do we do with all that freed-up memory space? We passed the savings on to some of the hardest-working nodes: subnet routers and app connectors.

Multi-queue for subnet routers, app connectors, and exit nodes

Subnet routers can look completely different across different tailnets. For someone running a small homelab network, a subnet router can easily handle a small set of 192.168.x.y non-Tailscale devices. A subnet router that fronts a cloud deployment, one with hundreds of peers, will carry substantially more traffic.

Until recently, subnet routers, app connectors, and exit nodes processed packets for multiple independent streams in one ordered, single-thread pipeline. That meant a single lane was shared across many connections, because a receiving application must never see its own packets arrive out of order.

Having reduced our memory footprint, we had capacity to implement a multi-queue system: several lanes instead of one, scaled to the machine’s resources rather than the number of peers. Each stream of packets gets a lane and stays there, while the lanes run in parallel, allowing work to spread across CPU cores.

It results in higher aggregate capacity and lower delay between receiving and forwarding packets for subnet routers and app connectors. Hardware you already have gets used more efficiently. App connectors and exit nodes, typically serving many users with short-lived connections, get a particularly noticeable boost.

“This translates into lower latency, essentially faster processing of data from the moment we read it off the wire to the moment we send it to the OS,” said Alex Valiushko, member of technical staff at Tailscale.

Throughput gains with writev

Taking advantage of Linux’s writev capabilities in the Tailscale client, Tailscale can pass multiple pieces of packet data to the Linux kernel in one operation, rather than having to copy and combine those pieces before passing them to the kernel. The v in writev stands for “vector”: Tailscale can describe separate pieces of data that need to be moved, without moving them. It means fewer copies of packet data in memory, fewer write operations, and higher throughput.

Faster startup with netmap caching

For now, these speed-ups are available only on Linux and, where applicable, Android systems. But we’ve also been working on features that apply to other systems. Tailscale clients will soon be able to use netmap caching to start more quickly in many conditions.

A machine connecting to Tailscale usually starts by connecting to Tailscale’s control plane, in something like 100 milliseconds on a typical network. The machine authenticates and gets a "network map" (netmap) describing the devices it can reach and how to reach them. This startup process should feel fast, maybe instantaneous, and with a good network connection, it typically does.

But when you're on bad airplane Wi-Fi, or inside a hotel with aggressive filtering, or other not-great connectivity setups, it can take a while for the machine to reach the control plane—and sometimes you may not be able to reach it at all. It’s often not obvious where the problem is, but the effect is that you can’t reach other devices.

Even under ideal network conditions, 100 milliseconds of startup latency may be too much for some latency-sensitive workloads.

Netmap caching helps machines get connected when the control plane is not quickly reachable. When it's enabled, each device on your tailnet stores a copy of the netmap on disk. When a device starts up, it can use that cached copy to establish connections with other devices on the tailnet, until it's able to contact the control plane to get the latest info. (These connections are negotiated between the devices directly, and Tailscale does not see any of the traffic, as usual).

“Bad network conditions—that’s really the space where people can get a lot of utility out of netmap caching,” said Claus Lensbøl, member of technical staff. “[A device client says], ‘You know what? We haven’t talked to control yet. We’ll probably get there soon. In the meantime, you can still start doing something.’”

There are a few limitations. Caching can only work if the device has previously connected to the tailnet at least once, to fetch a network map from the control plane. In addition, netmap caching requires the device to have persistent disk space to store the cache. We’ve taken care to minimize unnecessary disk writes, but in some cases you may not want to enable it. For example, on exceptionally large tailnets, updating a cache may require a lot of disk traffic. Likewise, devices that use slow or wear-sensitive storage like SD cards may prefer not to enable netmap caching.

For most devices on most tailnets, though, this feature can notably speed up how quickly devices can establish contact with each other at startup. We’ve seen tailnets with poor control plane reachability start sending through the data plane, on a “warm” cache start, one to two orders of magnitude faster than from a “cold” start. For devices facing variable startup latency, or far away from a DERP server or the control plane, the benefits are particularly tangible.

When you can see all these speed-ups

Memory reduction via buffer changes (Linux/Android) is expected in the v1.104 client.

Multi-queue to benefit subnet routers and app connectors is planned for a release after v1.104.

Throughput gains (Linux/Android) were partially implemented in spring 2026; leveraging the additional gains in memory and throughput is planned for a release after v1.104.

Netmap caching is available as a feature flag in the current Tailscale client; it is expected to arrive by default in v1.104, following further testing. Mobile clients are expected to have the feature in a release after v1.104.

Performance is still difficult to diagnose and test

Sure, we think Tailscale is fast. But you shouldn't have to trust us on that. That’s why we’re exploring a Tailscale-aware monitoring and testing toolkit. We want to give our customers the tooling they need to test, diagnose, and understand their network configuration, in a way that’s Tailscale-native.

Here are the gaps we see in modern performance testing:

• Distribution tax: Most performance tooling is point-to-point, and requires you to install something on every endpoint.

• Workflows are rigid: It’s pretty easy to run the wrong test, get the wrong output, and chase a problem that’s not there.

• Protocol support: Many tools don’t support newer protocols, such as QUIC and HTTP/3.

• Tailscale-awareness: General-purpose tooling is not Tailscale-native. It can’t tell you if a connection is using DERP or is direct, whether a peer relay might help, or how the connection path changes over time.

Existing tooling doesn't understand Tailscale-native paths and states. So we're exploring tooling that does.

Help us shape the future of performance testing at Tailscale.

All Platforms

Fixed: Resolved an issue that could cause a loss in connectivity when a netmap update occurs near the time of reauthentication.

macOS

Fixed: Resolved an issue that could prevent exit nodes from appearing when using a custom coordination server.

iOS

Fixed: Resolved an issue that could prevent exit nodes from appearing when using a custom coordination server.

tvOS

Fixed: Resolved an issue that could prevent exit nodes from appearing when using a custom coordination server.

Fixed: Resolved an issue that prevented the VPN tunnel from automatically starting on a cold boot.

In-cluster Tailscale Peer Relays

Over the past few months, we’ve chosen to tackle some of the most stubborn issues of the Tailscale Kubernetes Operator to improve performance, connectivity, and scale:

• Cross-cluster connections being routed through DERP servers
• IPv6 connectivity
• Let’s Encrypt rate limiting

While IPv4/IPv6 connectivity and Let’s Encrypt rate limits are not completely solved problems, our optimizations and fixes contained in the 1.102 release should significantly reduce how often users are blocked from connectivity and deployment. For multi-cluster environments, the new in-cluster peer relays will reduce the configuration burden of direct multi-cluster connectivity, even in difficult network scenarios such as VPCs.

In many cases, Kubernetes clusters are deployed into virtual private cloud (VPC) networks and are unable to communicate directly with each other without setting up explicit rules in the network firewall. To enable communication regardless of firewall rules, Tailscale uses a DERP server as a relay to establish a connection. Connection speeds are much lower than a direct connection, so you would typically set up a Tailscale Peer Relay to help facilitate a direct connection to improve performance.

Before 1.102, you could technically deploy a peer relay inside or outside your cluster to enable direct connections between clusters. However, we have heard from you that setting up a peer relay to work with Kubernetes clusters can be a headache, requiring manual configuration of a Tailscale client completely separate from the Operator.

With Tailscale Peer Relays In 1.102, you can now deploy peer relays in your clusters using our new custom resource, PeerRelay, for the Kubernetes Operator. When defined, the Kubernetes Operator will deploy and maintain each peer relay for you, with little configuration:

apiVersion: tailscale.com/v1alpha1
kind: PeerRelay
metadata:
  name: my-relay
spec:
  replicas: 2

You can also supply additional configuration such as tags, proxyClass inheritance, and tailnet by referencing our custom resource API.

IPv6 connectivity

IPv6 connectivity, especially enabling connectivity between IPv4 clients and IPv6 workloads, can be tricky in Kubernetes. This has also been true of the Tailscale Kubernetes Operator, as we rely on iptables and nftables to perform routing within the cluster. If you are not running a dual-stack cluster with both IPv4 and IPv6, you cannot route with the IP set you don’t have, and connections from clients can never be established.

Even given those limitations, there was support missing around IPv6, which we’ve included in this release. Firstly, we added support for the ProxyGroup Egress to egress to IPv6 destinations. Previously, only an IPv4 address was a valid destination, which included Tailscale services’ IPv4 address.

However, if you needed to connect to a destination that only supported IPv6 on incoming connections, such as our 4via6 subnet routers, you would not be able to establish a connection. Most of Tailscale is compatible with both IPv4 and IPv6, but on large networks with isolated sub-networks, you may run into cases where your IPv4 addresses overlap. In this case, a 4via6 subnet router can bridge that connection by exposing an IPv6 address for an IPv4 destination. As of 1.102, we now support this functionality in the Kubernetes Operator, enabling connections where IPv4 ranges overlap.

Let’s Encrypt rate limit optimizations

When you use Tailscale, every node in your Tailscale network (tailnet) is given a MagicDNS name. In order for those MagicDNS names to be used for TLS connections, each node needs its own certificate for the hostname it was assigned. These certificates are issued by the open Certificate Authority, Let’s Encrypt.

As a free public service run by the Internet Security Research Group (ISRG), there are various rate limits placed on its usage to ensure the service remains available for everyone. As tailnets become larger, and especially as large automated deployments become more common, it’s likely you may run into some of them. The most common is a 50-certificate per registered domain per week limit that is reset only after seven days. This issue can be crippling when trying to roll Tailscale out across a large network in a short time period.

While you can request a rate limit override from Let’s Encrypt, we wanted to provide a smoother experience before you need to increase your limit, while also being better citizens of the Let’s Encrypt platform. So we’ve made a series of small optimizations to how we acquire certificates in the Kubernetes Operator:

• Certificate renewal retries now follow a backoff schedule instead of a fixed interval.
• When available, Retry-After headers are now used, which avoids tight retry loops that made rate-limit backoffs worse.
• The per-attempt cert issuance timeout is increased to 30 minutes to avoid premature timeouts on ACME challenges.
• Cert issuance for multiple domains now runs in parallel instead of one at a time, preventing the provisioning of many domains from stalling each cert behind the previous one.
• During Ingress deletion, VIPServices are now prevented from acquiring new certificates, avoiding wasting Let’s Encrypt rate-limit quota. This is especially prevalent in ephemeral deployments.

We have one more optimization coming in 1.104 that will improve how certificate renewals are counted towards your rate limits. Even with all these optimizations, limits can still be encountered. We are also working on another solution that I hope to be able to share soon. In the meantime, if you are still running into rate limit issues with Let’s Encrypt, we recommend formally requesting a rate limit override from Let’s Encrypt for your tailnet.

What’s next?

Our next release cycle for the Tailscale Kubernetes Operator will be primarily focused on improving our end-to-end testing infrastructure, Let’s Encrypt account key sharing, and fixing a few stubborn bugs. In the background, we’re working on longer-term solutions for Let’s Encrypt limits, installation for OpenShift and GKE, and planning our biggest improvement since the operator’s inception.

Today, we have a few common problems that the operator struggles with, primarily due to its architecture:

• Egress to any tailnet resource requires explicit setup, per endpoint and per namespace.
• Access controls can only target the ProxyGroup rather than the workload.
• Using IPv4 and IPv6 interchangeably between clients and clusters is difficult.
• Cluster workloads bypass connectors without a steering mechanism.

To solve these problems, we need a deeper way to route traffic, beyond what iptables and nftables are capable of. This means for ingress and egress, a Container Network Interface (CNI) is required. We also need a way to assign identities to workloads within the cluster without resorting to sidecars. All of this leads us to a new architecture: something between a traditional gateway proxy and a full sidecar mesh.

One problem we need to tackle first is the requirement to create a new tag in tagOwners for every new tag created in the tailnet. Our goal is for every workload in Kubernetes to have its own identity for access controls. Today, that means tagging the workload with a Tailscale tag to grant access via the ACL. Typically for application teams, this requires a ticket to your Tailscale admin to create the new tag for you. That pattern becomes cumbersome when you have automated deployments, even outside of Kubernetes, constantly requiring new tags.

That’s why we are building pattern-based tag ownership into Tailscale’s ACL. This will allow you to specify ownership for a pattern of tags, effectively granting ownership over a predetermined scope for application teams and operators. Once granted, the owner will be able to create as many tags as needed under the pattern specified in the tagOwners section. If you have ephemeral or automated infrastructure deployment as a service within your organization, even outside of Kubernetes, this change is for you.

After pattern-based tag ownership, we’ll be building a new architecture for the operator, aimed at solving all the problems outlined above. More details on what that looks like soon!

Resources

For a complete list of changes in the Kubernetes Operator and Tailscale as a whole, see our changelog. If you’re looking to get started with Tailscale’s Kubernetes Operator, check out our installation guide or the more complete quickstart guide for a deeper look.

If you’re looking to report an issue you have, log a feature request, or get involved with helping us build Tailscale for everyone, check out our repository on GitHub.

Today we’re releasing tailcat, a remix of pieces of Tailscale that gives you a way to use the open-source Tailscale data plane (WireGuard® + NAT traversal + DERP) without the Tailscale control plane, written by the people who made Tailscale. It’s Tailscale without Tailscale, by Tailscale.

Specifically, tailcat is both an open-source Go package and a CLI tool using that package. It lets you run a server-side listener and a client to connect to that server, moving bidirectional bytes back and forth.

That is, it’s like netcat but flowing over Tailscale’s magicsock (WireGuard encryption + NAT traversal + DERP rendezvous/fallback relay).

Notably, tailcat has:

• no IP addresses
• no accounts (no logins, no passwords, no SSO)
• no control plane
• no users
• no admins
• no administrative controls
• no root or admin OS access requirement
• no relationship with or dependence on Tailscale as a company (if you run your own cmd/derper DERP server, at least)

What does “Tailscale” even mean?

When you watch people describe Tailscale to each other online, you see very different interpretations of what “Tailscale” means to them.

One group of people, often seen saying things like “I’ll just run WireGuard myself,” focuses on the WireGuard part and doesn't consider (or care about) parts like NAT traversal, DERP fallbacks, centrally managed firewall (ACL) rules, SSO login, tagging, MDM policies, audit logging, etc. Maybe they only want or need the WireGuard part on a public IP. That’s fine.

Another group of people talks more about the company, corporate structure, long-term viability, founders, funding stage, pricing, certifications, reliability, responsible handling of security disclosures, etc.

Another group of people talk about whether Tailscale is open source or not. As a reminder: our core is open source (with a real OSI-approved license!), our DERP server is open source, and our clients are open source on platforms that are themselves open source: Linux and Android. Our server-side control plane is not. A lot of people in this audience appreciate that Headscale (which we love and partially fund development of) exists, either to use today, or use in the future, as a fallback plan.

All of those interpretations are fine. Whether you’re using our official GUI client wrappers around our official control plane, with a corporate SSO identity provider, or you’re at the other extreme, using only tsnet on Linux nodes against your self-hosted Headscale server, there are many ways to wire up and use Tailscale and its many pieces:

• Its WireGuard + NAT traversal + DERP fallback data plane
• Its control plane
• Its company (paying us to run and support things for you)
• Its open source code

tailcat gives you another way to use a subset of Tailscale.

How it works

Let’s say you want to run a tailcat server. Here’s what it does:

• generates a keypair (either ephemeral or named & reused)
• picks a DERP server (either one you specify, or an auto-selected bandwidth-limited Tailscale-run one)
• generates a tailcat address, which is a string of the form: tc + base64(CBOR( public key + DERP bootstrap info ))
• you then share that address string with somebody out of band, either directly, or by putting it in a DNS TXT record, and sharing that DNS hostname out of band

The client side is about the same:

• pick a key (ephemeral or locally named & reused)
• connect to the rendezvous DERP server specified in the tailcat address
• send a MEOW message to the server’s public key over DERP to add yourself to the netmap

At that point, if the server is cool with that client’s public key (it can be optionally locked down), then it replies with a happy MEOW reply.

The client then proceeds to make a TCP connection to the other side using an embedded userspace TCP stack atop WireGuard. There are actual IP addresses on the wire (IPv6 ones derived from your public key), but they’re never visible to users. Your operating system is never involved at the TCP layer and never sees the synthetic tailcat IPs. All your operating system does is send the DERP TCP messages and/or NAT-punched UDP WireGuard messages.

Because it goes over Tailscale’s magicsock data plane, NAT traversal automatically kicks in and tries to get a direct connection, so data transfer (WireGuard UDP packets) ends up going directly between the client and server, without a DERP relay involved. But if both sides are behind a hard NAT without any port mapping services available, the data packets are relayed over DERP as a fallback. If you use Tailscale-hosted DERP servers, those are rate-limited (bandwidth costs us money). But if you run your own DERP server, you can control any rate limiting.

In the default mode where you don’t specify a port number on the tailcat server, the default is to just pipe the received data to the server’s stdout, like netcat. But it can also run in a client mode, where it runs a SOCKS server on an ephemeral local port and then runs a provided child process (e.g. curl or whatever) with an environment variable set to use said SOCKS server, letting tailcat -oblivious programs use tailcat transparently. (tailcat is currently always userspace-only, never reconfiguring your system’s networking stack … no TUN devices, no routing table changes, etc.)

Why?

I wrote tailcat in September 2023 on a long ten-hour flight while catching up on bad movies. At the time, tailcat was mostly a fun novelty. I presented it internally, and I’d use it occasionally myself, but I mostly forgot about it. But then a number of customers approached us with use cases where it was a perfect fit, so we gave them copies of it, with arrangements where we’d host the DERP fallback relays for them in cases where tailcat’s use of Tailscale’s magicsock fails to get a direct connection.

Fast-forward to a few months ago, when all this AI agentic coding stuff was in full swing. It’s been really powerful to just give my sandboxed AI agents access to make their own also-untrusted nested VMs and give them tailcat. With access to exotic hardware in faraway places, I let the AI go wild wiring things up to each other and running experiments. Off the top of my head, I can recall:

• giving an agent access to a fleet of every Raspberry Pi generation
• giving an agent access to a sandboxed EC2 instance that had ambient access to control a nearby EC2 instance and kexec reboot it repeatedly, while porting Tailscale to run in EC2’s UEFI environment, including porting the Amazon Nitro ENA network driver to pure Go (under Tamago)
• giving an agent access to a Windows host to repeatedly create and destroy Hyper-V VMs to debug and fix a stack corruption bug in the Go runtime and standard library

In most of these cases, I probably technically could’ve just used Tailscale proper, but it would’ve been more tedious to the point that I probably wouldn’t have even done it, and would’ve just set up a few port forwards instead, or opened up some ports on a firewall somewhere. I find that tailcat is often the perfect tool when I already have two shells open on two machines in two very different worlds and I just want to connect the two together, for a quick file copy, or port forward, or letting one SSH to the other. Especially when one side is untrusted or ephemeral or I’m afraid to touch its system configuration.

When we launched Taildrop in 2021, one of the first requests was for netcat-like sharing between nodes. tailcat now provides that, and more. We’d still like to do something tailcat-like in the main Tailscale client too, but we’ll have to figure out how that fits into the rest of the Tailscale product.

Another reason to open source tailcat is that it’s kinda obvious and inevitable. We’d selfishly rather people be using, improving, and filing bugs against our data plane, which then makes the rest of the Tailscale product better.

“Contact Sales”

I would be remiss if I didn’t mention that you should contact us if you have fun use cases where tailcat might help you, and where we can help you integrate tailcat or run a global fleet of DERP relays for you. (e.g. IoT, P2P games, distributed GPUs, etc.)

The DERP server fleet we’re running for tailcat is throttled and only available in a handful of regions around the world. The idea is that, most of the time, our magicsock NAT traversal will do its thing and DERP isn’t relevant, with tailcat getting a direct UDP WireGuard connection between the two peers. But in cases where that fails, we’d be happy to exchange money for goods and services.

Or, hey, run your own DERP fleet or single server. It’s open source too.

Enjoy!

We look forward to seeing what you build and how you use this. Give tailcat a spin here.

Networking: it’s the thing you bolt on last. You write an application or spin up an instance, and then you work out how anyone actually reaches it. Opening ports, standing up proxies, grabbing certificates and checking the ACLs—the project is “done,” yet the on-call work is just starting.

That separation is something we want to change. Over the last few releases, Tailscale has been growing: from something you only configure for your software, into something you build with and on. And you never give up admin console control, or the ease of making direct, encrypted connections.

Here’s what we mean:

• You can build with Tailscale: embed secure connectivity directly into applications, so the things you build join your Tailscale network (tailnet) with their own identity.
• You can build on Tailscale: automate how tailnets are created, shared, and managed, using the same APIs that power the admin console.

My colleague Reza walks through these options in a video on our YouTube channel, and has provided code examples in our tailscale-dev repository. Here’s a bit more on how they work, and where you can read about them.

Build with Tailscale

Embedding the network in an app with tsnet

Let’s start with a small, “fun” version of a problem. You have a local AI server, like Ollama, running on a box at your desk. Ollama offers a server, which is handy for providing an endpoint, or working away from your desk. But that server must never become a public endpoint.

The usual ways to fix this: open an inbound port, stand up a reverse proxy with custom certificates, and spend a lot of time either pasting in variables yourself, or walking an agent through doing it. And then checking in again, when the certificates stop working.

Using tsnet gets you away from the usual. Import it as a Go library, and each Ollama server joins the tailnet as its own node, with their own identity, a MagicDNS name, and a place already set in your ACLs. No host daemon, public port, or firewalls to trip over. The certificates are also handled, if you need to serve something up over HTTPS.

“But I’m already running Tailscale on these machines!” you might say. The distinction is that tsnet gives an identity to each application, separate from hosts. So the box can switch between tailnets, or the host can be a sandbox with a contained blast radius. You can give everyone on the tailnet their own Ollama, and those Ollama instances get their own scopes, access, and connections.

This is what it looks like, in pseudocode, when tsnet gives a Go application Tailscale powers:

srv := &tsnet.Server{
  Hostname: hostname,
  Dir: stateDir,
  AuthKey: authKey,
  ClientID: clientID,
  ClientSecret: clientSecret,
  Ephemeral: false,
}

defer srv.Close()

if _, err := srv.Up(context.Background()); err != nil {
  log.Fatalf("tsnet up: %v", err)
}

// srv.Listen("tcp", ":80") also works if you don't need TLS.
ln, err := srv.ListenTLS("tcp", ":443")
if err != nil {
  log.Fatalf("listen :443: %v", err)
}
defer ln.Close()

http.HandleFunc("/", func(w http.ResponseWriter, r *http.Request) {
  fmt.Fprintln(w, "Hello from tsnet")
})

log.Printf("serving https://%s.<tailnet>.ts.net", hostname)
log.Fatal(http.Serve(ln, nil))

This service would come up at https://ollama..ts.net, valid certificate and all. ListenTLS will mint a certificate if you’ve turned on HTTPS for your tailnet. You’ll note, in Reza’s video and repository, that Ollama only binds to 127.0.0.1:11434. The tailnet is the only way in, whether or not you remember to close the port later.

“Sounds great,” you might say, “except we’re not a Go shop.” Watch this space—or, more specifically, watch tailscale-rs. It brings this embedded Tailscale model to Rust, and opens up bindings in Python, Elixir, and C, with more to come. Right now it’s experimental (pre-alpha), so it’s definitely more direction than production code. But it’s a promise of options to come.

Build on Tailscale

Provision isolated tailnets with the Tailnets API

Embedding with tsnet gets the app you trust on your tailnet. The Tailnets API gives you something else: a whole network you bring up on demand, as part of a product or provisioning workflow, rather than editing by hand.

It’s useful for isolation: one tailnet per customer, environment, or short-lived test. It’s also a way to run code you don’t entirely trust yet. Hand an agent a throwaway tailnet and see what it builds inside a walled space. Then, just as easily, take it down when it’s done (or tell the agent to tear itself down).

Here’s what it looks like in action: provisioning isolated tailnets through the API. You could then go on to enable HTTPS certficates for your tailnets, provision them with tags, and more.

create_tailnet() {
  local label="$1"
  token="$2"
  curl -sS "https://api.tailscale.com/api/v2/organizations/-/tailnets" \
    --request POST \
    --header 'Content-Type: application/json' \
    --header "Authorization: Bearer $token" \
    --data "{\"displayName\":\"e2e-sandbox-$label\"}"
}

tailnet_access_token() {
  local client_id="$1"
  local client_secret="$2"
  curl -sS -X POST "https://api.tailscale.com/api/v2/oauth/token" \
    -d "client_id=$client_id" \
    -d "client_secret=$client_secret" |
    jq -r '.access_token'
}

So we’ve put a good deal of connectivity inside the things you test and ship. Next up: automating parts of Tailscale itself, smoothing out even more friction from the network.

Managing sharing without the clicks

Sharing across tailnets typically requires multiple human-effort steps: creating the share, sending it over, and accepting it. That’s fine for a web app on your NAS, but across a suite of tailnets, it becomes a ClickOps dependency.

Declarative Node Sharing takes those manual actions and turns them into policy. You declare what should be shared with whom, commit it, and let a GitOps workflow apply it—the same way you manage the rest of your infrastructure. No manual clicking and checking, and no relying on someone’s memory of what is shared with whom.

Declarative Node Sharing is currently available by joining a waitlist. You can find the join link in Settings > General in your admin console.

Automate all the admin console actions

Have you noticed Tailscale’s new admin console? It’s built on the same APIs available to your tailnet. Anything you can click on the console, you can drive programmatically: ACL updates, key rotation, ACL fleet management, and all the tailnet provisioning we mentioned earlier in this post.

Platform and security teams can build their own automations, internal tools, and custom interfaces, on top of Tailscale’s standard admin console. Network operations that used to require clicks are now code that can be reviewed, tested, and automated.

One platform, two ways in

We’ve been working to make Tailscale a more useful tool for multiple audiences inside any organization:

• Developers can embed secure connectivity into shipped products, with tsnet today and tailscale-rs in the future. Bring up network layers faster, and provision isolated tailnets from inside their products or agentic workflows.
• Infrastructure, IT, and security teams can now manage sharing through policy and automated operations, so that large-scale tailnets, and multiple tailnets, have far fewer manual steps.

Whether you’re building with Tailscale, on it, or both, we want secure networking to no longer be the last hurdle to shipping products or sealing up systems. Tailscale can help make networking part of what you build, not the work you do after you thought you were done.

Learn more

• Read more on the Tailnets API
• Join the Declarative Node Sharing waitlist in the admin console.
• Explore tsnet, and see what’s possible soon with our Rust work
• Check out code examples in our dev repository
• See what you can automate now with the Tailscale API and API docs

Tailscale customers can now purchase DNS filtering by Control D from the Tailscale sales team. Control D’s DNS filtering solution integrates directly into your tailnet with per-group or per-device controls.

Teams that want to block malicious, phishing, or unwanted destinations can set up DNS filtering rules in Control D and apply those rules to any groups, tags, or devices in their tailnet with a simple access control list (ACL) integration. And starting today, you don’t have to go through another procurement process to do so.

How it works

Add Control D as a nameserver in the Tailscale admin console, and head over to your Control D dashboard to find a default security rule (or create a custom rule). In your Tailscale ACL, map the users, groups, or devices to the Control D rule. Your devices will then send DNS queries through Control D over encrypted DNS, applying the filtering ruleset you’ve just set up.

Tailscale will bill you for the number of users you need DNS filtering for. No need to predict how many devices, serverless nodes, or other infrastructure you’re going to have. Just let us know the size of your organization, and we’ll send you a simple user-based bill at the end of the month.

You still manage DNS filtering rules inside Control D, whether through the Dashboard or API.

Why Control D?

Control D is one of the fastest and most reliable DNS filtering services we’ve tried out (under 7 ms in North America). We already have customers using their service, and when we met the team behind Control D, we knew they were onto something great.

Control D blends threat feeds, malicious domain and IP detection, and machine learning to block malware, phishing, and suspicious domains. It’s consistently ranked as one of the top DNS malware blockers. Control D lets you filter by content categories, choose from a maintained list of over 1,000 services and apps, and write custom rules to block, allow, or redirect anything else. It gives you the same kind of straightforward control over the public Internet that Tailscale gives you inside your tailnet. Filter by recognizable domains and write custom rules to block, allow, redirect, or reroute traffic using Control D managed domain lists.

To purchase DNS Filtering by Control D, come have a chat with us.

Meet Tailscale PAM

Teams already use Tailscale to connect people and devices to private infrastructure. But access to production databases, servers, Kubernetes clusters, and internal applications requires more than a secure network path. Security teams also need to control which resources users can access, under what conditions, and what happens during privileged sessions.

The Border0 + Tailscale integration introduced identity-aware, credential-free access to critical infrastructure. Tailscale PAM, now in beta, turns that integration into a dedicated Tailscale product, managed through the Tailscale admin console and unified with the Tailscale experience.

Tailscale PAM (privileged access management) lets teams control and audit privileged access to sensitive infrastructure. It is available through the Tailscale admin console, giving customers a consistent experience in managing both connectivity and privileged access.

From the Tailscale admin console, customers can manage Tailscale PAM workflows, including:

• Connect private infrastructure: Deploy and monitor connectors running inside private environments
• Protect specific resources: Grant access to specific databases, servers, Kubernetes clusters, and web applications, rather than granting broad network access
• Control access precisely: Define who can access each resource, when access is allowed, and what permissions apply
• Adapt access safely: Set policies for employees, contractors, and other external users based on the resources they need to access
• Simplify setup: Deploy connectors inside your private environment without installing clients on each resource
• Support audits and investigations: Use session logs to see who accessed which resources and when, and session recordings to support compliance, audits, and post-incident investigations

This gives customers distinct solutions for connectivity and privileged access, managed through Tailscale.

Grant access when it is needed

Production access is often occasional. An engineer may need infrastructure access during an incident, temporary SSH access for maintenance, or Kubernetes permissions for a deployment.

With just-in-time access, users can request access to a specific service or resource and receive approval through Slack. Admins can scope access to the resource they need and limited to a defined period. This helps teams reduce standing access without slowing down operational work.

Keep familiar workflows

Tailscale PAM works with the tools infrastructure and engineering teams already use, including SSH, Kubernetes API, database clients, RDP clients, and browsers.

Users authenticate through the organization’s identity provider and access the services available to them. Tailscale PAM brokers the connection, associates each session with an identity, and preserves logs or recordings for supported protocols. Teams don’t need to distribute shared credentials or send users through a separate access process for every resource.

Apply controls to individual services

Network-level access is often broader than the task requires. A user who needs to work on one production database does not necessarily need access to the subnet around it.

Tailscale PAM lets admins define individual services and apply policies directly to them. Policies can control access based on users, groups, time windows, and permissions. This gives infrastructure teams more precise control, while making it easier for security teams to update access as responsibilities change.

Improve visibility and auditability

Session logs and recordings provide additional evidence where supported, helping teams investigate privileged access activity and prepare for compliance reviews.

Instead of maintaining separate records for databases, SSH, Kubernetes, and other systems, teams can manage privileged access through a more consistent model.

Secure access for contractors and external users

Give contractors, vendors, and other external users access only to the specific resources they need, with permissions tailored to their work. Session logs and recordings provide visibility into their activity, while browser-based access lets them connect through the web console without installing a desktop client.

Try Tailscale PAM Beta

Tailscale PAM Beta governs privileged access while working seamlessly with the connectivity, identity, and administrative foundation Tailscale provides.

During the beta, customers can manage connectors, services, policies, and administrative audit activity through the Tailscale admin console. The long-term goal is a unified experience for identity-based connectivity, privileged-access policy, and auditability. Existing Border0 customers can choose when to move to the unified Tailscale admin experience. If you have questions about what the beta means for your current setup, please reach out to your account manager.

We’ll use what we learn from the beta, along with customer feedback, to keep improving the product and prepare it for general availability.

Join the Tailscale PAM Beta waitlist to get started. To learn more about pricing or talk through your use case, reach out to us and we’ll help you take the next step.

We started building Aperture 10 months ago to demonstrate that you don’t need to choose between ease of use, identity-aware networking, and robust safety when using agentic AI with Tailscale.

Our solution started as an LLM proxy that eliminated the need to distribute API keys to both engineers and agents connected to your tailnet. Since then, it has grown into a comprehensive AI gateway, with countless visibility and control features for enterprises. These include cost controls, request and response hooks, guardrails, extensive logging, and even a full MCP (Model Context Protocol) and API proxy, keeping even more keys away from agents and people.

With today’s general availability (GA) announcement, however, we want to go back to the roots of Tailscale, focusing on something that provides an “it just works” experience for individuals and homelab enthusiasts. So we’re also announcing a handful of new features, including:

• Purchasing tokens through Aperture
• MCPs for controlling your tailnets and the devices on them
• An upgraded chat experience

We believe the future of cost-effective AI use involves experimenting with different models from many different labs.

In particular, open-weight models are becoming increasingly prevalent and powerful, but they can still be difficult to use and require large upfront investments. Until now, bringing open-weight models into your Aperture instance required either a third-party API key or enough expensive hardware to route state-of-the-art self-hosted models through Aperture.

Today, each new Aperture instance comes with some initial tokens included. You can also buy more for any major model, both open-weight and closed, directly inside of Aperture. Whether you bring your own subscriptions and API keys, or use tokens sourced through Tailscale, our goal is simple: we want you to be productive with AI as quickly as possible.

Administrating a homelab (or any network) with or without AI in the mix can range from fun to Sisyphean. For the times when you’re pushing that boulder uphill, we’ve added two new MCP endpoints, Tailscale and Tailscale SSH. They make it easier for Aperture and coding agents to add new nodes to your tailnet, as well as access them via Tailscale SSH. This is useful in situations where, for example, you want an agent to deploy a service to a node in your tailnet that you want to access remotely, or share with others. With MCP access, the agent can prompt you for access and, once approved, configure the service without manually copying keys and filling in environment variables.

Before you get too anxious about an agent doing all of this, I’d like to point out three things. First, Tailscale’s unidirectional access control rules are in effect: Aperture — and any agents working through it — must respect them, so you can control exactly which machines can talk to Aperture and vice versa. Second, you approve every machine Aperture wants to add to your tailnet. Third, there’s a clear audit trail, because all of your agent’s actions are logged.

We hope these new MCPs allow you to hold onto the fun parts of homelabbing, while handing the fiddly YAML and other brittle configuration tasks to an LLM with constraints you control.

Since we announced the chat interface built into Aperture, we’ve received tons of feedback on how it could better work with your data and your devices. That’s why we’ve added Projects, and customized default tool permissions.

Projects lets you group chats, with shared initial contexts (instructions), tool access, and tailnet nodes among them. You spend less time prompting each chat with the outline and goals of your project. You can expand tool access beyond your defaults, or rein it in for trickier work. And you don’t have to tell an LLM how to access your NAS; the NAS is present as a Tailscale node, and the LLM can reach it in your tailnet if your access control rules allow it.

The second major addition is the ability to define default tool permissions for everything exposed in Aperture. We’ve been trying to strike the balance between the added predictability that comes with specifying every tool for every chat, and the serendipity that comes when the LLM has broad access to tools. Now you can set defaults that make sense for your own use, carried across all chats.

We don’t know what the future holds when it comes to agentic AI, but we know it demands the right balance of flexibility and security, supporting use cases people can only dream up in the coming days, weeks, and months.

If you’d like to go on this journey with us and use Aperture to control and extend your AI agents, you can add it to your tailnet today. As always, we appreciate and read all of the feedback you submit, so let us know what you think by using the feedback form in Aperture, or emailing us at [email protected].

Use Tailscale Privileged Access Management (PAM) (beta) to provide application-aware access to resources in your Tailscale network.

New

• Services can be defined for privileged access, including SSH, database, RDP, HTTPS, Kubernetes, and Amazon S3 types.
• Sessions can be recorded for SSH, database, HTTPS, and Kubernetes Service types.
• Policies can be set for user access and in-service permissions through grants.
• Secrets store can be linked for credential injection.
• Logs of user access can be viewed, and session recordings can be played back.
• Connectors can be managed and deployed to provide connectivity to services.
• Browser client permits access to services without requiring a Tailscale client download.
• Custom domain management can be used for public HTTP PAM services.
• Custom Amazon S3 bucket can be configured for PAM recording storage.
• Service accounts can be created for machine identities to interact with the PAM API.

Request access to join the Tailscale PAM beta.

Use Aperture (generally available) to secure and manage AI agents and LLM sessions with cost controls, request and response hooks, guardrails, logging, MCP support, and API proxying.

New: A promotional model token credit is included for use with new and existing Aperture gateways.

New: Model tokens can be purchased directly in Aperture for major AI models.

New: With user approval, Aperture can add nodes to your tailnet with the Tailscale MCP endpoint for Aperture and coding agents.

New: Tailnet nodes can be accessed through Tailscale SSH with the SSH MCP endpoint after approval.

New: Chat Projects can be used to share instructions, tool access, and tailnet nodes in group chats.

New: Baseline tool access can be defined across Aperture chats with default tool permissions.