FR
live

Tailcat ships Tailscale’s WireGuard data plane with no control plane at all

On August 31, 2026, Brad Fitzpatrick released tailcat, an open-source Go package and CLI that exposes Tailscale’s data plane — WireGuard, NAT traversal, and DERP — with no account, no IP addresses, and no control plane. Use it to connect two isolated machines, or hand an AI agent a disposable connection, with no root access.

Two bare metal enclosures linked by a single taut cable stretched over a dark void, one connector end glowing amber.

August 31, 2026. Brad Fitzpatrick, co-founder of Tailscale, releases tailcat: an open-source “remix” that hands you Tailscale’s data plane — WireGuard, NAT traversal, and DERP relay — without the control plane. September 2023. The tool was born on a long-haul flight under the name derpcat, before being revived for the age of AI agents. August 2026. It is open sourced at the TailscaleUp conference, under the BSD-3-Clause license. Why it matters: you can now stand up a point-to-point encrypted tunnel between two machines in seconds, with no account, no visible IP address, and no change to the host’s network configuration.

A netcat that speaks WireGuard, nothing more

tailcat can be summed up in one line: “like netcat, but over Tailscale’s data plane, without Tailscale’s control plane.” It is both an importable Go library (github.com/tailscale/tailcat) and a CLI built on top of it. One side listens, the other side dials the address, and traffic flows end-to-end encrypted over WireGuard.

What tailcat lacks matters as much as what it has. No IP address exposed to the user, no account, no login, no SSO, no users, no admins, no governance rules — and, crucially, no root or admin requirement: everything runs in userspace, without touching the machine’s routing tables or DNS. The initial connection bootstraps through a DERP relay, then magicsock attempts NAT traversal to upgrade to a direct peer-to-peer UDP connection; the relay only remains as a last resort if hole-punching fails.

bash
# server side: listen and print the ephemeral address
tailcat
# Selected bootstrap relay region 302, San Francisco
# 🐈 Server listening with new address: tcXXXXXXXXXXX

# client side: send bytes through the address shared out of band
echo hello | tailcat tcXXXXXXXXXXX

The crucial point is how the address is distributed: it is shared out of band — a message, a DNS TXT record, whatever — and it acts as a secret. Tailscale puts it bluntly in its FAQ: the address is sensitive, treat it like a password, don’t commit it and don’t tweet it.

Short-lived use cases, where a tailnet is overkill

Tailscale is built for ongoing, scalable, auditable connectivity: identities, ACL policies, SSO, logs. tailcat occupies the opposite end: the one-off connection. The official docs list the typical uses — remote development, SSH access, file transfers, CI jobs, game sessions, sandboxed environments — and add a use case that became central in 2026: giving an AI agent temporary access to a specific machine without onboarding it to your network.

That is exactly the scenario that motivated the release. Fitzpatrick describes using tailcat to wire his coding agents to disposable machines: a fleet of every Raspberry Pi generation, a sandboxed EC2 instance that could repeatedly reboot its neighbor via kexec, or a Windows host that created and destroyed Hyper-V VMs to debug a stack corruption in the Go runtime. Full Tailscale would have been possible in each case, but “more tedious to the point that I probably wouldn’t have even done it” — you would have ended up opening ports on a firewall instead.

The internal mechanics deserve naming: each peer derives a deterministic IPv6 address from its WireGuard public key, but that is an implementation detail never exposed. Both sides run a userspace TCP stack (gVisor) on top of WireGuard, so the operating system never sees tailcat’s synthetic addresses.

What to know before adopting it

tailcat is free, but with no stability promises. The README is explicit: the Go API, the CLI flags, the output, and even the wire format may all change. The public DERP relays are rate-limited, carry no uptime SLA, and Tailscale may revoke access to them at any time. The hosted relay keeps metadata logs and is not intended for privacy — tailcat is not an anonymous service.

For the self-hoster, the real option is to supply your own relay: derper is open source, and Tailscale documents Custom DERPs. Deploying it yourself removes the dependency on Tailscale’s infrastructure and puts you back in control of throughput and metadata. The tool also ships native SSH and SFTP handlers — tailcat_ssh.go and tailcat_sftp.go in the repo — which makes it more than a bare byte pipe.

bash
# expose local ports through the tunnel
tailcat serve 8080,8443

# client side: bind a local port to the remote service
tailcat tcXXXXXXXXXXX 8080

Installation is as broad as you would expect from a modern Go tool: static Linux binaries (.deb, .rpm), Windows, macOS via Homebrew, a container on ghcr.io, AUR and conda-forge packages, and Nix. The repo already showed 6,300 stars and 243 forks within days of the announcement — a signal that the need was real.

Under the hood: an address and a MEOW handshake

The magic rests on two mechanisms. The tailcat address is a string of the form tc followed by a base64(CBOR) blob that encodes the server’s public key and the DERP relay bootstrap information. That address is the whole secret: sharing it means granting the connection. The handshake, meanwhile, is deliberately trivial — the client sends a MEOW message to the server’s public key over DERP to add itself to the netmap, and the server replies with a happy MEOW if it accepts the key, with an optional key-based allowlist to lock access down.

On the data side, a userspace TCP stack (gVisor) runs on top of WireGuard, so the operating system never takes part in the connections. The server then dispatches incoming traffic by port: forwarding to localhost, piping to stdout, running an SSH session, or an SFTP transfer depending on configuration. That simplicity is what makes the tool fit disposable environments: nothing is installed, nothing is reconfigured, and a compromised machine exposes only what you handed it.

A secret, not an anonymous service

One final caution of consequence: tailcat is not an anonymous service. Access rests on possession of the address and the public keys each node exchanges; the keys represent a node’s identity, and the DERP relay hosted by Tailscale keeps metadata logs. For full metadata confidentiality, the only answer is to self-host your own derper — which is also what makes the tool truly “Tailscale-free”: at that point, no piece of the company’s infrastructure touches the traffic.

Verdict

If you need a short connection between two machines — a file transfer, an hour of SSH access, an AI agent that has to touch a sandboxed VM without joining your network — reach for tailcat: one address, one pipe, no account or privilege to manage.

If you run a fleet, identities, or an access policy, stay on Tailscale (or self-hosted Headscale): tailcat deliberately drops accounts, ACLs, audit, and device management, and will not replace them.

If you want to drop Tailscale’s infrastructure entirely, deploy your own derper and point tailcat at it — that is the condition for removing the public-relay dependency and keeping control of throughput and metadata.

References

The cyber brief, every Tuesday

The flaws that matter and the patches to apply, in a ten-minute read.

No spam. One-click unsubscribe.
read next

On the same topic

Proxmox moves enterprise support to 24/7 and opens a North American subsidiary

On September 2, 2026, Proxmox announced around-the-clock enterprise support starting October 19 and the launch of Proxmox North America Inc. in Kingston, Ontario, on the back of a 2.3 million-server installed base. For organizations weighing a move off VMware after Broadcom’s price hikes, the support objection just fell away.

Cloudflare’s EmDash sandboxes plugins to fix WordPress’s security flaw

In late August 2026 Cloudflare released EmDash, a TypeScript CMS pitched as the spiritual successor to WordPress, and moved its own blog onto it. The core idea is one mechanism: isolating every plugin in a sandbox with declared permissions, where 96% of WordPress flaws come from plugins.

← Back to the feed

Type at least two characters.

navigate open esc dismiss