VPNSmith
VPS Contabo
self-host-vpnCOMP

NetBird vs Headscale (2026): a sua própria stack, ou o cliente de outra empresa

Ambos permitem alojar o servidor de coordenação por conta própria. O NetBird tem o seu próprio cliente e a sua própria camada de identidade; o Headscale reimplementa o servidor do Tailscale e apoia-se nas apps oficiais do Tailscale. A escolha é sobre qual dependência consegue aceitar.

Por Eric Gerard · Fundador · VPNSmith - Especialista em VPN auto-hospedada e VPS RGPD6 min de leituraPhoto: Pexels

Os dois projetos respondem à mesma pergunta, como corro uma malha WireGuard sem que uma empresa guarde o mapa?, e ambos respondem com honestidade. A diferença não está nas funcionalidades, nem no desempenho. Está em qual dependência está disposto a carregar.

Está a comparar o NetBird com o serviço alojado do Tailscale e não com o Headscale? A nossa comparação NetBird vs Tailscale aborda os planos gratuitos, o preço por utilizador e a única diferença que decide.

A versão numa frase

O Headscale substitui o servidor de coordenação do Tailscale por um que é o utilizador a correr, e mantém os clientes oficiais do Tailscale. O NetBird substitui o produto inteiro: o seu próprio agente, o seu próprio servidor de gestão, o seu próprio dashboard, a sua própria camada de identidade, WireGuard por baixo, nada emprestado por cima.

Esta única diferença estrutural determina quase tudo o resto.

Onde está a dependência

É isto que deve resolver primeiro, porque nenhuma comparação de funcionalidades lhe sobrevive.

Com o Headscale, o servidor é seu, mas o cliente é software mantido pela Tailscale Inc., apontado para o seu servidor através de um URL de login que pode ser substituído. Este arranjo mantém-se há anos e não é contratual. Se quiser ver o compromisso no sentido inverso, o serviço gerido do Tailscale face ao Headscale é a comparação que o enquadra como SaaS versus alojamento próprio.

Com o NetBird, o cliente é o agente do próprio projeto. Ninguém a montante pode alterar o protocolo por baixo de si e, em troca, a cobertura de plataformas, o ritmo de lançamentos e a sobrevivência a longo prazo do projeto ficam todos a cargo do NetBird. Alojar o NetBird por conta própria mostra o que isso implica na prática.

Nenhum é mais seguro em abstrato. Um pede-lhe que confie na tolerância continuada de um fornecedor de clientes; o outro pede-lhe que aposte num projeto mais pequeno que é dono de toda a sua stack.

Uma renderização 3D sobre fundo cinzento-escuro: um anel de poliedros pretos facetados unidos entre si por finas linhas douradas, cada forma ligada a várias vizinhas
Um anel renderizado de formas pretas facetadas unidas por finas linhas douradas, cada uma ligada a várias outras. Os dois projetos existem para construir exatamente esta forma sem que uma empresa guarde o diagrama.

Peças em movimento, contadas com honestidade

O Headscale é um binário Go e uma base de dados. É essa a instalação. Adicionar uma máquina é um comando de login num cliente que a maioria das pessoas já tem.

A instalação predefinida do NetBird arranca vários serviços em conjunto: um servidor de gestão, um servidor de signal, um relay TURN para as ligações que se recusam a ser diretas, um dashboard e um fornecedor de identidade. O docker-compose publicado resume isso a um comando, mas um comando não é um serviço. É mais superfície para atualizar, monitorizar e salvaguardar.

O enquadramento honesto: o NetBird dá-lhe mais de origem, o Headscale dá-lhe menos para manter. Qual dos dois é o bom negócio depende de, à partida, querer ou não uma interface de administração.

A identidade, e porque é que os separa

O NetBird trata a identidade como parte do produto. SSO, mapeamento de grupos e aprovação de dispositivos são o caminho esperado, não uma extensão. Se a resposta a "quem pode entrar nesta rede" tem de vir do Google Workspace, Okta, Entra ou Authentik, isso é uma configuração documentada e não um projeto.

O Headscale suporta OIDC, por isso pode apontar para o seu fornecedor, mas a superfície de gestão à volta é deliberadamente mais escassa. A função do Headscale é falar corretamente o protocolo do Tailscale, não ser um produto de gestão de dispositivos. O controlo de acessos vive em ficheiros ACL compatíveis com o Tailscale, o que é excelente se quiser um ficheiro revisável sob controlo de versões, e pobre se queria uma interface.

Uma tabela que não se esquiva

Se isto o descreveIncline-se para
Portáteis e telemóveis de pessoas que nunca deveriam ver um ficheiro de configuraçãoHeadscale
Quer SSO, grupos e aprovação de dispositivos num único produtoNetBird
Quer o menor número de serviços para correr, atualizar e salvaguardarHeadscale
Recusa-se a depender de todo do cliente de outra empresaNetBird
Quer as regras de acesso num ficheiro revisável no GitHeadscale
Quer uma interface de administração desde o primeiro diaNetBird

O que não afirmaríamos

Não lhe diríamos que um é mais rápido. Ambos transportam o tráfego sobre WireGuard, ambos atravessam o NAT e ambos recorrem a um relay quando não o conseguem, um servidor TURN no NetBird, DERP no Headscale. Numa ligação concreta, o fator decisivo é o seu percurso e o seu hardware, não o emblema no plano de controlo. Se o débito é mesmo a sua restrição, meça a sua própria rota antes de deixar uma tabela comparativa escolher por si.

