Construindo o ambiente definitivo de self-hosting

 (codecaptured.com)
26 pontos por GN⁺ 2025-07-20 | 2 comentários | Compartilhar no WhatsApp
  • Após anos testando diferentes abordagens de self-hosting, o autor compartilha a experiência de ter finalmente construído com sucesso um ambiente personalizado
  • Os principais objetivos eram controle dos dados pessoais e manutenção de uma infraestrutura confiável, combinando para isso várias tecnologias centrais como NixOS, ZFS, Tailscale e Authelia
  • Pensando também na usabilidade para família e conhecidos, reforçou a acessibilidade com SSO, uma página inicial dedicada e outros recursos
  • Organiza em detalhes os problemas encontrados na operação real e as soluções concretas adotadas (ex.: proxy público para serviços privados, ambiente VPN misto, integração de autenticação)
  • No futuro, planeja melhorias adicionais como infraestrutura de backup e reforço de segurança, além de deixar dicas práticas e materiais de referência

Introdução e motivação

  • Depois de tentar várias formas de self-hosting ao longo de alguns anos, o autor montou um ambiente "bom o suficiente" que atende às suas necessidades
  • Consultou diversos materiais open source e experiências de outras pessoas, e compartilha esse processo para ajudar outros desenvolvedores

Objetivos

  • Buscar mais privacidade e reduzir o risco de mudanças ou descontinuação de serviços, mantendo controle direto sobre os dados pessoais e os serviços correspondentes
  • Oferecer esse mesmo controle à família e a pessoas próximas, com foco em criar um ambiente de serviços confiável

Requisitos

  • Requisitos obrigatórios

    • Limitar ao máximo a exposição dos serviços à internet pública, reduzindo o risco de incidentes de segurança
    • Minimizar indisponibilidade da infraestrutura crítica causada por erros, evitando dependências circulares e facilitando rollback de configuração
    • Ter propriedade direta dos componentes centrais como autenticação, rede e domínio, priorizando soluções open source
    • Considerar a usabilidade do ponto de vista de família e conhecidos (login SSO consistente, necessidade mínima de manutenção)
    • Adotar ativamente uma configuração declarativa por arquivos, facilitando versionamento, backup, recuperação e reaproveitamento de configurações de terceiros
    • As atualizações precisam ser fáceis e seguras, para permitir manutenção periódica

  • Requisitos não prioritários

    • Modularização extrema/organização impecável não são necessárias (praticidade em primeiro lugar)
    • Nem tudo precisa ser open source, mas usar quando possível
    • Não busca alta disponibilidade (HA); aceita downtime em troca de uma estrutura mais simples

Escolhas tecnológicas

  • NixOS

    • Uma distribuição Linux que gerencia de forma declarativa toda a configuração do sistema operacional com a linguagem Nix e seu gerenciador de pacotes
    • Como a configuração vira código, é possível fazer versionamento e rollback estruturado
    • Também oferece suporte a diversos pacotes e integração com Docker/PODMAN
    • O autor acumulou conhecimento consultando configurações Nix de outros desenvolvedores

  • ZFS

    • Um sistema de arquivos de alto desempenho com ótimos recursos de proteção de dados, como snapshots e rollback
    • Configurado com 4 HDDs de 10TB em RAIDZ2 (tolerando falha simultânea de 2 discos) e cache em um SDD de 256GB
    • Gerenciamento com separação entre datasets de arquivos e mídia e montagens NFS por finalidade
    • Estrutura uma arquitetura de armazenamento principal simples e confiável

  • Tailscale & headscale

    • Tailscale: uma Mesh VPN de fácil acesso que permite entrar na rede interna sem exposição à internet pública, apenas instalando o cliente
    • Headscale: backend open source auto-hospedável para Tailscale, eliminando o risco de mudanças na política da empresa
    • Traz ganho de segurança de rede, mas exige instalação do cliente nos dispositivos dos usuários
    • Do ponto de vista de usabilidade, a necessidade de instalar um cliente em cada aparelho ainda é uma barreira de entrada

  • Authelia & LLDAP

    • Authelia: solução de SSO, autenticação e autorização baseada em OpenID Connect, com integração possível ao proxy nginx
    • LLDAP: Lightweight LDAP, usado para gerenciar usuários e grupos do Authelia e como autenticação de backup
    • Funciona bem com poucos recursos, mas a configuração é complexa e há uma curva de aprendizado para entender como integrar cada serviço

