How to Set Up a Tailcat Server Without a Tailscale Account

Tailcat operates independently of the Tailscale control plane by combining userspace WireGuard, magicsock, gVisor Netstack, and public DERP relays into a single binary that requires no account, root privileges, or network configuration—only a self-generated connection token.

You can deploy a fully encrypted point-to-point tunnel server using the tailscale/tailcat repository without creating a Tailscale account or managing control-plane authentication. Tailcat repurposes core Tailscale networking components—WireGuard, magicsock, and DERP—but runs them in a self-contained, userspace mode that generates its own connection tokens and requires zero host-level network changes.

How Tailcat Eliminates the Tailscale Control Plane Dependency

Traditional Tailscale deployments rely on the Tailscale control plane for authentication, machine cataloging, and coordination. Tailcat removes this dependency by embedding four critical components directly into a single binary:

• Userspace WireGuard: Encrypts all traffic within the process itself. Because it operates entirely in userspace without creating kernel TUN/TAP devices, the server requires no root privileges or routing table modifications.
• magicsock: Handles NAT traversal, UDP hole-punching, and automatic fallback to relay servers when direct connections fail.
• gVisor Netstack: Implements a complete TCP/IP stack in userspace, allowing Tailcat to accept inbound TCP connections and initiate outbound ones without interacting with the host's DNS or routing configuration.
• DERP Relay: Serves as the bootstrap channel and fallback path for peers unable to establish direct UDP connectivity. Tailcat defaults to the public DERP map hosted at https://tailcat.dev/derpmap.json, though you can specify custom relays.

Instead of authenticating against a central server, Tailcat generates a connection token—a string encoding the server's WireGuard public key and DERP region information. According to the source documentation in README.md (lines 18-26), the server prints this token on startup, which clients use to establish encrypted sessions without any external authentication service.

Step-by-Step Installation and Server Setup

Deploying a Tailcat server requires only the binary and outbound internet access (or access to your chosen DERP relay). No systemd services, kernel modules, or administrative rights are necessary.

Install the Tailcat Binary

Retrieve the latest release using Go:

go install github.com/tailscale/tailcat/cmd/tailcat@latest

The binary compiles all networking dependencies statically, producing a single executable that contains WireGuard, magicsock, and gVisor Netstack.

Start an Ephemeral Server

Launch a server with a temporary WireGuard key pair:

tailcat

The process generates an ephemeral private key, selects the nearest public DERP region from the default map, and displays a connection token:

# 🐈 Server listening with new address: tcomFwWCCcjS5nKNqAod034nWoJZW0LZqDhhC8U_dKdnDRYQ8uNGFpGQEu

As documented in README.md (lines 60-66), this token represents the server's identity. Copy the string following address: to distribute to clients.

Connect Your First Client

From any machine with the Tailcat binary, pipe data through the token:

echo "hello" | tailcat tcomFwWCCcjS5nKNqAod034nWoJZW0LZqDhhC8U_dKdnDRYQ8uNGFpGQEu

The client uses the embedded WireGuard public key and DERP coordinates to establish a direct encrypted tunnel. No account credentials, API keys, or pre-shared secrets are exchanged through third-party servers.

Persisting Keys and Using Custom DERP Relays

For production deployments, you likely want deterministic server addresses and control over relay infrastructure.

Generate Persistent Keys with tailcat genkey

To maintain a consistent connection token across restarts, generate a persistent keypair:

tailcat genkey --region=nyc

This command saves the private key to ~/.config/tailcat/keys/default.private.json. When you subsequently run:

tailcat --serve=8080

The server reuses the saved key, producing the identical connection token each time. As noted in the "Key Management" section of README.md (lines 98-106), this ensures clients can reconnect without updating their configuration after server restarts.

Deploy Private DERP Infrastructure

To avoid public relays entirely, specify your own DERP server during key generation:

tailcat genkey --region=derp.example.com
tailcat --serve=22

The generated token now embeds derp.example.com as the bootstrap coordinate. According to the "Bring your own DERP relay" documentation (lines 107-114), this configuration routes all fallback traffic through your infrastructure while still supporting direct UDP hole-punching when possible.

Core Architecture and Source Files

Understanding the implementation confirms why no Tailscale account is required. The entry point in cmd/tailcat/tailcat.go parses CLI flags and initializes the Server struct defined in tailcat.go. The Server implementation handles:

• Ephemeral key generation via WireGuard primitives
• DERP map retrieval and region selection
• Connection token encoding and display
• TCP session management through gVisor Netstack

Because tailcat.go instantiates magicsock and DERP clients directly rather than querying the Tailscale coordination server, the binary operates as a closed system. The readme.go file embeds documentation into the binary for offline reference via the --readme flag, ensuring deployment guidance remains available without internet access to GitHub.

Summary

• Tailcat requires no Tailscale account because it implements its own key exchange via connection tokens rather than the Tailscale control plane.
• Userspace operation via WireGuard and gVisor Netstack eliminates the need for root privileges, kernel modules, or routing table changes.
• Quick start: Install with go install, run tailcat to generate an ephemeral token, and pipe data to that token from clients.
• Persistence: Use tailcat genkey to create stable identities stored in ~/.config/tailcat/keys/.
• Infrastructure independence: Deploy private DERP relays by specifying custom regions during key generation, keeping all coordination traffic on your infrastructure.

Frequently Asked Questions

Does Tailcat share code with the main Tailscale client?

Yes. Tailcat imports and reuses four core Tailscale components: the userspace WireGuard implementation, magicsock for NAT traversal, gVisor Netstack for TCP/IP handling, and the DERP relay protocol. However, it assembles these components into a standalone server that never contacts the Tailscale control plane, authentication servers, or machine database.

What happens if the public DERP relays are unreachable?

If the public DERP map at https://tailcat.dev/derpmap.json is inaccessible, peers cannot bootstrap connections through the default relays. You must deploy a custom DERP server and generate keys using tailcat genkey --region=your-derp.example.com. Direct UDP connections between peers with public IPs or successful hole-punching will still function without any DERP access.

Can I run Tailcat on systems without root access?

Absolutely. Because Tailcat uses gVisor Netstack and userspace WireGuard, it never creates TUN/TAP devices or modifies system routing tables. The binary runs with standard user privileges, making it ideal for restricted environments like shared hosting, containers without NET_ADMIN capabilities, or locked-down development machines.

How is the connection token different from a Tailscale auth key?

A Tailscale auth key authenticates a machine to the Tailscale control plane, which then distributes WireGuard keys to other nodes. A Tailcat connection token is the WireGuard public key plus DERP coordinates, encoded into a single string. Clients parse this token to connect directly to the server without intermediary authentication services, eliminating the control plane entirely.

{
  "mcpServers": {
    "instagit": {
      "command": "npx",
      "args": ["-y", "instagit@latest"]
    }
  }
}