Key details

  1. Tailcat is an open-source Go package plus CLI released by Tailscale.
  2. It uses WireGuard encryption, Tailscale NAT traversal and DERP rendezvous/fallback without the Tailscale control plane.
  3. Peers exchange connection metadata through a short token that the application transports out of band.
  4. No Tailscale account is required.
  5. The tool runs in userspace and does not require root/admin access or modify routing and DNS.
  6. Tailscale’s public Tailcat DERP relays are rate-limited and best-effort; operators can run their own DERP relay.
  7. The project currently makes no API, CLI, wire-format, uptime or throughput stability promises.
  8. The repository is BSD-3-Clause licensed.

What builders should take away

  1. Use Tailcat when you want Tailscale’s peer-connectivity plumbing but deliberately do not want a managed tailnet or control-plane dependency.
  2. Treat the connection token as security-sensitive application data: define how it is authenticated, delivered, expired and revoked rather than assuming Tailcat supplies an identity layer.
  3. If relay availability matters, test direct-connect rates on your real networks and plan whether to operate your own DERP infrastructure.
  4. Do not build a compatibility contract around the current CLI or Go API yet; Tailscale explicitly says both and the wire format may change.
  5. Because Tailcat does not alter routes or DNS, evaluate it as an application networking primitive rather than a drop-in VPN replacement.

What changed

Tailscale released Tailcat on August 31 as an open-source Go package and CLI built from the same `magicsock` data-plane components used by Tailscale. Instead of enrolling devices in the Tailscale control plane, one side starts a Tailcat listener and shares a short connection token out of band; the other side uses that token to connect. Traffic is encrypted end-to-end with WireGuard, initial rendezvous can use DERP, and the library attempts NAT traversal to upgrade the connection to direct peer-to-peer UDP when possible. Tailcat does not change system routes or DNS and does not require a Tailscale account or administrator/root privileges.

Why it matters

Tailscale’s easiest path normally combines an open-source networking data plane with Tailscale’s managed identity and coordination layer. Tailcat separates those layers in a supported public project, giving developers a small primitive for applications that need encrypted peer connectivity but want to own identity, authorization and connection metadata themselves. That can be useful for self-hosted tools, temporary peer transfers, developer utilities and embedded networking features. The cost of that freedom is operational: Tailcat is not a replacement control plane, its connection metadata must be exchanged securely by the application, and Tailscale provides no API, wire-format or relay SLA guarantees.

Connection metadata moves out of the control plane

A Tailcat server produces a short token containing the information a peer needs to establish the session. How that token reaches the client is intentionally outside Tailcat’s scope. That makes the library composable, but it also shifts authentication, authorization, expiry and token-delivery decisions into the surrounding application.

The networking path still uses Tailscale’s data-plane machinery

Tailcat uses WireGuard for end-to-end encryption and Tailscale’s `magicsock` code for NAT traversal. Connections bootstrap through DERP, then try to establish direct UDP where the network permits it. This preserves much of the difficult peer-connectivity engineering without requiring a machine to join a managed tailnet.

It is a userspace library rather than a VPN configuration

Tailcat does not modify routing tables or DNS and does not require root or administrator privileges. The CLI behaves more like an encrypted NAT-traversing netcat, while the Go package lets another application embed the same connection behavior directly.

Relay ownership can stay with Tailscale or move to the operator

The default setup can use Tailscale’s free rate-limited DERP relays, but the project also supports self-hosted DERP infrastructure. Tailscale explicitly describes the public relays as best-effort, with no uptime or throughput commitment, so production users that depend on relay availability need to make that trade-off explicit.

What to watch next

  • Whether Tailscale stabilizes the Go API, CLI and wire format.
  • Adoption of Tailcat inside self-hosted or embedded applications rather than one-off CLI use.
  • Authentication and identity patterns that emerge around out-of-band connection-token exchange.
  • Whether browser/WebAssembly support gains direct WebRTC connectivity instead of DERP-only relay.
  • Third-party or self-hosted DERP tooling aimed specifically at Tailcat deployments.

Still unclear

  • Tailcat is new and Tailscale provides no API or wire-format stability promise.
  • The free public DERP service has no uptime or throughput SLA and may change or be withdrawn.
  • The project intentionally does not provide a complete identity/control plane, so security properties depend partly on the surrounding application’s token exchange and authorization design.
  • NAT traversal success varies by network; some connections will remain relayed.

Sources

Direct reading behind this dossier.

3 sources
tailscale/tailcat README
Tailscale / GitHub primary_repository

Primary technical documentation for token exchange, WireGuard/DERP behavior, rootless operation, self-hosted relays and stability limits.

tailscale/tailcat
Tailscale / GitHub repository

Public BSD-3-Clause source repository for the Go library and CLI.

Discussion

Discussion is reader-contributed. Comments are not part of the BTN dossier or its editorial evidence.

0 visible comments

Join the discussion

Keep comments useful and relevant. Reader contributions may be moderated and are not BTN editorial evidence.

Sign in to comment