Projeto da estrutura

  • Arquitetura

    • Cada servidor recebe o nome de um planeta de Star Wars
    • O ponto de entrada (public server) é "taris", oferecendo Authelia, headscale, blog e outros serviços essenciais
    • headscale, Authelia e LLDAP precisam ser acessíveis externamente e, por isso, operam de forma pública dentro de um escopo limitado
    • Serviços privados (Foundry VTT, monitoramento etc.) são expostos seletivamente por proxy via NGINX

  • Servidores privados

    • No servidor principal "kuat", o TrueNAS gerencia uma VM com NixOS e o pool de armazenamento ZFS
    • O escopo de snapshot/backup é separado entre "files" (dados irrecuperáveis) e "media" (dados recuperáveis, se desejado)
    • Os principais serviços rodam na VM "bespin" com NixOS, e há também uma VM separada para testes ("alderaan")

  • Outros serviços

    • Dispositivos mission-critical são configurados como appliances de propósito único (ex.: para casa inteligente, usa Home Assistant OS em separado)
    • O servidor Matrix e o cliente Element usam o Ansible Playbook oficial
    • E-mail e gerenciamento de senhas são terceirizados para serviços externos como ProtonMail e Bitwarden, evitando dependências circulares

Problemas específicos e soluções

  • Página inicial de serviços

    • Um dashboard simples baseado em Flame melhora a acessibilidade aos serviços para cada usuário
    • Como consome poucos recursos e tem bom acabamento visual, é operado de forma prática até a adoção de uma alternativa melhor

  • Uso simultâneo de Tailscale e outras VPNs

    • Alguns sistemas operacionais (especialmente Android e Windows) não permitem múltiplas VPNs ao mesmo tempo
    • Combinando o recurso de exit node do Tailscale com o Gluetun (cliente VPN em container), é possível rotear por VPNs externas como ProtonVPN
    • Há efeitos colaterais, porém, como maior consumo de bateria e quedas ocasionais de velocidade

  • Cuidados com autenticação (Authentification)

    • Principais protocolos de autenticação em serviços self-hosted: OIDC (prioridade), OAuth e LDAP
    • Cada serviço e o Authelia exigem configuração separada
    • A conta de administrador deve ser mantida separadamente da integração com Authelia/LLDAP, garantindo um meio de recuperação em caso de falha de autenticação
    • Em serviços sem suporte a OIDC, o controle de acesso é implementado integrando NGINX e proxy do Authelia
    • O OIDC do Authelia e o controle de acesso via NGINX Proxy precisam de configurações separadas

  • DNS e emissão de SSL

    • Serviços públicos operam do modo tradicional (domínio → IP público)
    • Serviços internos usam o subdomínio "internal" e IPs do Tailscale, bloqueando exposição externa
    • Os certificados SSL usam o suporte nativo do Let's Encrypt no NixOS (HTTP-01 para serviços públicos e DNS-01 para internos)

  • Cuidados na instalação do NixOS em VPS

    • Muitos VPS não oferecem opção de instalação do NixOS
    • Quando necessário, é preciso consultar a wiki da comunidade e afins para confirmar os caminhos de instalação suportados

  • Montagem de datasets do TrueNAS em VMs

    • O firewall padrão do TrueNAS bloqueia o acesso do host a partir da VM
    • A montagem dos datasets NFS foi implementada seguindo o guia oficial (criação de rede bridge)

  • Proxy público para serviços pessoais

    • Em um ambiente baseado em headscale, é possível expor serviços privados externamente com NGINX proxyPass
    • Além do Tailscale Funnel oficial, o autor fornece exemplos de configuração e materiais de referência

