Netcat Is Dead. Tailcat Quietly Killed It Over Tailscale.
In this article
Bottom line: Tailcat is a new open-source CLI, trending on Hacker News with 541 points, that reimplements netcat's pipe-anything-over-a-socket simplicity but routes traffic through Tailscale's WireGuard mesh instead of raw TCP/UDP.
It embeds `tsnet` so a single binary joins your tailnet, dials a peer by its Tailscale hostname, and moves bytes — no open ports, no NAT traversal hacks, no `ncat -e` shell-injection nightmares.
I've spent the past week replacing netcat and socat in my own debugging workflow with it, and the honest answer is: for anything crossing a NAT boundary, it's just better.
I still remember the first time `nc -l -p 4444` saved my job.
Production database was hemorrhaging connections at 2 a.m., I needed to pipe a heap dump off a box with no scp access, and netcat was the only tool guaranteed to already be installed.
That's the whole pitch of netcat — it's everywhere, it does one thing, and it's been doing that one thing since 1995.
Tailcat is the first tool in years that made me question whether that's still the right default.
The Setup: Why Netcat Started Showing Its Age
Here's the scenario that got me looking at Tailcat in the first place.
I run a small fleet of edge boxes — a couple of Raspberry Pis doing sensor ingestion, a mini PC acting as a home lab jump host, and a handful of cloud VMs across two providers.
None of them share a network. Most sit behind NAT with no public IP, no port forwarding, and a "just don't" policy on opening inbound ports.
Every time I needed to move a file, pipe a log stream, or do a quick reverse shell for debugging (authorized, on my own boxes, don't email me), I'd reach for netcat and immediately remember why it's painful in this exact setup.
Netcat has no idea what a NAT is. You either need a public relay, an SSH tunnel as scaffolding, or you're opening a port on a router you don't control.
I already run Tailscale across all these devices for SSH access, so the machines can already see each other by hostname — `pi-sensor`, `edge-vm-1`, `homelab` — over an encrypted mesh that's already solved hole-punching and relay fallback.
What I wanted was netcat's simplicity, but speaking Tailscale's language instead of raw sockets.
Someone on Hacker News apparently wanted the exact same thing, because that's precisely what Tailcat does.
The Core Insight: Netcat's Job, Tailscale's Network
The trick isn't clever cryptography or a novel protocol. It's that Tailcat doesn't touch the public internet's addressing model at all.
It Rides on tsnet, Not Raw Sockets
Tailscale ships a Go library called `tsnet` that lets any program embed a full WireGuard-based mesh client without installing the system daemon. Tailcat is built on it.
When you run `tailcat listen edge-vm-1:9000`, the binary registers itself as an ephemeral node on your tailnet, authenticates against your existing Tailscale identity, and starts listening — reachable by every other device on that tailnet by name, regardless of what NAT or firewall sits in front of it.
Compare that to classic netcat, where `-l -p 9000` binds a socket that's only reachable if the network path already exists.
Tailcat inverts the assumption: the network path always exists, because Tailscale already built it.
The Command Feels Identical, the Guarantees Don't
```
Old way — needs an SSH tunnel or public IP first
nc -l -p 4444 > received_file.tar
Tailcat — works from anywhere on the tailnet, no tunnel setup
tailcat listen 4444 > received_file.tar ```
On the sending side:
``` tailcat send pi-sensor:4444 < heap_dump.tar ```
That's it.
No `-w` flag fighting timeouts, no `socat` fallback because netcat's TLS support is inconsistent across BSD and GNU variants, no manually wrapping the connection in an SSH tunnel because the target's behind three layers of NAT.
The transport is already encrypted at the WireGuard layer, so you're not even leaking plaintext the way raw netcat traffically does when people forget the `-z` scan flag actually still opens a connection.
I tested it moving a 2GB log archive between my homelab and a cloud VM in a different provider's network entirely.
Netcat plus an SSH tunnel took about four minutes of setup before a single byte moved — agent forwarding, tunnel establishment, port conflicts.
Tailcat took eleven seconds, because the tailnet was already up and doing the hard part in the background.
ACLs Become Your Firewall, for Free
The part that actually impressed me is what happens when you combine Tailcat with Tailscale's existing ACL policy file.
Tailscale already lets you write rules like "only the `admin` tag can reach `tag:db` on port 5432." Because Tailcat is just another tailnet client, those same ACLs apply to it automatically.
That means you get netcat-style ad hoc connectivity with the same authorization model your production infrastructure already enforces — not a separate, forgotten firewall rule that somebody has to remember to close after the incident is over.
The Reality Check: This Isn't a Netcat Replacement for Everyone
Now the part where I stop being a fanboy for a second.
Tailcat is not a drop-in replacement if you don't already run Tailscale, and setting up Tailscale just to get Tailcat's benefits is a much bigger ask than "install a package."
It also doesn't touch netcat's most common actual use case: quick local-network port scanning and banner grabbing.
If you're doing `nc -zv target 1-1000` against a box on your LAN, you don't need a mesh VPN for that, and Tailcat doesn't try to compete there.
It's solving the cross-NAT, cross-provider problem specifically, not trying to be netcat's full feature-for-feature successor.
There's also a trust question worth naming directly: you're routing your ad hoc debugging traffic through Tailscale's control plane and, in fallback cases, its DERP relay servers.
For most people that's a non-issue — it's the same trust boundary you already accepted the day you installed Tailscale for SSH.
But if your threat model specifically excludes third-party coordination servers, that's a real tradeoff, not a hypothetical one.
And honestly, the ephemeral node registration adds a few hundred milliseconds of overhead every time you spin up a new connection that a raw TCP socket just doesn't have.
For a one-off file transfer that's nothing. For something latency-sensitive, netcat's dumb simplicity still wins.
The Practical Takeaway: Where I'd Actually Use This
If you already run Tailscale across your infrastructure — homelab, multi-cloud, hybrid on-prem setups — swap Tailcat in for the specific jobs where netcat currently forces you into tunnel gymnastics: ad hoc file transfers between NAT'd boxes, quick log streaming during an incident, or a debugging pipe between machines that don't share a subnet.
Keep plain netcat around for local scanning and anything on a network you don't control with Tailscale.
The workflow shift that actually matters here isn't "netcat is obsolete." It's that the boundary between "local network tool" and "distributed systems tool" is dissolving, and a lot of Unix utilities built assuming a flat local network are going to get these mesh-aware cousins over the next couple of years.
Tailcat is an early, well-executed example. I wouldn't be surprised to see similar treatments of `rsync` or `curl` show up on Hacker News before 2027 is out.
For now, my practical rule: if the two machines are on the same LAN, reach for netcat like always.
If you're crossing a NAT boundary you don't control, Tailcat has already saved me more debugging time in a week than I expected.
Has your team already replaced other classic Unix networking tools with mesh-VPN-aware versions, or is netcat still the thing everyone reaches for out of habit?
