Tailcat is a new Tailscale open source CLI for creating encrypted WireGuard tunnels between two machines using short tokens, without a Tailscale account, without root permissions, and without system route changes.
It makes it feel like netcat for the modern developer network: fast, scriptable, disposable when needed, and built on the same low-level pieces that make Tailscale useful.
What’s interesting isn’t just that Tailcat can move bytes between two machines. There are already many ways to do that.
What’s interesting is the shape of the flow.
One side runs a listener and receives a token. The other side passes that token to the client. The connection starts through DERP, Tailscale’s relay and rendezvous layer, and then tries to switch to direct UDP between peers when NAT traversal works. Traffic stays encrypted end-to-end with WireGuard. The Tailscale control plane doesn’t participate.
For developers, that opens a practical middle ground between “opening a port”, “setting up VPN access”, “pasting things in a chat app”, and “spinning up a temporary relay in the cloud”.
What is Tailcat?
Tailcat is a CLI and a Go library that reuses Tailscale’s open source network components to create encrypted WireGuard tunnels, routed by token, without using the Tailscale control plane.
The project presents itself as “Tailscale without Tailscale, by Tailscale”. It’s a playful phrase, but it works as a mental model.
Tailcat doesn’t join your machine to a tailnet. It doesn’t require a Tailscale account. It doesn’t modify routing tables, DNS, or operating system network configuration. It runs in userspace and uses a TCP/IP stack also in userspace, so normal traffic doesn’t need root or administrator permissions.
That makes it more of a development utility than a complete network product for fleets.
The basic flow is small:
- You run
tailcaton the machine that’s going to receive the connection. - You copy the generated connection token.
- You run
tailcat` from the other machine. - You send data, connect to a port, use SSH, or enable another supported mode.
The token contains the information the client needs to find the server’s WireGuard public key and the DERP region. The rest of the metadata exchange happens out of band, however you prefer: copy and paste in the terminal, a secure message, a ticket, a temporary note, or your own automation.
That out-of-band exchange is the tradeoff. Tailcat removes the account-backed control plane, but makes the token important as an operational artifact.
How do you install Tailcat?
Tailcat installs with Go or runs via Nix.
The README shows this Go installation command:
go install github.com/tailscale/tailcat/cmd/tailcat@latest
It also supports Nix flakes:
nix run github:tailscale/tailcat
nix profile install github:tailscale/tailcat
That’s the entire installation story published in the primary documentation as of August 27, 2026.
There’s also an experimental browser demo, compiled to WebAssembly, at https://tailscale.github.io/tailcat/. The README says the browser version can send and receive files or text, and interoperate with the CLI, but browser traffic only goes through DERP until WebRTC support exists.
That detail matters because Tailcat has two very different usage profiles:
- The CLI can attempt direct peer connectivity after DERP bootstrap.
- The browser demo is convenient, but currently relies only on the relay.
For serious development workflows, the CLI is the primary artifact.
How do you use Tailcat like netcat?
You can use Tailcat like netcat by starting a listener on one machine, copying its token, and sending data to that token from another machine.
On the server side:
tailcat
Tailcat prints a connection token and waits.
On the client side:
echo hello | tailcat <token>
The server receives hello and exits.
That’s the small elegance of the tool. No port forwarding ceremony, no tailnet joining, no VPN configuration, no firewall ingress rule, and no dependency on a shared account.
The practical uses are exactly the small jobs that come up all the time in development:
- Move a snippet of logs between machines.
- Send the output of a remote command to a local process.
- Test connectivity across complicated NAT.
- Send a small file or payload without spinning up a service.
- Build a quick debugging bridge between two environments.
Tailcat doesn’t try to replace a full VPN. It tries to make encrypted pipes cheap enough to use casually.
How do you expose a local port with Tailcat?
Tailcat can expose local TCP ports across the tunnel with --serve.
For example, the README shows:
tailcat --serve=8080,8443
Or also:
tailcat --serve=all
Then the client can connect using the token and specify the port:
tailcat <token> 8080
This opens a useful debugging pattern: you run a local service on one machine, expose it with Tailcat, and another machine reaches it by token without changing system routes or publishing a public endpoint.
It’s especially handy for development servers, callback testing, temporary admin tools, local previews, or internal prototypes that shouldn’t become permanent infrastructure.
There’s also a SOCKS mode:
tailcat socks <token> curl http://server.tailcat:8081/
The README says tokens can also work directly as hostnames in URLs within the SOCKS proxy, with a caveat: Tailcat tokens are case-sensitive, while browsers convert hostnames to lowercase. This works with curl and many CLI tools, but not as a general trick to open the hostname from a browser.
Again, the usage pattern is clear. Tailcat shines most as a native terminal utility.
Does Tailcat work for SSH without opening ports?
Tailcat can run an unauthenticated SSH server on Linux and macOS, or proxy to the system’s SSH server.
The README shows:
tailcat --serve=no-auth-ssh
And on the client side:
tailcat ssh <token>
tailcat ssh <token> ls -la
The phrase “unauthenticated SSH” deserves a pause.
In the simple mode, the connection token works as a reachability secret. Anyone who has the token can connect to that server run. That can be perfectly reasonable for a short debugging session, especially with ephemeral keys, but it’s not the same operational model as a hardened SSH service with long-lived users, keys, audit, and access review.
The README also shows a more secure pattern for longer-duration access: generate a client identity, generate a server key, and serve SSH with an --allow restriction for the client’s public key.
That’s the more interesting pattern if you think beyond a quick test. WireGuard authenticates the client before the SSH server sees a packet, and the service can remain reachable without opening an ingress port.
Still, Tailcat’s stability section is explicit: as of August 27, 2026, the project doesn’t promise API or CLI stability. Treat it as a powerful tool for developers, not a mature access platform.
What about Tailcat tokens and keys?
Tailcat tokens are derived from WireGuard key material and DERP information, so key management defines who can reach a server.
The default mode uses ephemeral keys. Each server run generates a new key in memory and prints a new address. When the process exits, the key is discarded and that address dies. That’s the safest default for one-off uses.
Persisted keys are another thing.
When you run tailcat genkey, Tailcat saves a key to disk so the address can stay stable across restarts. That’s useful if you want a repeatable endpoint, but it changes the trust model: anyone who’s received that address can connect to future servers using that key, unless you restrict clients with --allow.
The README marks a subtle behavior worth remembering: when a saved key called default exists, running tailcat with no arguments automatically uses it instead of generating an ephemeral key. The CLI indicates on startup whether it’s using a new address or a saved key.
That startup line isn’t decoration. It’s part of the security model.
If you want to force an ephemeral key after creating a default key, the README shows:
tailcat --serve=8080 --key=new
```For developers, the central habit is this: knowing whether the token you're sharing is disposable or durable.
## What Role Does DERP Play in Tailcat?
DERP is the rendezvous and fallback relay channel that allows Tailcat to work when two machines can't reach each other directly from the start.
The connection flow is, in practical terms, like this:
1. The server starts, generates or loads a WireGuard key pair, connects to a DERP relay, and prints a token.
2. The client parses the token, learns the server's public key and DERP region, generates its own ephemeral key pair, and connects to the same DERP relay.
3. Client and server perform a discovery handshake across DERP.
4. WireGuard comes online.
5. Both sides attempt NAT traversal and UDP hole punching.
6. If it works, traffic takes a direct peer-to-peer route. If it fails, DERP remains as the fallback route.
This is the small practical miracle behind many peer-to-peer development flows: you don't need to know in advance whether NAT traversal will work. The tool tries. If it can go direct, it goes direct. If not, the connection keeps working via relay.
But DERP is also the tradeoff.
Tailcat's default DERP map points to public relays operated by Tailscale. The README says those relays are free and rate-limited, with no uptime SLA or throughput targets. Tailscale can revoke access anytime.
That's why the default path is excellent for testing the tool, doing demos, running small debugging sessions, and creating occasional pipes. For a serious or repeated flow, the README points to another option: run your own DERP relay or serve your own DERP map.
That boundary is well placed. Public relays make the first experience easy. Operating your own relay makes the operational story yours.
## Does Tailcat Replace Tailscale?
Tailcat doesn't replace Tailscale; it's a low-level utility for developers built with pieces of Tailscale's networking.
The difference matters.
Tailscale gives you identity, devices, users, ACLs, tailnets, policies, administration surfaces, and a control plane. Tailcat removes that layer on purpose. There's no account, no tailnet, and no central policy engine.
Precisely because of that, Tailcat is useful for some jobs and wrong for others.
Use Tailcat when you need:
- A short-lived encrypted pipe.
- A token-routed tunnel.
- A temporary way to expose a local port.
- A quick debugging bridge between two machines.
- A Go library to embed this connection model into your own tool.
- To avoid operating system route changes.
It doesn't make sense to treat Tailcat as a direct replacement for managed network access, team policies, device inventory, or access governance.
The edge is also the function. Tailcat gives developers a very small primitive: token-encrypted connectivity. What you build around it is up to you.
## Why Should Developers Care?
Tailcat matters because it packs a sophisticated network stack into minimal operational flow.
The trend is bigger than a CLI.
Modern development happens across laptops, containers, remote workstations, CI workers, local services, staging, client-like environments, and internal tools. The old assumption that everything useful lives on a friendly LAN no longer holds. So developers improvise: SSH tunnels, reverse proxies, cloudflared-like tunnels, ngrok-style services, VPNs, port forwards, bastions, pastebins, and snippets sent over chat.
Tailcat enters that messy space with a simple promise: create an encrypted tunnel using a token, without joining a control plane and without changing the machine's network configuration.
That works for individual debugging.
It's also interesting as an architectural pattern.
A token can carry enough rendezvous information to start a private encrypted connection. DERP can make the first packet work across NAT. WireGuard can secure the traffic. A userspace TCP/IP stack can avoid privileged changes to the system. A small CLI can expose all of that without asking the developer to become a network engineer for a ten-minute task.
That's good tooling for developers.
The caveat is that simple reachability tools become dangerous when teams forget what controls they're avoiding. Tailcat reduces friction, but it also removes the organizational controls that live in a full networking platform. That's fine for ephemeral work. It needs more thought for durable access.
## What Should You Try First with Tailcat?
The best first test with Tailcat is a disposable pipe between two machines.
Install it with Go, run `tailcat` on one side, copy the token, and send a small payload from the other side. Then try `tailcat ping --until-direct <token>` to see if the connection moves from DERP relay to direct route.
Next expose a local development port:
```sh
tailcat --serve=8080
And connect from the other side:
tailcat <token> 8080
Then inspect key behavior. Run with the default ephemeral key. Generate a saved key. Observe the startup line. Force a new key with --key=new.
That small exercise teaches the whole model:
- Tokens provide reachability.
- Ephemeral keys are disposable.
- Saved keys create durable addresses.
- DERP makes connection startup reliable.
- Direct UDP is a performance improvement, not a requirement.
- With no control plane, the policy on how you share tokens is up to you.
Tailcat went open source in August 2026 during TailscaleUp. As of August 27, 2026, it’s fresh, installable, and explicitly not stable in the way a production platform is stable. That makes it exactly the kind of tool worth testing now with a developer’s eye: useful today, still in motion, and full of ideas that will probably show up in more tools.