Próximos passos e desafios

  • Necessidade de adicionar um servidor de backup dedicado e um processo de validação de recuperação
  • Planeja usar mais ativamente o controle de acesso do Tailscale/headscale
  • Pretende avançar com reforços adicionais de segurança, incluindo acesso via SSH
  • Avalia adotar soluções locais de DNS com criptografia e cache, como Pi-hole e AdGuard Home
  • Considera expandir com novos serviços como Forgejo, Manyfold e RomM

Materiais de referência

Leituras relacionadas

2 comentários

 
opminsu 2025-07-25

Que legal!
 
GN⁺ 2025-07-20
Comentários do Hacker News

  • Para que família e amigos consigam usar com facilidade, o objetivo é fazer cada pessoa acessar vários serviços com uma conta de login por pessoa, baseada em SSO (single sign-on); essa parte é realmente difícil, mas ao mesmo tempo é a mais legal. Open source e Linux são bem paradoxais: estão literalmente em todo lugar e lidam com todos os protocolos, mas construir de fato o ambiente cliente, ou seja, conectar pessoas e montar você mesmo os elementos de groupware, acaba sendo ainda mais complexo. O próprio processo de integrar vários sistemas de forma orgânica e montar até a infraestrutura de diretório já é impressionante. Nunca imaginei que um dia operaria FreeIPA ou um serviço de diretório compatível com Windows, mas ultimamente também parece que o mundo baseado em OpenID está finalmente se consolidando

    • Valeu pela empatia. Login simples e acessibilidade foram os requisitos mais difíceis deste projeto, e acho que são justamente o ponto que determina se as pessoas vão usar ou não. Open source realmente está em todo lugar, mas os problemas começam quando um usuário comum tenta usar alguma coisa por conta própria. Acho que esse paradoxo existe porque cada projeto quer inovar por conta própria. A falta de uma força puxando tudo numa mesma direção é ao mesmo tempo vantagem e desvantagem. Ainda assim, olhando só para o ecossistema de self-hosting nos últimos 5 anos, sinto que ficou muito mais fácil tanto de instalar quanto de usar

    • Concordo muito com esse paradoxo. Ontem mesmo postei na minha plataforma de validação sobre como FOSS é pouco acessível para quem não é técnico. Isso me faz pensar se uma plataforma tipo integrador de sistemas, que conecte usuários técnicos e não técnicos, não poderia ser uma solução

    • Na verdade não é tão difícil assim. Se, em vez de se apegar a um serviço específico, você colocar suporte a SSO como principal critério de seleção, dá para montar tudo com uma facilidade surpreendente. Eu também quase não tinha experiência no começo, mas usei caddy e authentik e completei rapidinho meu sistema self-hosted. Como alternativa, o yunohost é uma distro muito fácil que já configura até o SSO para você

    • Eu uso autenticação SSO com Google, Discord e GitHub via authentik. Funciona bem o suficiente para todo mundo

  • Sei que pode levar tempo até cada pessoa encontrar o sistema “ideal” para si, porque cada um tem objetivos, preferências e ambiente diferentes. Quero compartilhar em um post de blog como cheguei ao meu setup final, cobrindo objetivos e requisitos, tecnologias usadas, arquitetura e processo de resolução de problemas. Meu jeito não vai servir para todo mundo, mas espero que ainda assim ajude outras pessoas. Eu também cresci graças a muito conteúdo e software livre, então quero continuar retribuindo essa ajuda

    • Queria saber como foi sua experiência usando Nix no homelab. Eu sigo numa pegada hardcore, tocando há mais de 7 anos um rack 25U com kubernetes pequeno, ceph e Talos Linux, mas venho querendo simplificar cada vez mais e, no fim das contas, sempre acabo chegando em Nix e ZFS. Essas dificuldades me são muito familiares. Se você também tiver curiosidade sobre algo, pode perguntar

    • Você já considerou usar coolify? Eu uso há mais de 1 ano e gosto bastante de como ele faz deploy automático a partir do GitHub no estilo Heroku https://coolify.io/

    • Fiquei curioso se você também usa a criptografia do ZFS. Antes eu rodava várias VMs, incluindo FreeIPA, em Debian+ZFS, mas depois simplifiquei: hoje deixo só a biblioteca criptografada do Seafile num VPS e faço backup para o servidor de casa via ZFS send/receive. Esse servidor liga toda noite, atualiza, sincroniza e volta a dormir. Para ficar ainda mais seguro, estou pensando em rodar o ZFS do meu desktop Linux (Fedora) também com criptografia total. Como meu dataset principal já é criptografado, sincronizar com drive externo ou nuvem fica bem mais simples. Subir meu arquivo inteiro de fotos para o Seafile no VPS sai caro, então ainda estou procurando uma saída

    • Gostei muito do relato do setup e das explicações detalhadas. Não consigo adotar tudo de imediato como você, mas decidi instalar o flame como dashboard e testar com a família

    • Prazer. Seu trabalho é muito interessante. Eu também estou tocando um projeto parecido baseado em NixOS. Meu objetivo é fazer uma caixinha quase zero-config, com uma pegada Apple, que qualquer pessoa possa ligar no modem e concluir só com um assistente de instalação web. Ainda está no começo, mas já roda aqui em casa. Ela faz ao mesmo tempo o papel de roteador híbrido (OPNSense/PFSense) e servidor de apps (Nextcloud, Synology, Yunohost etc.). Toda a configuração também é gerenciada em uma única camada de módulos Nix: DNS dinâmico, certificados Let's encrypt, subdomínios automáticos para cada app, bloqueio de anúncios e headscale embutido. Agora estou implementando SSO também, e pretendo pegar algumas ideias do seu post. Mais detalhes em https://homefree.host

  • Às vezes eu olho para a rede da minha casa e imagino o estrago que causaria para minha família se eu morresse, ou o quanto seria difícil para alguém de fora entender meu setup. “Brincar de homelab” na verdade preenche algo parecido com o hobby de senhores de outra geração que montavam trilhos de trem em miniatura no porão. Não digo isso de forma pejorativa; acho que algumas pessoas têm esse instinto de querer um mundo em miniatura totalmente sob seu controle

    • Penso exatamente igual, então deixei uma documentação pronta para o caso de acontecer algo. A parte 1 fala de dinheiro e de onde estão documentos importantes; a parte 2 traz instruções de como deixar a casa “mais burra” de novo. Por exemplo, como remover interruptores inteligentes e voltar aos tradicionais, como migrar serviços-chave como o Bitwarden para a nuvem, custos para manter domínio/e-mail, como voltar o roteador para o equipamento padrão da operadora etc. Minha esposa nunca foi muito fã da casa inteligente, mas ficou tranquila ao saber que sempre dá para voltar a uma “casa burra”. Sinceramente, nem sei o quanto isso faria falta se sumisse tudo, mas pelo menos me consola pensar que não seria mais problema meu

    • Guardo as fotos da família em um home lab RAID1 e toda noite faço backup via rsync para um drive externo num computador na casa da minha cunhada. Além do backup, a ideia é que, se acontecer alguma coisa, minha família consiga acessar tudo com facilidade. Como minha esposa não liga para TI, só deixei combinado: “se conectar o USB, está tudo lá”

    • Acho que dá para ignorar cenários de ameaça pouco úteis, como roubo de disco físico. O mais prático é deixar todas as fotos e documentos importantes sem criptografia e com instruções fáceis de entender junto. A parte de automação residencial me preocupa bem mais

    • Pensar com antecedência no que fazer se a pessoa que opera o homelab ficar muito tempo ausente ou vier a falecer é algo realmente importante. Eu não fiz meu setup pensando especificamente em facilitar isso, mas sinto que deveria refletir mais sobre o assunto. O essencial é deixar os dados importantes e as credenciais de acesso a eles. Também vale usar serviços como Nextcloud para que os dados sincronizem automaticamente com os dispositivos da família e fazer com que família e amigos realmente usem o sistema no dia a dia. Aqui em casa, por exemplo, tento fazer do Home Assistant algo quase tão essencial quanto um eletrodoméstico, a ponto de minha parceira também usar. Isso é mais fácil de manter quando existe como dispositivo físico, e não como uma VM isolada. Claro que há bastante esperança envolvida nisso tudo, então o ideal é mesmo montar um plano detalhado com os familiares próximos

    • Eu também pensei bastante nisso. Parto do princípio de que meu NAS e meus serviços em Docker não vão inicializar direitinho sem mim. Os backups externos criptografados provavelmente nem seriam recuperáveis sem ajuda profissional. Então faço snapshots incrementais diários via cron para novas pastas em um HD externo NTFS. Dá menos de 50 GB, então fica barato manter duplicado. Se eu faltar, é só plugar esse disco e copiar as pastas. Também tenho uma cópia completa da biblioteca do Seafile em notebooks individuais. O domínio de e-mail está pago por 10 anos adiantado e hospedado no iCloud. Como as fotos da família em anexo enchem a caixa e fazem e-mails quicarem, estou pensando em usar migadu

  • Também acho esse tema fascinante. Um aviso: se você entrar em trabalho autônomo ou abrir uma empresa de TI, a vontade de montar um homelab pode crescer ainda mais. Com o tempo, rodar containers simples deixa de ser suficiente, e você acaba entrando no caminho de enviar documentos, conseguir legalmente um DBA e ASN, pegar de fato seu próprio bloco de IP/IPV6 e evoluir para seu próprio ISP. Muita gente resolve o problema de ingress (acesso externo) com tailscale, mas essa parte é realmente difícil. Também acho que, em teoria, uma estrutura baseada em STUN/TURN, com cache apenas de arquivos estáticos no servidor e acesso dinâmico autenticado por magic link de e-mail numa login wall, não seria tão arriscada nem tão cara. Ao montar um ambiente de desenvolvimento remoto, isso ainda te dá mais uma desculpa para explorar tudo isso. Links de referência: https://en.wikipedia.org/wiki/Traversal_Using_Relays_around_NAT, https://en.wikipedia.org/wiki/STUN

    • Eu montei meu ingress com Fly.io, cache nginx na ponta remota e um container peer Fly Wireguard adicional no pod de ingress. Não é grátis, mas foi a opção com melhor custo-benefício para ter anycast ingress sem precisar abrir nenhuma porta em casa

  • Ando brincando com Immich e sempre fico na dúvida se devo usá-lo fora de casa só via tailscale ou se devo subir também um reverse proxy num VPS. O que mais me preocupa é encontrar uma solução de monitoramento/segurança amigável ao usuário que me avise quando alguém estiver tentando atacar o VPS

    • Estou com a mesma dúvida. Se você encontrar alguma informação sobre solução de segurança/monitoramento, compartilhe

  • Meu setup é muito mais simples

    • Uma máquina só
    • Proxy nginx
    • Vários serviços na mesma máquina; alguns só internos, outros expostos externamente, mas todos acessíveis via web
    • Serviços internos com senha longa de HTTP basic auth (gerenciador de senhas embutido do Firefox)
    • Serviços externos públicos ou com Google OAuth
    • Fiz tudo do zero, codando eu mesmo, porque esse é justamente o objetivo do homelab
    • Seja imagem ou vídeo, o navegador já dá conta de ler bem
    • A parte difícil é sempre o backend; o frontend é quase uma vibe HTML dos anos 90

    • HTTP envia a senha em texto puro, então pelo menos usar um certificado self-signed já seria mais seguro

    • Construir você mesmo a infraestrutura e os serviços em código é simplesmente uma das melhores formas de aprender. E ainda é ótimo poder atender exatamente às suas próprias necessidades

  • Tenho vontade de operar um homelab assim, mas me falta tempo. Até consigo instalar as coisas no fim de semana, mas não tenho folga para manter e atualizar tudo com consistência. Então acabo deixando nas mãos de provedores de nuvem e paro de pensar nisso. Se alguém aqui faz como eu e usa só nuvem, queria saber como aborda isso

    • No meu setup antigo, eu também sofria porque a manutenção não andava direito e isso me estressava. Foi por isso que passei a gostar de NixOS e ZFS. Nos dois, rollback é muito fácil. Você atualiza e, se der problema, volta imediatamente para a versão anterior; a depuração pode ficar para quando houver tempo. E acho totalmente válido optar pela nuvem se a experiência estiver boa para você. Setup próprio realmente consome tempo, então cada um precisa pesar custo e valor

    • Eu rodo algo como 12 serviços self-hosted e normalmente gasto menos de 1 minuto por mês com upgrades. Cada serviço tem sua pasta, com a stack do docker-compose e a pasta de dados; para atualizar basta fazer docker compose pull e depois up -d. Muito de vez em quando aparece uma atualização que exige mudança de configuração, mas na maioria das vezes termina em poucos minutos. Sem VM nenhuma. Para mim, self-hosting totalmente automatizado só com Docker Compose é o caminho mais simples

    • Isso não costuma ser algo que termina em um único fim de semana. No meu caso, começou com “vou instalar Plex para testar” e um ano depois virou uma estrutura complexa com Proxmox e todo tipo de integração com automação residencial. Meio brincando, meio falando sério: se quiser um setup mínimo, comece com docker compose, porque administrar e atualizar fica bem simples

  • Fico em dúvida se realmente precisa introduzir SSO. Se família e amigos usarem um cliente wireguard, que é bem simples até no iOS, eles conseguem entrar na rede de casa com um único toque e usar todos os serviços internos sem precisar de SSO separado. Numa rede doméstica pequena, isso tem muito mais vantagem do que desvantagem

    • Serviços que usamos, como Nextcloud e Mealie, já partem do princípio de contas por usuário. Com SSO, todo mundo consegue acessar todos os serviços com a mesma conta e eu deixo de ter que administrar senha por senha. A configuração fica um pouco mais complexa, mas a operação acaba ficando mais fácil, o que aumenta a chance de a família realmente usar

    • Eu self-hosto uns 20 apps e já estou de saco cheio de gerenciar autenticação separada para cada um, então estou implementando SSO. Quando quero expor alguns apps também para a família, centralizar a autenticação num só lugar vira a prioridade máxima. Sinceramente, não concordo com a abordagem citada acima

  • Fico curioso sobre por que usar flame especificamente. Você está trazendo dezenas ou centenas de dependências de terceiros como node, react, redux etc. para dentro do seu “reino da segurança”, quando na prática uma página HTML simples com uma lista de links já poderia cumprir o papel de página inicial

    • Eu já tinha usado flame antes, então fui nele por familiaridade e porque resolvia o problema de imediato. Também gosto do design e, como ele fica atrás de Tailscale e Authelia, não tenho grandes preocupações de segurança por causa disso. Mas penso em olhar alternativas depois

  • Tenho vontade de fazer self-hosting com NixOS, mas ainda não saí do plano. Meu ambiente hoje é gerenciado com algumas VMs e um arquivo docker compose por VM; uso um playbook ansible só para copiar os arquivos compose e mantenho o Fedora Server sempre uma versão atrás da release mais recente, atualizando quando expira. No Mac eu já uso nix-darwin, então entendo as vantagens da configuração em Nix, mas ainda não senti ganho de eficiência ou retorno de tempo suficiente para justificar portar meu ambiente inteiro para Nix. Talvez se um LLM ficasse ditando os arquivos de configuração. Por enquanto, não tenho motivação suficiente para encarar isso

    • Eu também resolvi testar NixOS e, em uma semana, migrei toda a rede de casa e até dois servidores reais. Já se passaram uns 3 ou 4 meses e estou mais satisfeito do que esperava. Migrar os servidores foi mais fácil do que migrar estações de trabalho. Recentemente até configurei um Jetson Orin Nano de brincadeira com NixOS. Na época do Gentoo eu nem cogitaria isso. A coisa mais irritante no Gentoo sempre foi o tempo absurdo de compilação em hardware antigo; por exemplo, compilar GHC num XPS de 2019 levava 6 horas

    • Para mim, a grande diferença do NixOS é como o rollback fica fácil quando algo dá errado. Com ansible ou compose também dá para fazer backup e recuperação, mas existe o peso de ter que escrever você mesmo esse sistema. Ainda assim, se você já está satisfeito com o que tem hoje, então isso já é ótimo

    • Se você já usa IaC até certo ponto, eu também não senti que o ganho extra trazido pelo NixOS fosse tão grande assim