O que é o .self TLD

O .self e uma proposta de domínio de topo (TLD) criada para suportar a prática de self-hosting, hospedar os próprios serviços em servidores pessoais ou privados. A ideia e criar um namespace dedicado para quem quer independência digital real.

Em vez de depender de domínios como .com, .net ou .io gerenciados por registradores comerciais, o .self seria um TLD orientado a comunidade, projetado para máquinas e serviços que não precisam ser resolvidos pela internet pública. A resolução funcionaria em redes privadas, VPNs ou resolvedores DNS alternativos.

A proposta ganhou destaque em junho de 2026 quando um post da HCCF viralizou no Hacker News com centenas de comentários, acendendo debate sobre soberania digital e o papel dos grandes registradores na internet.

Como funcionaria o .self

O modelo proposto não depende da ICANN para funcionar. A ideia central e usar um sistema de resolução DNS alternativo, onde usuários configuram seus resolvedores para reconhecer endereços .self.

Quando você digita meucalendario.self no navegador, o resolvedor DNS configurado na sua rede sabe que deve procurar esse endereço em um diretório distribuído da comunidade, não nos servidores raiz da ICANN. Isso e semelhante ao que projetos como OpenNIC e Handshake já fazem.

A diferença proposta pelo .self e o foco em usabilidade para auto-hospedagem: certificados TLS compatíveis com o namespace, integração com ferramentas como Caddy, Nginx e Traefik, e suporte nativo para redes locais e VPNs como Tailscale e WireGuard.

Por que a comunidade self-hosting se empolgou

O movimento de auto-hospedagem cresceu muito nos últimos anos. Plataformas como Nextcloud, Immich, Jellyfin e Vaultwarden tornaram acessível hospedar em casa o que antes dependia de serviços pagos na nuvem.

O problema que o .self resolve: acessar esses serviços de forma amigável e complicado. Você pode usar o IP local, criar um subdomínio no Cloudflare ou usar o .local do mDNS. O .self oferece uma alternativa padronizada voltada especificamente para esse caso de uso.

Na discussão do HN, muitos devs apontaram o aspecto filosófico: ter um namespace que não pode ser tirado por uma empresa privada ou governo, representando seus serviços pessoais sem depender de infraestrutura centralizada.

Como começar: usando o conceito .self hoje

O .self ainda não e um TLD oficial. Mas você pode experimentar o conceito com ferramentas que já existem. Passo 1: configure um resolvedor DNS local. O Pi-hole com DNS customizado ou o AdGuard Home permitem definir que qualquer domínio .self resolva para um IP da sua rede.

Passo 2: adicione entradas no servidor DNS local, por exemplo meunextcloud.self apontando para 192.168.1.10. Passo 3: aponte os dispositivos da rede para usar o DNS local. Passo 4: use o Caddy como proxy reverso com TLS auto-assinado para cada serviço.

O resultado e acesso tipo meunextcloud.self com HTTPS na sua rede domiciliar, sem expor nada a internet pública.

Exemplo prático: rede domiciliar com .self

Imagine que você tem um servidor caseiro rodando vários serviços. Sem .self, você acessa pelo IP ou por URLs complicadas. Com o conceito .self implementado localmente, cada serviço recebe um nome legível: arquivos.self para o Nextcloud, fotos.self para o Immich, plex.self para o Jellyfin e senhas.self para o Vaultwarden.

Cada serviço tem HTTPS, um nome legível e funciona em qualquer dispositivo da sua rede sem configuração adicional. A configuração e feita uma vez no Pi-hole e todos os dispositivos herdam automaticamente.

Com o Tailscale, você pode estender o mesmo acesso para quando estiver fora de casa. Os endereços .self resolvem pelo Tailscale DNS, sem expor portas ao mundo.

Comparação com alternativas

O .local (mDNS) e nativo no macOS e Linux, mas não funciona em todos os dispositivos Android. Usar um subdomínio real funciona bem com certbot, mas exige domínio pago e expõe o endereço no DNS público. O Cloudflare Tunnel e elegante mas depende de terceiro, violando o principio de independência do self-hosting.

Projetos como OpenNIC e Handshake já oferecem TLDs alternativos, mas com foco em descentralização ampla, não self-hosting especificamente. O .self se diferencia por ser pensado do zero para auto-hospedagem, com suporte a ferramentas populares da comunidade e sem dependência de terceiros.

A escolha entre as abordagens depende do contexto. Para um dev solo em casa, Pi-hole mais Caddy mais conceito .self e provavelmente a combinação mais prática. Para uma equipe corporativa, Tailscale com Magic DNS pode ser mais simples de gerenciar.

Pontos positivos e limitações

O que funciona a favor: o conceito resolve um problema real de forma elegante. A padronização de um namespace dedicado facilita documentação, tutoriais e configurações compartilhadas. Hoje cada um inventa sua própria solução e e difícil compartilhar guias entre comunidades.

Limitações importantes: o .self ainda e uma proposta, não um padrão adotado. Sem aprovação da ICANN, exige resolvedor configurado em cada rede. Isso limita o uso a ambientes controlados e exige configuração manual em cada dispositivo que precisar acessar os serviços.

Outro risco e a fragmentação. Se cada comunidade criar seu próprio TLD alternativo, a confusão aumenta. A proposta só ganha valor se houver adoção suficiente para criar um ecossistema de ferramentas ao redor.

Casos de uso reais

O .self faz sentido para estes perfis:

  • Dev com homelab: você tem servidor em casa com vários serviços. Endereços .self deixam o acesso tao fácil quanto qualquer site comercial, sem configuração por dispositivo.
  • Equipe pequena com servidor próprio: uma startup que hospeda Git, Wiki e CI num servidor próprio se beneficia de endereços padronizados acessíveis pela VPN.
  • Entusiasta de privacidade: quer usar Vaultwarden em vez de 1Password, Immich em vez de Google Fotos. O .self facilita o acesso a todos esses serviços com uma única configuração de DNS.
  • Educador de infraestrutura: ensinar redes, DNS e self-hosting fica mais claro com um namespace dedicado e documentação padronizada.

Dicas e boas práticas

Para adotar o conceito .self hoje na sua rede:

  • Use o Pi-hole ou AdGuard Home como servidor DNS principal. Configure o DHCP do roteador para distribuir o IP do Pi-hole como DNS de toda a rede.
  • Prefira um wildcard DNS local: *.self apontando para o IP do seu proxy reverso. Assim você não precisa criar entradas individuais para cada serviço.
  • Use o Caddy como proxy reverso. A configuração de TLS para domínios internos e mais simples do que no Nginx.
  • Separe os serviços que precisam de acesso externo dos que são apenas internos. Os internos ficam no .self, os externos recebem subdomínio real com certbot.

Vale a pena?

O .self enquanto TLD oficial ainda e uma proposta. Mas o conceito e as ferramentas para implementa-lo localmente são muito reais. Se você prática self-hosting ou quer começar, configurar um DNS local com namespace padronizado e uma das melhores melhorias de qualidade de vida que você pode fazer.

A discussão ao redor do .self reflete algo maior: uma parte crescente da comunidade tech quer mais controle sobre a própria infraestrutura digital. Serviços de nuvem são convenientes, mas dependência total de terceiros tem seus custos em privacidade, preço e disponibilidade.

O próximo passo: instale o Pi-hole ou AdGuard Home na sua rede, configure um DNS local com o namespace .self e teste com um serviço que você já usa. A experiência vai mostrar se essa abordagem faz sentido para o seu caso.