Também não lhe diríamos que alojar o plano de controlo por conta própria torna a malha altamente disponível. Nos dois projetos, um plano de controlo inacessível deixa os túneis existentes a funcionar, enquanto os novos registos, a rotação de chaves e as alterações de políticas param. É um bom modo de falha, e significa que precisa de uma cópia de segurança do estado do plano de controlo: não de um cluster.

O veredito honesto

Escolha o Headscale se quer a coisa mais pequena que funciona e aceita que o cliente venha de outra empresa. Escolha o NetBird se quer que a identidade, as políticas e uma interface façam parte do mesmo produto, e prefere ser dono de toda a stack em vez de pedir emprestada a parte mais bem mantida.

Em qualquer dos casos, o servidor de coordenação precisa de uma casa: um pequeno VPS sempre ligado, com IP público e um domínio. Para o Headscale, o nosso gerador de configuração Headscale gratuito escreve o config.yaml, o ficheiro Docker Compose e o bloco do reverse proxy; para qualquer um dos dois, um Contabo Cloud VPS 4 (4 vCPU, 8 GB de RAM) é apresentado a partir de 5,50 €/mês em contabo.com (verificado a 17 de outubro de 2026), o que deixa margem para os vários serviços do NetBird. Se preferir um alojamento norte-americano com garantia de reembolso de 30 dias, o Ultahost VPS Basic custa 5,52 $ por mês num contrato de 24 meses (1 GB de RAM, IPv4 dedicado, consultado a 21 de outubro de 2026), o suficiente para um servidor Headscale de uma equipa pequena; para a stack mais pesada do NetBird, escolha o Contabo.

Se nenhuma das dependências o convence e prefere correr uma malha com a sua própria autoridade de certificação, isso é uma terceira forma totalmente diferente: o Headscale comparado com o Nebula segue esse caminho.

★ Datacenter GDPR em Nuremberg · ✓ IPv4 dedicado incluído · porta de 200 Mbit/s

Aloje a sua VPN no seu próprio VPS → ContaboAcesso root completo · IPv4 público · escolha a sua região→

Perguntas frequentes

Qual é a diferença entre o NetBird e o Headscale?
O Headscale é uma reimplementação open source do servidor de coordenação do Tailscale: é o utilizador que corre o servidor, mas as máquinas continuam a usar os clientes oficiais do Tailscale, apontados para o seu servidor em vez do da Tailscale. O NetBird é uma stack completa e própria (o seu agente, o seu servidor de gestão, o seu dashboard e a sua camada de identidade), construída sobre WireGuard mas sem dever nada ao Tailscale. Ou seja, o Headscale substitui um componente do produto de outra empresa, e o NetBird substitui o produto inteiro.
Qual dos dois é mais fácil de alojar por conta própria?
O Headscale, se contar as peças em movimento. É um único binário Go com uma base de dados por trás, e os clientes são apps que os seus utilizadores talvez já tenham instaladas. A instalação predefinida do NetBird arranca vários serviços de uma vez: gestão, signal, um relay TURN para as ligações que não conseguem ser diretas, um dashboard e um fornecedor de identidade. A configuração docker-compose resume isso a um comando, mas continua a ser mais superfície para correr, atualizar e salvaguardar. O NetBird dá-lhe mais de origem; o Headscale dá-lhe menos para manter.
O NetBird ou o Headscale suportam SSO?
Ambos suportam, mas por caminhos diferentes. O NetBird trata a identidade como parte do produto: a instalação padrão inclui um fornecedor de identidade, e ligar um externo (Google Workspace, Okta, Entra, Authentik) é um percurso documentado e não um extra. O Headscale suporta OIDC, por isso pode apontá-lo para o seu próprio fornecedor, mas as peças à volta (mapeamento de grupos, fluxos de aprovação de dispositivos, a interface de administração) são mais escassas, porque a função do Headscale é falar o protocolo do Tailscale, não ser um produto de gestão.
O Headscale é afetado pelo roadmap dos clientes do Tailscale?
Sim, e é o risco estrutural que vale a pena nomear. O Headscale funciona porque os clientes oficiais do Tailscale permitem substituir o servidor de login, e porque o Headscale acompanha um protocolo que não controla. Este arranjo mantém-se há anos e não é contratual. O NetBird tem a exposição oposta: depende do cliente do próprio NetBird, das plataformas que ele suporta e da continuidade do projeto, mas mais ninguém pode alterar o protocolo por baixo de si.
Qual devo escolher para uma equipa pequena?
Se as máquinas forem portáteis e telemóveis de pessoas que nunca deveriam ver um ficheiro de configuração, e se já confia nas apps do Tailscale, o Headscale é a resposta mais leve: clientes maduros, um login familiar, um único serviço para correr. Se quer que a aprovação de dispositivos, as políticas de grupo e o SSO façam parte do mesmo produto, e prefere não depender de todo do cliente de outra empresa, o NetBird foi feito para isso e dá-lhe uma interface de administração desde o primeiro dia.
Posso migrar de um para o outro mais tarde?
Sim, mas conte com reinstalar os clientes em vez de mudar uma opção. Os dois falam protocolos diferentes, por isso migrar significa registar de novo cada máquina com o agente do outro projeto (o cliente Tailscale para o Headscale, o agente NetBird para o NetBird). O esquema de endereçamento e as regras de acesso podem ser transpostos no papel, mas não há nenhuma exportação que transforme uma instalação na outra.