Tailscale's tailcat carries netcat-style TCP over the data plane, no control plane needed

Tailscale's tailcat is drawing attention as a netcat-style utility that carries TCP traffic across Tailscale's data plane while skipping the control plane entirely — and according to a walkthrough on dev.to, that combination makes it a natural fit for private AI infrastructure.

What tailcat does

According to the dev.to post, tailcat is essentially netcat for connections that travel over Tailscale's data plane, with no reliance on the control plane that normally coordinates the network. The distinction matters: in Tailscale's architecture, the control plane handles node identity, key distribution and network membership, while the data plane is the peer-to-peer mesh that actually moves packets between machines. A transport that depends only on the data plane removes vendor-side coordination from the critical path — useful in automation, where a control-plane outage or policy change would otherwise break connectivity between already-trusted nodes.

The author describes tailcat as compact and composable, mapping onto habits engineers already have with nc: opening listeners, making connections, forwarding ports and probing services. The post claims the repository gained roughly 790 GitHub stars in a single day, which would point to strong early momentum, though that figure is the author's and has not been independently verified.

A private gateway pattern

The post's central example is an AI inference gateway that never gets a public listener. The gateway runs as a container on a private Docker network, bound to loopback only, so nothing outside the host can reach it. From a trusted build runner or developer workstation, the service is then exposed through tailcat's listener and connect syntax, and ordinary OpenAI-compatible requests — a chat-completions call carrying a bearer token — flow across that transport like any other TCP connection.

The appeal is that model traffic, API keys and prompts travel a private path between known nodes instead of transiting a publicly exposed endpoint or pulling in a separate VPN stack with its own control dependencies.

Keep governance out of the transport

The author is clear about separation of concerns. Quota enforcement, key rotation and model allowlists belong in the gateway layer; tailcat should stay focused on transport. The post also advises keeping local access logs disabled or redacted, and not routing sensitive payloads through observability layers that have no need to see them — reasonable guidance wherever prompts may contain proprietary code or internal data.

Unverified claims in the mix

The same post mixes in promotional details about a third-party relay service, including an OpenAI-compatible base URL and a claim that Anthropic-style prompt caching discounts cache hits by 90 percent. Those specifics rest on a single blog post and should be treated cautiously; the architectural case for tailcat stands independently of whichever upstream provider a team happens to use. The post also leaves open how trust is established between tailcat endpoints once the control plane is out of the picture — a question worth answering before relying on the tool in production.

Why it matters

Teams running LLM gateways usually pick between exposing an authenticated public endpoint or standing up a full VPN. A data-plane-only transport offers a middle path: private reachability between trusted nodes with minimal moving parts and no additional control-plane dependency. Because tailcat borrows nc's mental model, it slots into existing workflows for port forwarding and service probing rather than demanding new tooling knowledge. For private AI infrastructure specifically, keeping inference endpoints off the public internet shrinks the attack surface around API keys and sensitive prompts — provided the tool's own trust model holds up under scrutiny.