Headscale em VPS vale a pena? Review do Tailscale auto-hospedado

Headscale vale a pena para quem já administra uma VPS e consegue cuidar de domínio, TLS, política de rede, backup e atualização. Ele permite usar clientes Tailscale com um servidor de controle próprio. Para quem quer praticidade ou não tem plano de recuperação, o Tailscale gerido costuma ser a escolha mais segura.

Como este review foi avaliado

Este é um review editorial baseado na documentação oficial do Headscale e da Tailscale. A análise compara requisitos, limitações e responsabilidades operacionais publicados pelos projetos. Ela não é relato de uso próprio.

O Runzos não instalou Headscale para este artigo, não mediu latência ou disponibilidade, não testou clientes e não executou uma restauração de backup. Por isso, os pontos positivos, os limites e o veredito abaixo são uma análise documental e condicional. Eles não substituem um teste no seu ambiente.

Pontos positivos documentados

Headscale permite usar clientes Tailscale com um control server próprio. A documentação também posiciona o projeto para self-hosters, hobbyistas e pequenas organizações em uma única tailnet.

Limites documentados

O projeto não oferece paridade completa com o Tailscale gerido. Device postures e IP sets não estão disponíveis. A operação ainda exige domínio, TLS, política de acesso, cópias de segurança, atualização e recuperação.

Um painel de administração aberto na internet vira uma dívida operacional. Portainer, bancos, automações e serviços internos passam a depender de regras de firewall, atualizações e credenciais expostas ao mundo inteiro.

Uma rede privada resolve parte desse cenário. Ela conecta notebook, celular e servidores por uma malha de acesso. O Headscale entra quando você quer controlar o servidor que coordena essa malha, em vez de depender do serviço gerido da Tailscale.

A questão não é anonimato. Também não é uma promessa de que todo tráfego passará pela sua VPS. A decisão é sobre acesso privado a apps que você já opera e sobre a disposição de assumir o Custo de Plantão: o tempo de manter domínio, TLS, chaves, políticas, cópias de segurança e recuperação.

Resposta curta: Headscale vale para quem aceita o Custo de Plantão

O Headscale é uma implementação open source e auto-hospedada do servidor de controle do Tailscale. O próprio projeto o posiciona para self-hosters, hobbyistas e pequenas organizações, dentro do escopo de uma única tailnet. O repositório oficial do Headscale deixa claro esse foco mais estreito.

Isso funciona bem quando você já mantém uma VPS para seus apps e entende o básico de operação. Você precisa ter um domínio público, HTTPS, uma conta dedicada, uma política de acesso e cópias de segurança antes de atualizar. A documentação recomenda expor HTTPS em TCP 443 e manter a porta TCP 9090 de métricas e depuração fora da internet pública. Os requisitos de produção do Headscale detalham esses pontos.

Para uma pessoa que só quer acessar arquivos ou serviços sem administrar essa camada, o Tailscale gerido reduz tarefas. Para uma equipe que precisa de recursos empresariais específicos, vale confirmar as limitações do Headscale antes da migração. Device postures e IP sets, por exemplo, não estão disponíveis no projeto.

A leitura do Runzos é simples: uma VPS barata deixa de ser barata quando uma alteração de política bloqueia seu acesso ou quando uma atualização encontra um backup inútil. Controle é útil quando a rotina já comporta esse plantão.

O que o Headscale controla e o que ele não controla

Headscale é o control plane da rede. Ele registra dispositivos, distribui chaves públicas e aplica as políticas que definem quem conversa com quem. Isso permite apontar clientes Tailscale para um servidor personalizado. A própria documentação da Tailscale explica essa configuração e cita Headscale como uma implantação autogerida. Veja como configurar um control server personalizado.

O control plane não precisa ser o caminho de todos os dados. Os pares tentam estabelecer uma conexão direta. Quando a travessia de NAT impede esse caminho, um relay DERP pode encaminhar o tráfego. Portanto, hospedar Headscale em uma VPS não significa que todo pacote passa por ela.

O control plane distribui coordenação; os dados tentam seguir direto e usam relay apenas como caminho alternativo.

Relay DERP é contingência, não detalhe decorativo

O DERP embutido do Headscale vem desativado. Quando habilitado, ele também usa STUN em UDP 3478. A função do relay é ajudar quando dois dispositivos não conseguem se conectar diretamente. A documentação DERP do Headscale explica essa função.

Há um cuidado importante: remover o mapa DERP padrão e manter apenas um relay próprio cria um ponto único de falha. Se esse relay parar, a conectividade de pares que dependem dele pode sofrer. Isso não exige abandonar o Headscale; exige evitar uma simplificação que pareça soberana no diagrama e frágil na operação.

