Tailcat es una nueva CLI open source de Tailscale para crear túneles cifrados con WireGuard entre dos máquinas usando tokens cortos, sin cuenta de Tailscale, sin permisos root y sin cambios en las rutas del sistema.
Eso la hace sentir como netcat para la red moderna del desarrollador: rápida, scriptable, descartable cuando hace falta y construida sobre las mismas piezas de bajo nivel que vuelven útil a Tailscale.
Lo interesante no es solamente que Tailcat pueda mover bytes entre dos máquinas. Ya existen muchas formas de hacer eso.
Lo interesante es la forma del flujo.
Un lado ejecuta un listener y recibe un token. El otro lado pasa ese token al cliente. La conexión arranca a través de DERP, la capa de relay y rendezvous de Tailscale, y después intenta pasar a UDP directo entre pares cuando la travesía de NAT funciona. El tráfico queda cifrado de extremo a extremo con WireGuard. El control plane de Tailscale no participa.
Para desarrolladores, eso abre un punto medio práctico entre “abrir un puerto”, “configurar acceso VPN”, “pegar cosas en una app de chat” y “levantar un relay temporal en la nube”.
¿Qué es Tailcat?
Tailcat es una CLI y una biblioteca Go que reutiliza componentes open source de red de Tailscale para crear túneles cifrados con WireGuard, direccionados por token, sin usar el control plane de Tailscale.
El proyecto se presenta como “Tailscale sin Tailscale, por Tailscale”. Es una frase juguetona, pero sirve como modelo mental.
Tailcat no une tu máquina a un tailnet. No requiere una cuenta de Tailscale. No modifica tablas de rutas, DNS ni configuración de red del sistema operativo. Corre en userspace y usa una pila TCP/IP también en userspace, así que el flujo normal no necesita permisos de root o administrador.
Eso la acerca más a una utilidad de desarrollo que a un producto completo de red para flotas.
El flujo básico es pequeño:
- Ejecutas
tailcaten la máquina que va a recibir la conexión. - Copias el token de conexión generado.
- Ejecutas
tailcat <token>desde la otra máquina. - Envías datos, conectas a un puerto, usas SSH o activas otro modo soportado.
El token contiene la información que el cliente necesita para encontrar la clave pública WireGuard del servidor y la región DERP. El resto del intercambio de metadatos ocurre fuera de banda, como prefieras: copiar y pegar en la terminal, un mensaje seguro, un ticket, una nota temporal o tu propia automatización.
Ese intercambio fuera de banda es el tradeoff. Tailcat elimina el control plane respaldado por una cuenta, pero vuelve importante al token como artefacto operativo.
¿Cómo instalar Tailcat?
Tailcat se instala con Go o se ejecuta mediante Nix.
El README muestra este comando de instalación con Go:
go install github.com/tailscale/tailcat/cmd/tailcat@latest
También soporta Nix flakes:
nix run github:tailscale/tailcat
nix profile install github:tailscale/tailcat
Esa es toda la historia de instalación publicada en la documentación primaria al 27 de agosto de 2026.
También hay una demo experimental en navegador, compilada a WebAssembly, en https://tailscale.github.io/tailcat/. El README dice que la versión de navegador puede enviar y recibir archivos o texto, e interoperar con la CLI, pero el tráfico del navegador pasa solamente por DERP hasta que exista soporte WebRTC.
Ese detalle importa porque Tailcat tiene dos perfiles de uso muy distintos:
- La CLI puede intentar conectividad directa entre pares después del bootstrap por DERP.
- La demo del navegador es cómoda, pero actualmente depende solo del relay.
Para flujos serios de desarrollo, la CLI es el artefacto principal.
¿Cómo usar Tailcat como netcat?
Puedes usar Tailcat como netcat iniciando un listener en una máquina, copiando su token y enviando datos hacia ese token desde otra máquina.
En el lado servidor:
tailcat
Tailcat imprime un token de conexión y espera.
En el lado cliente:
echo hello | tailcat <token>
El servidor recibe hello y termina.
Esa es la pequeña gracia de la herramienta. No hay ceremonia de port forwarding, no hay unión a un tailnet, no hay configuración de VPN, no hay regla entrante de firewall y no hay dependencia de una cuenta compartida.
Los usos prácticos son exactamente los pequeños trabajos que aparecen todo el tiempo en desarrollo:
- Mover un fragmento de logs entre máquinas.
- Enviar la salida de un comando remoto a un proceso local.
- Probar conectividad a través de NAT complicado.
- Mandar un archivo pequeño o un payload sin levantar un servicio.
- Construir un puente rápido de debugging entre dos entornos.
Tailcat no intenta reemplazar una VPN completa. Intenta que los pipes cifrados sean lo bastante baratos como para usarlos de forma casual.
¿Cómo exponer un puerto local con Tailcat?
Tailcat puede exponer puertos TCP locales a través del túnel con --serve.
Por ejemplo, el README muestra:
tailcat --serve=8080,8443
O también:
tailcat --serve=all
Después, el cliente puede conectarse mediante el token e indicar el puerto:
tailcat <token> 8080
Esto abre un patrón útil de debugging: ejecutas un servicio local en una máquina, lo expones con Tailcat y otra máquina lo alcanza por token sin cambiar rutas del sistema ni publicar un endpoint público.
Es especialmente práctico para servidores de desarrollo, pruebas de callbacks, herramientas administrativas temporales, previews locales o prototipos internos que no deberían convertirse en infraestructura permanente.
También existe un modo SOCKS:
tailcat socks <token> curl http://server.tailcat:8081/
El README dice que los tokens también pueden funcionar directamente como hostnames de URL dentro del proxy SOCKS, con una advertencia: los tokens de Tailcat distinguen mayúsculas y minúsculas, mientras que los navegadores convierten hostnames a minúsculas. Eso sirve con curl y muchas herramientas CLI, pero no como truco general para abrir el hostname desde un navegador.
De nuevo, la forma de uso queda clara. Tailcat brilla más como utilidad nativa de terminal.
¿Tailcat sirve para SSH sin abrir puertos?
Tailcat puede ejecutar un servidor SSH sin autenticación en Linux y macOS, o hacer proxy hacia el servidor SSH del sistema.
El README muestra:
tailcat --serve=no-auth-ssh
Y, del lado cliente:
tailcat ssh <token>
tailcat ssh <token> ls -la
La frase “SSH sin autenticación” merece una pausa.
En el modo simple, el token de conexión funciona como secreto de alcanzabilidad. Cualquiera que tenga el token puede conectarse a esa ejecución del servidor. Eso puede ser perfectamente razonable para una sesión corta de debugging, sobre todo con claves efímeras, pero no es el mismo modelo operativo que un servicio SSH endurecido con usuarios duraderos, claves, auditoría y revisión de acceso.
El README también muestra un patrón más seguro para acceso de mayor duración: generar una identidad de cliente, generar una clave de servidor y servir SSH con una restricción --allow para la clave pública del cliente.
Ese es el patrón más interesante si piensas más allá de una prueba rápida. WireGuard autentica al cliente antes de que el servidor SSH vea un paquete, y el servicio puede quedar alcanzable sin abrir un puerto entrante.
Aun así, la sección de estabilidad de Tailcat es explícita: al 27 de agosto de 2026, el proyecto no promete estabilidad de API ni de CLI. Conviene tratarlo como una herramienta potente para desarrolladores, no como una plataforma madura de acceso.
¿Qué pasa con los tokens y las claves de Tailcat?
Los tokens de Tailcat se derivan de material de claves WireGuard e información DERP, así que el manejo de claves define quién puede alcanzar un servidor.
El modo predeterminado usa claves efímeras. Cada ejecución del servidor genera una clave nueva en memoria e imprime una dirección nueva. Cuando el proceso termina, la clave se descarta y esa dirección muere. Ese es el default más seguro para usos puntuales.
Las claves guardadas son otra cosa.
Cuando ejecutas tailcat genkey, Tailcat guarda una clave en disco para que la dirección pueda mantenerse estable entre reinicios. Eso es útil si quieres un endpoint repetible, pero cambia el modelo de confianza: cualquiera que haya recibido esa dirección puede conectarse a servidores futuros que usen esa clave, salvo que restrinjas clientes con --allow.
El README marca un comportamiento sutil que conviene recordar: cuando existe una clave guardada llamada default, ejecutar tailcat sin más argumentos la usa automáticamente en lugar de generar una clave efímera. La CLI indica al iniciar si está usando una dirección nueva o una clave guardada.
Esa línea de inicio no es decoración. Forma parte del modelo de seguridad.
Si quieres forzar una clave efímera después de haber creado una clave default, el README muestra:
tailcat --serve=8080 --key=new
Para desarrolladores, el hábito central es este: saber si el token que estás compartiendo es descartable o duradero.
¿Qué papel cumple DERP en Tailcat?
DERP es el canal de rendezvous y relay de fallback que permite que Tailcat funcione cuando dos máquinas no pueden alcanzarse directamente desde el inicio.
El flujo de conexión es, en términos prácticos, así:
- El servidor arranca, genera o carga un par de claves WireGuard, se conecta a un relay DERP e imprime un token.
- El cliente parsea el token, aprende la clave pública del servidor y la región DERP, genera su propio par de claves efímeras y se conecta al mismo relay DERP.
- Cliente y servidor hacen un handshake de descubrimiento a través de DERP.
- WireGuard queda activo.
- Ambos lados intentan travesía de NAT y UDP hole punching.
- Si funciona, el tráfico pasa a una ruta directa peer-to-peer. Si falla, DERP queda como ruta de fallback.
Este es el pequeño milagro práctico detrás de muchos flujos peer-to-peer de desarrollo: no necesitas saber de antemano si la travesía de NAT va a funcionar. La herramienta lo intenta. Si puede ir directo, va directo. Si no, la conexión sigue funcionando por relay.
Pero DERP también es el tradeoff.
El mapa DERP predeterminado de Tailcat apunta a relays públicos operados por Tailscale. El README dice que esos relays son gratuitos y rate-limited, sin SLA de uptime ni objetivos de throughput. Tailscale puede revocar el acceso en cualquier momento.
Por eso el camino predeterminado es excelente para probar la herramienta, hacer demos, ejecutar sesiones pequeñas de debugging y crear pipes ocasionales. Para un flujo serio o repetido, el README apunta a otra opción: ejecutar tu propio relay DERP o servir tu propio mapa DERP.
Ese límite está bien puesto. Los relays públicos hacen fácil la primera experiencia. Operar tu propio relay vuelve tuya la historia operativa.
¿Tailcat reemplaza a Tailscale?
Tailcat no reemplaza a Tailscale; es una utilidad de bajo nivel para desarrolladores construida con piezas de red de Tailscale.
La diferencia importa.
Tailscale te da identidad, dispositivos, usuarios, ACLs, tailnets, políticas, superficies de administración y un control plane. Tailcat elimina esa capa a propósito. No hay cuenta, no hay tailnet y no hay motor central de políticas.
Justamente por eso Tailcat es útil para algunos trabajos y equivocada para otros.
Usa Tailcat cuando necesitas:
- Un pipe cifrado de corta duración.
- Un túnel direccionado por token.
- Una forma temporal de exponer un puerto local.
- Un puente rápido de debugging entre dos máquinas.
- Una biblioteca Go para incrustar este modelo de conexión en tu propia herramienta.
- Evitar cambios de rutas del sistema operativo.
No conviene tratar Tailcat como reemplazo directo de acceso de red gestionado, políticas de equipo, inventario de dispositivos o gobernanza de acceso.
El filo también es la función. Tailcat da a los desarrolladores un primitivo muy pequeño: conectividad cifrada por token. Lo que construyes alrededor queda de tu lado.
¿Por qué debería importarle a los desarrolladores?
Tailcat importa porque empaqueta una pila de red sofisticada en un flujo operativo mínimo.
La tendencia es más grande que una CLI.
El desarrollo moderno ocurre entre laptops, contenedores, workstations remotas, workers de CI, servicios locales, staging, entornos parecidos a cliente y herramientas internas. La vieja suposición de que todo lo útil vive en una LAN amable ya no alcanza. Entonces los desarrolladores improvisan: túneles SSH, proxies reversos, túneles tipo cloudflared, servicios estilo ngrok, VPNs, port forwards, bastiones, pastebins y fragmentos enviados por chat.
Tailcat entra en ese espacio desordenado con una promesa simple: crear un túnel cifrado usando un token, sin unirse a un control plane y sin cambiar la configuración de red de la máquina.
Eso sirve para debugging individual.
También es interesante como patrón arquitectónico.
Un token puede llevar suficiente información de rendezvous para iniciar una conexión privada cifrada. DERP puede hacer que el primer paquete funcione a través de NAT. WireGuard puede asegurar el tráfico. Una pila TCP/IP en userspace puede evitar cambios privilegiados en el sistema. Una CLI pequeña puede exponer todo eso sin pedirle al desarrollador que se convierta en ingeniero de redes para una tarea de diez minutos.
Eso es buen tooling para desarrolladores.
La advertencia es que las herramientas de alcanzabilidad simple se vuelven peligrosas cuando los equipos olvidan qué controles están evitando. Tailcat reduce fricción, pero también elimina los controles organizacionales que viven en una plataforma completa de red. Eso está bien para trabajo efímero. Necesita más pensamiento para acceso duradero.
¿Qué deberías probar primero con Tailcat?
La mejor primera prueba con Tailcat es un pipe descartable entre dos máquinas.
Instálalo con Go, ejecuta tailcat en un lado, copia el token y envía un payload pequeño desde el otro lado. Después prueba tailcat ping --until-direct <token> para ver si la conexión pasa de relay DERP a ruta directa.
Luego expón un puerto local de desarrollo:
tailcat --serve=8080
Y conéctate desde el otro lado:
tailcat <token> 8080
Después inspecciona el comportamiento de claves. Ejecuta con la clave efímera predeterminada. Genera una clave guardada. Observa la línea de inicio. Fuerza una clave nueva con --key=new.
Ese ejercicio pequeño enseña todo el modelo:
- Los tokens dan alcanzabilidad.
- Las claves efímeras son descartables.
- Las claves guardadas crean direcciones duraderas.
- DERP vuelve confiable el inicio de conexión.
- UDP directo es una mejora de rendimiento, no un requisito.
- Sin control plane, la política sobre cómo compartes tokens queda de tu lado.
Tailcat fue open source en agosto de 2026 durante TailscaleUp. Al 27 de agosto de 2026, es fresco, instalable y explícitamente no estable en el sentido en que una plataforma de producción es estable. Eso lo vuelve exactamente el tipo de herramienta que vale la pena probar ahora con mirada de desarrollador: útil hoy, todavía en movimiento y lleno de ideas que probablemente aparezcan en más herramientas.