Tailcat é uma nova CLI open source do Tailscale para criar túneis criptografados com WireGuard entre duas máquinas usando tokens curtos, sem conta do Tailscale, sem permissões root e sem alterações nas rotas do sistema.
Isso a faz parecer com netcat para a rede moderna do desenvolvedor: rápida, scriptável, descartável quando necessário e construída sobre as mesmas peças de baixo nível que tornam o Tailscale útil.
O interessante não é apenas que Tailcat possa mover bytes entre duas máquinas. Já existem muitas formas de fazer isso.
O interessante é a forma do fluxo.
Um lado executa um listener e recebe um token. O outro lado passa esse token para o cliente. A conexão é iniciada através do DERP, a camada de relay e rendezvous do Tailscale, e depois tenta passar para UDP direto entre pares quando a travessia de NAT funciona. O tráfego fica criptografado de ponta a ponta com WireGuard. O control plane do Tailscale não participa.
Para desenvolvedores, isso abre um ponto meio prático entre “abrir uma porta”, “configurar acesso VPN”, “colar coisas em um app de chat” e “levantar um relay temporário na nuvem”.
O que é Tailcat?
Tailcat é uma CLI e uma biblioteca Go que reutiliza componentes open source de rede do Tailscale para criar túneis criptografados com WireGuard, direcionados por token, sem usar o control plane do Tailscale.
O projeto se apresenta como “Tailscale sem Tailscale, por Tailscale”. É uma frase bem-humorada, mas funciona como modelo mental.
Tailcat não conecta sua máquina a um tailnet. Não requer uma conta do Tailscale. Não modifica tabelas de rotas, DNS ou configuração de rede do sistema operacional. Roda em userspace e usa uma pilha TCP/IP também em userspace, então o fluxo normal não precisa de permissões de root ou administrador.
Isso a aproxima mais de um utilitário de desenvolvimento do que de um produto completo de rede para frotas.
O fluxo básico é pequeno:
- Você executa
tailcatna máquina que vai receber a conexão. - Você copia o token de conexão gerado.
- Você executa
tailcat` da outra máquina. - Você envia dados, conecta a uma porta, usa SSH ou ativa outro modo suportado.
O token contém as informações que o cliente precisa para encontrar a chave pública WireGuard do servidor e a região DERP. O resto da troca de metadados ocorre fora da banda, como você preferir: copiar e colar no terminal, uma mensagem segura, um ticket, uma nota temporária ou sua própria automação.
Essa troca fora da banda é o trade-off. Tailcat elimina o control plane respaldado por uma conta, mas torna o token importante como um artefato operacional.
Como instalar Tailcat?
Tailcat é instalado com Go ou executado via Nix.
O README mostra este comando de instalação com Go:
go install github.com/tailscale/tailcat/cmd/tailcat@latest
Também suporta Nix flakes:
nix run github:tailscale/tailcat
nix profile install github:tailscale/tailcat
Essa é toda a história de instalação publicada na documentação primária em 27 de agosto de 2026.
Também há uma demonstração experimental em navegador, compilada para WebAssembly, em https://tailscale.github.io/tailcat/. O README diz que a versão do navegador pode enviar e receber arquivos ou texto, e interoperar com a CLI, mas o tráfego do navegador passa apenas por DERP até que exista suporte WebRTC.
Esse detalhe importa porque Tailcat tem dois perfis de uso muito distintos:
- A CLI pode tentar conectividade direta entre pares após o bootstrap por DERP.
- A demonstração do navegador é confortável, mas atualmente depende apenas do relay.
Para fluxos sérios de desenvolvimento, a CLI é o artefato principal.
Como usar Tailcat como netcat?
Você pode usar Tailcat como netcat iniciando um listener em uma máquina, copiando seu token e enviando dados para esse token de outra máquina.
No lado do servidor:
tailcat
Tailcat imprime um token de conexão e aguarda.
No lado do cliente:
echo hello | tailcat <token>
O servidor recebe hello e termina.
Essa é a pequena graça da ferramenta. Não há cerimônia de port forwarding, nenhuma adesão a um tailnet, nenhuma configuração de VPN, nenhuma regra de firewall de entrada e nenhuma dependência de uma conta compartilhada.
Os usos práticos são exatamente os pequenos trabalhos que aparecem o tempo todo no desenvolvimento:
- Mover um fragmento de logs entre máquinas.
- Enviar a saída de um comando remoto para um processo local.
- Testar conectividade através de NAT complicado.
- Enviar um arquivo pequeno ou um payload sem levantar um serviço.
- Construir uma ponte rápida de debugging entre dois ambientes.
Tailcat não tenta substituir uma VPN completa. Tenta tornar os pipes criptografados baratos o suficiente para serem usados de forma casual.
Como expor uma porta local com Tailcat?
Tailcat pode expor portas TCP locais através do túnel com --serve.
Por exemplo, o README mostra:
tailcat --serve=8080,8443
Ou também:
tailcat --serve=all
Depois, o cliente pode se conectar usando o token e indicar a porta:
tailcat <token> 8080
Isso abre um padrão útil de debugging: você executa um serviço local em uma máquina, o expõe com Tailcat e outra máquina o alcança por token sem alterar rotas do sistema nem publicar um endpoint público.
É especialmente prático para servidores de desenvolvimento, testes de callbacks, ferramentas administrativas temporárias, visualizações locais ou protótipos internos que não deveriam se tornar infraestrutura permanente.
Também existe um modo SOCKS:
tailcat socks <token> curl http://server.tailcat:8081/
O README diz que os tokens também podem funcionar diretamente como nomes de host de URL dentro do proxy SOCKS, com um aviso: os tokens de Tailcat diferenciam maiúsculas de minúsculas, enquanto os navegadores convertem nomes de host para minúsculas. Isso funciona com curl e muitas ferramentas CLI, mas não como um truque geral para abrir o nome de host a partir de um navegador.
Novamente, o padrão de uso fica claro. Tailcat brilha mais como um utilitário nativo de terminal.
Tailcat serve para SSH sem abrir portas?
Tailcat pode executar um servidor SSH sem autenticação no Linux e macOS, ou fazer proxy para o servidor SSH do sistema.
O README mostra:
tailcat --serve=no-auth-ssh
E, do lado do cliente:
tailcat ssh <token>
tailcat ssh <token> ls -la
A frase “SSH sem autenticação” merece uma pausa.
No modo simples, o token de conexão funciona como um segredo de alcançabilidade. Qualquer pessoa que tenha o token pode se conectar a essa execução do servidor. Isso pode ser perfeitamente razoável para uma sessão curta de debugging, especialmente com chaves efêmeras, mas não é o mesmo modelo operacional que um serviço SSH endurecido com usuários duradouros, chaves, auditoria e revisão de acesso.
O README também mostra um padrão mais seguro para acesso de maior duração: gerar uma identidade de cliente, gerar uma chave de servidor e servir SSH com uma restrição --allow para a chave pública do cliente.
Esse é o padrão mais interessante se você pensar além de um teste rápido. WireGuard autentica o cliente antes que o servidor SSH veja um pacote, e o serviço pode ficar alcançável sem abrir uma porta de entrada.
Mesmo assim, a seção de estabilidade do Tailcat é explícita: em 27 de agosto de 2026, o projeto não promete estabilidade de API ou CLI. Vale a pena tratá-lo como uma ferramenta poderosa para desenvolvedores, não como uma plataforma madura de acesso.
O que acontece com os tokens e as chaves do Tailcat?
Os tokens de Tailcat são derivados de material de chaves WireGuard e informações DERP, então o gerenciamento de chaves define quem pode alcançar um servidor.
O modo padrão usa chaves efêmeras. Cada execução do servidor gera uma nova chave na memória e imprime um novo endereço. Quando o processo termina, a chave é descartada e esse endereço morre. Esse é o padrão mais seguro para usos pontuais.
As chaves salvas são outra coisa.
Quando você executa tailcat genkey, Tailcat salva uma chave no disco para que o endereço possa permanecer estável entre reinicializações. Isso é útil se você quiser um endpoint repetível, mas altera o modelo de confiança: qualquer pessoa que tenha recebido esse endereço pode se conectar a servidores futuros que usem essa chave, a menos que você restrinja clientes com --allow.
O README marca um comportamento sutil que vale a pena lembrar: quando existe uma chave salva chamada default, executar tailcat sem mais argumentos a usa automaticamente em vez de gerar uma chave efêmera. A CLI indica ao iniciar se está usando um endereço novo ou uma chave salva.
Essa linha de início não é decoração. Faz parte do modelo de segurança.
Se você quiser forçar uma chave efêmera após ter criado uma chave default, o README mostra:
tailcat --serve=8080 --key=new
```Para desenvolvedores, o hábito central é este: saber se o token que você está compartilhando é descartável ou duradouro.
## Qual papel o DERP cumpre no Tailcat?
DERP é o canal de rendezvous e relay de fallback que permite que o Tailcat funcione quando duas máquinas não conseguem se alcançar diretamente desde o início.
O fluxo de conexão é, em termos práticos, assim:
1. O servidor inicia, gera ou carrega um par de chaves WireGuard, se conecta a um relay DERP e imprime um token.
2. O cliente faz parse do token, aprende a chave pública do servidor e a região DERP, gera seu próprio par de chaves efêmeras e se conecta ao mesmo relay DERP.
3. Cliente e servidor fazem um handshake de descoberta através do DERP.
4. WireGuard fica ativo.
5. Ambos os lados tentam travessia de NAT e UDP hole punching.
6. Se funcionar, o tráfego passa para uma rota direta peer-to-peer. Se falhar, DERP fica como rota de fallback.
Este é o pequeno milagre prático por trás de muitos fluxos peer-to-peer de desenvolvimento: você não precisa saber com antecedência se a travessia de NAT vai funcionar. A ferramenta tenta. Se conseguir ir direto, vai direto. Se não conseguir, a conexão continua funcionando por relay.
Mas DERP também é o tradeoff.
O mapa DERP padrão do Tailcat aponta para relays públicos operados pelo Tailscale. O README diz que esses relays são gratuitos e rate-limited, sem SLA de uptime nem objetivos de throughput. O Tailscale pode revogar o acesso a qualquer momento.
Por isso o caminho padrão é excelente para testar a ferramenta, fazer demos, executar sessões pequenas de debugging e criar pipes ocasionais. Para um fluxo sério ou repetido, o README aponta para outra opção: executar seu próprio relay DERP ou servir seu próprio mapa DERP.
Esse limite está bem colocado. Os relays públicos tornam a primeira experiência fácil. Operar seu próprio relay torna a história operativa sua.
## O Tailcat substitui o Tailscale?
O Tailcat não substitui o Tailscale; é um utilitário de baixo nível para desenvolvedores construído com peças de rede do Tailscale.
A diferença importa.
O Tailscale lhe dá identidade, dispositivos, usuários, ACLs, tailnets, políticas, superfícies de administração e um control plane. O Tailcat remove essa camada de propósito. Não há conta, não há tailnet e não há motor central de políticas.
Justamente por isso o Tailcat é útil para alguns trabalhos e inadequado para outros.
Use Tailcat quando precisar:
- De um pipe cifrado de curta duração.
- De um túnel direcionado por token.
- De uma forma temporária de expor uma porta local.
- De uma ponte rápida de debugging entre duas máquinas.
- De uma biblioteca Go para incorporar esse modelo de conexão em sua própria ferramenta.
- Evitar mudanças de rotas do sistema operacional.
Não convém tratar o Tailcat como substituto direto de acesso de rede gerenciado, políticas de equipe, inventário de dispositivos ou governança de acesso.
O fio também é a função. O Tailcat oferece aos desenvolvedores um primitivo muito pequeno: conectividade cifrada por token. O que você constrói ao redor fica do seu lado.
## Por que deveria importar aos desenvolvedores?
O Tailcat importa porque empacota uma pilha de rede sofisticada em um fluxo operativo mínimo.
A tendência é maior que uma CLI.
O desenvolvimento moderno ocorre entre laptops, containers, workstations remotas, workers de CI, serviços locais, staging, ambientes parecidos com cliente e ferramentas internas. A velha suposição de que tudo que é útil vive em uma LAN amigável já não é suficiente. Então os desenvolvedores improvisam: túneis SSH, proxies reversos, túneis tipo cloudflared, serviços estilo ngrok, VPNs, port forwards, bastões, pastebins e fragmentos enviados por chat.
O Tailcat entra nesse espaço desorganizado com uma promessa simples: criar um túnel cifrado usando um token, sem se juntar a um control plane e sem mudar a configuração de rede da máquina.
Isso serve para debugging individual.
Também é interessante como padrão arquitetônico.
Um token pode levar informação de rendezvous suficiente para iniciar uma conexão privada cifrada. DERP pode fazer com que o primeiro pacote funcione através de NAT. WireGuard pode proteger o tráfego. Uma pilha TCP/IP em userspace pode evitar mudanças privilegiadas no sistema. Uma CLI pequena pode expor tudo isso sem pedir ao desenvolvedor que se torne um engenheiro de redes para uma tarefa de dez minutos.
Issa é uma boa ferramenta para desenvolvedores.
A advertência é que as ferramentas de alcançabilidade simples se tornam perigosas quando os times esquecem quais controles estão evitando. O Tailcat reduz fricção, mas também elimina os controles organizacionais que vivem em uma plataforma completa de rede. Isso está bom para trabalho efêmero. Precisa de mais pensamento para acesso duradouro.
## O que você deveria testar primeiro com o Tailcat?
O melhor primeiro teste com o Tailcat é um pipe descartável entre duas máquinas.
Instale com Go, execute `tailcat` em um lado, copie o token e envie um payload pequeno do outro lado. Depois teste `tailcat ping --until-direct <token>` para ver se a conexão passa de relay DERP para rota direta.
Depois exponha uma porta local de desenvolvimento:
```sh
tailcat --serve=8080
E se conecte do outro lado:
tailcat <token> 8080
Depois inspecione o comportamento de chaves. Execute com a chave efêmera padrão. Gere uma chave guardada. Observe a linha de início. Force uma chave nova com --key=new.
Esse exercício pequeno ensina todo o modelo:
- Os tokens oferecem alcançabilidade.
- As chaves efêmeras são descartáveis.
- As chaves guardadas criam endereços duradouros.
- DERP torna confiável o início da conexão.
- UDP direto é uma melhoria de desempenho, não um requisito.
- Sem control plane, a política sobre como você compartilha tokens fica do seu lado.
O Tailcat foi open source em agosto de 2026 durante TailscaleUp. Em 27 de agosto de 2026, é fresco, instalável e explicitamente não estável no sentido em que uma plataforma de produção é estável. Isso o torna exatamente o tipo de ferramenta que vale a pena testar agora com olho de desenvolvedor: útil hoje, ainda em movimento e cheio de ideias que provavelmente aparecerão em mais ferramentas.