Política permissiva abre mais do que parece

A documentação do Headscale informa que, sem um arquivo de política carregado, todos os nós podem se comunicar. Uma policy vazia também produz allow-all. Para negar tudo inicialmente, a configuração precisa declarar grants: e liberar apenas o necessário depois.

Esse é o ponto em que a rede privada deixa de ser só uma conveniência. Um dispositivo aprovado na malha pode alcançar mais serviços do que deveria se as Grants forem permissivas. Comece com poucos acessos: notebook administrativo para VPS de apps, celular para um serviço específico, e nada além disso até haver uma razão clara.

Headscale, Tailscale e WireGuard manual: qual encaixa na sua rotina?

As três opções usam a ideia de rede privada, mas distribuem o trabalho de forma diferente. WireGuard é a base técnica de uma interface de rede segura. Tailscale acrescenta coordenação, identidade e travessia de NAT como serviço. Headscale oferece uma forma auto-hospedada de controlar essa coordenação, com compatibilidade para clientes Tailscale e limites documentados.

A compatibilidade com clientes Tailscale é uma vantagem prática do Headscale. Ela não garante paridade com o produto gerido. O projeto documenta ausência de device postures e IP sets, além de apenas um subconjunto de autogroups. Se esses recursos sustentam sua política atual, a migração precisa ser redesenhada antes de qualquer troca de login server.

WireGuard manual pode servir a uma topologia pequena e estável. Porém, a cada dispositivo novo, troca de chave ou mudança de rede, o trabalho reaparece. Tailscale gerido absorve boa parte dessa operação. Headscale fica no meio: entrega um servidor de controle próprio, mas mantém você responsável por sua disponibilidade e pela política.

No briefing desta pauta, a pesquisa de DataForSEO registrou em 22 de setembro de 2026 um volume mensal brasileiro de 33.100 buscas para “tailscale” e 590 para “headscale”. Isso descreve interesse de busca naquele recorte; não mede adoção, desempenho ou segurança de nenhuma opção.

O mínimo de VPS e rede para evitar um incidente

A instalação de produção precisa de IP público, domínio e HTTPS em TCP 443. Use uma conta local dedicada ao processo. A porta TCP 9090 deve permanecer privada, pois atende métricas e depuração. Se você habilitar o DERP embutido, inclua a necessidade de STUN em UDP 3478 na análise de firewall.

A entrada pública deve ser controlada; métricas e depuração permanecem privadas, com relay tratado separadamente.

Não transforme essas portas em uma lista para abrir sem contexto. O desenho da sua rede define o que precisa estar acessível. Serviços como banco, Portainer e painéis internos não ganham motivo para ficar públicos porque agora existe uma malha privada. A malha reduz exposição; firewall, atualização e autenticação continuam necessários.

Faça backup antes de cada upgrade

Atualizações do Headscale aplicam migrations no banco. Por isso, a documentação recomenda backup antes do processo. No arranjo padrão, ela aponta a configuração em /etc/headscale/config.yaml, os dados em /var/lib/headscale e o banco SQLite em /var/lib/headscale/db.sqlite. A orientação de upgrade do Headscale deve entrar no seu procedimento operacional.

Backup sem restauração testada ainda deixa dúvida. Antes de atualizar, registre como recuperar a configuração e o banco em uma VPS de teste ou em um ambiente separado. Preserve também um acesso SSH que não dependa da malha. Se a política ou o control plane falhar, você precisa de uma rota para corrigir a infraestrutura sem abrir um painel administrativo para a internet.

A recomendação editorial tem um limite claro: este artigo não confirma um teste de restauração do Runzos. Ele indica o processo que a documentação exige e o risco operacional que você deve resolver antes de depender da rede.

Não use Headscale se você não consegue cumprir este checklist

Headscale é uma ferramenta para reduzir exposição de administração, não uma forma de terceirizar responsabilidade para uma VPS. Se os itens abaixo ainda não têm dono, mantenha um serviço gerido ou adie a implantação.

Domínio, TLS, firewall, backup, restauração e acesso de emergência precisam estar prontos antes da dependência operacional.

Também evite Headscale se você espera uma troca sem manutenção. O projeto tem escopo delimitado e recursos ausentes em relação ao serviço Tailscale. Uma equipe sem pessoa responsável por rede, identidade e recuperação ganha pouco ao trazer essa carga para dentro de casa.

Discurso oficial, evidência e recomendação prática

A documentação oficial apresenta Headscale como alternativa auto-hospedada e open source ao control server do Tailscale para self-hosters e hobbyistas. Esse discurso é coerente com a compatibilidade de clientes e com a possibilidade de hospedar sua coordenação.

A mesma documentação limita a expectativa. Há requisitos de HTTPS, banco, backups e atualização. Há diferenças de política frente ao Tailscale. Há DERP para cenários em que a conexão direta não fecha. Nenhum desses pontos invalida o projeto; eles definem o trabalho que acompanha a escolha.

A reconciliação prática do Runzos evita dois erros. O primeiro é tratar Headscale como uma VPN para anonimato. O segundo é vendê-lo como economia automática. Para quem já opera VPS e prefere assumir o control plane, ele pode organizar acesso privado a apps internos. Para quem não consegue responder por essa operação, o serviço gerido preserva tempo e reduz pontos de manutenção.

Recomendações por perfil

Solo builder com VPS e apps internos: Headscale faz sentido se você já cuida de domínio, TLS, firewall e backup. Comece com poucos dispositivos e uma policy restritiva. Seu objetivo é acessar administração sem deixar painéis expostos por padrão.

Iniciante ou equipe sem operador: mantenha o Tailscale gerido ou adie a mudança. O ganho de controle não compensa se uma falha de configuração deixa todos sem acesso ou se ninguém sabe restaurar o banco.

Quem precisa de recursos empresariais específicos: confira primeiro as limitações de policy. O Headscale não implementa device postures e IP sets, entre outras diferenças documentadas. A compatibilidade do cliente não substitui essa avaliação.

Se o seu cenário passou pelo checklist, uma VPS é a base da operação. Veja VPS para rodar sua rede privada e apps self-hosted. Compare a oferta com sua necessidade de domínio, backup e suporte antes de migrar qualquer acesso administrativo.

Como alternativa, a oferta de VPS da Hostinger para n8n pode servir a quem quer avaliar outra rota de infraestrutura. A escolha da VPS não dispensa os controles descritos acima.

FAQ sobre Headscale em VPS

Headscale funciona com o aplicativo Tailscale?

Sim. A documentação da Tailscale permite configurar clientes para usar um control server personalizado e cita Headscale como implantação autogerida. A alteração pode ser feita pela interface em alguns clientes ou com o comando de login indicado pela documentação. Antes da troca, confira quais recursos de policy sua rede usa, porque Headscale não oferece paridade completa com o serviço gerido.

Headscale é uma VPN para anonimato?

O objetivo tratado aqui é acesso privado entre dispositivos e serviços que você opera. Headscale controla a coordenação da sua tailnet; ele não é uma promessa de anonimato. O tráfego tenta conexão direta entre pares e pode usar relay DERP quando necessário. Privacidade, firewall, atualização e política de acesso continuam exigindo decisões operacionais.

Quais portas preciso abrir?

A documentação de produção recomenda HTTPS em TCP 443 e pede que TCP 9090, usado para métricas e depuração, não fique público. O DERP embutido vem desativado; quando você o habilita, ele também usa STUN em UDP 3478. Revise o desenho da sua rede antes de alterar regras de firewall.

Posso apagar os relays DERP padrão?

É possível configurar relays, mas operar apenas um DERP embutido próprio cria um ponto único de falha. A documentação alerta que isso pode afetar a conectividade quando pares precisam de relay. Mantenha essa consequência explícita no seu plano, em vez de remover o mapa padrão apenas para centralizar tudo na VPS.

Como evitar perder acesso durante uma atualização?

Faça backup antes do upgrade, porque migrations são aplicadas ao banco. Guarde a configuração e os dados apontados pela documentação, além de testar a restauração fora da produção. Mantenha SSH de emergência independente da malha. Assim, uma policy incorreta ou um serviço indisponível não obriga você a expor um painel interno para recuperar o controle.

Veredito: vale a pena hospedar Headscale em uma VPS?

Vale quando a rede privada faz parte da sua operação de VPS e você aceita mantê-la. Headscale ajuda a coordenar dispositivos e reduzir a exposição de serviços administrativos. Ele não elimina firewall, backups, upgrades nem a necessidade de revogar um dispositivo perdido.

O Custo de Plantão é a régua mais honesta. Se domínio, TLS, política, cópia de segurança e recuperação já têm lugar na sua rotina, o control plane próprio pode trazer autonomia útil. Se esses itens dependem de improviso, o Tailscale gerido entrega uma escolha mais prudente. Escolha a infraestrutura depois de decidir quem responderá pelo acesso quando algo falhar.