O teu homelab não precisa de quinze serviços: precisa de seis, pela ordem certa, e de um backup que já tenhas restaurado

Higgs

Olá a todos!

Prefácio habitual: este post tinha outra cara. Havia um rascunho na gaveta com quinze categorias de serviços “essenciais”, cada uma com dois ou três nomes, e quando o reli esta semana percebi que tinha envelhecido mal. Recomendava TeamViewer para aceder ao homelab, dizia que o Fail2ban protege contra DDoS, confundia o Emby com o Jellyfin e ensinava a instalar coisas com o apt-key. Deitei-o fora e comecei do zero. O que se segue é opinião, formada a partir do que corre em minha casa e do que vejo partir na casa dos outros. Vale o que vale.

Com o verão a despedir-se, é normal chegar aquela vontade de pegar no mini PC que está em cima do móvel da televisão e fazer finalmente as coisas bem. Conheço o padrão porque já o repeti várias vezes: abre-se o r/selfhosted, abre-se a lista awesome-selfhosted no GitHub, e duas horas depois há dezassete separadores abertos e uma lista de quarenta serviços que parecem todos indispensáveis.

Não são.

A pergunta “quais são os serviços self-hosted essenciais” tem uma resposta mais aborrecida do que se espera, e é precisamente por ser aborrecida que quase ninguém a dá. Os serviços essenciais são os que impedem que o homelab se transforme num problema: o backup, o DNS, a forma como se chega lá de fora, quem pode entrar, e quem avisa quando alguma coisa morre. Raramente são os que tornam o homelab interessante. Tudo o resto, do Jellyfin ao Home Assistant, assenta em cima dessa base. É a parte divertida, e é a parte que só deve vir depois.

Como o Khan Noonien Singh diria pela voz do Benedict Cumberbatch dira, shall we begin?

O teste do algodão que uso para decidir o que é essencial

Antes de nomes, um critério. Um serviço é essencial no homelab se passar pelo menos numa de duas perguntas.

A primeira: no dia em que isto parar, quem é que dá por isso? Se a resposta for “a casa inteira, em menos de cinco minutos”, o serviço é infraestrutura e tem de ser tratado como tal. O DNS é o exemplo clássico. Quando o Adguard cai, ninguém em casa sabe o que é um Adguard; sabem apenas que “a internet não dá”, e o telemóvel que toca é o teu.

A segunda: este serviço protege os outros? O backup não faz nada de visível até ao dia em que é a única coisa que interessa. A monitorização é igual. O SSO também, de certa forma, porque reduz o número de sítios onde uma palavra-passe fraca pode abrir a porta.

O Jellyfin não passa em nenhuma das duas. Se parar numa terça-feira à noite, a pior consequência é ver a série no dia seguinte. Continua a ser útil, só que é opcional, e era essa a distinção que o rascunho antigo não fazia: punha o servidor de streaming ao mesmo nível do backup, numa lista numerada de um a quinze, como se tudo pesasse o mesmo.

O critério tem ainda uma consequência prática. Os serviços essenciais devem ser os mais simples, os mais testados e os menos mexidos do homelab inteiro. Não é neles que se experimenta a versão beta de coisa nenhuma.

A base: onde tudo vai correr

Não é um serviço, mas convém decidir primeiro, porque condiciona o resto.

Para a maior parte das pessoas, a resposta em 2026 continua a ser o Proxmox VE. A versão atual é a 9.2, saída em maio, assente no Debian 13 Trixie e com o kernel 7.0 por omissão. Em agosto saiu também a primeira versão oficial para ARM de 64 bits, e antes que alguém se entusiasme: as notas de lançamento dizem explicitamente que placas como o Raspberry Pi não são suportadas, porque o arranque tem de ser feito por UEFI e o hardware descrito por ACPI. O Proxmox em ARM é para servidores NVIDIA Grace, não para a gaveta das placas esquecidas.

A novidade que mais me interessou para um homelab chegou na 9.1: a possibilidade de criar contentores LXC diretamente a partir de imagens OCI, as mesmas que se usam no Docker. Ainda está a amadurecer, e a parte dos contentores de aplicação continua marcada como pré-visualização técnica, mas aponta numa direção clara. O roadmap do projeto fala mesmo em suporte declarativo baseado na especificação Compose, para gerir grupos de contentores como uma única aplicação. Durante anos, a pergunta “LXC ou uma VM com Docker lá dentro? – cof cof quem nunca?” foi das mais discutidas nos fóruns. Pode estar a caminho de deixar de fazer sentido.

Quanto ao armazenamento, o rascunho antigo falava em “TrueNAS Core/Scale”. O Core morreu. A 13.3-U1.2 foi a última versão desse ramo, a documentação está arquivada, e a própria TrueNAS aponta a Community Edition 25.10 (a antiga SCALE, baseada em Debian) como caminho de migração. Quem ainda tem um Core a correr não precisa de entrar em pânico amanhã, mas precisa de ter um plano, porque não vai receber mais nada.

A minha opinião, que já rendeu mais do que uma discussão ao cafe: se tens uma máquina só, põe o Proxmox no metal e o armazenamento em ZFS gerido pelo próprio Proxmox. Se tens discos de tamanhos diferentes e queres acrescentar um de cada vez sem pensar em vdevs, o Unraid continua a ser a opção mais confortável, com a ressalva de que é pago. O TrueNAS brilha quando é um NAS dedicado, numa máquina que faz só isso. Pôr um TrueNAS numa VM dentro do Proxmox, com passthrough da controladora, funciona, mas é mais uma camada que tens de perceber quando algo corre mal às duas da manhã. Ou se fores como eu, usa hosts dedicados para storage, LVM com bcache e iscsi para distribuir pelos hosts de compute.

Uma nota sobre hardware, porque em Portugal a fatura da luz entra na conta. Um servidor de rack comprado em segunda mão parece uma pechincha até se perceber que vai passar o ano inteiro ligado. Para a maior parte dos homelabs domésticos, um mini PC moderno com um processador de baixo consumo faz tudo o que é preciso, incluindo transcodificação de vídeo por hardware, e gasta uma fração da energia. O servidor de rack é ótimo para aprender. É péssimo para pagar.

Serviço 1: backup, e sobretudo a possibilidade de restauro

Começo pelo que acham que só deve montar ao fim.

A regra 3-2-1 continua válida: três cópias dos dados, em dois suportes diferentes, uma delas fora de casa. Parece burocracia até ao dia em que um disco morre durante o resilver, ou um contentor com permissões a mais apaga a pasta errada, ou um ransomware encontra a partilha SMB montada com permissão de escrita.

Há duas confusões que vejo com frequência. A primeira é tratar snapshots de ZFS como backups. Vivem no mesmo pool e morrem com o mesmo pool; são excelentes para desfazer um erro de há vinte minutos e inúteis quando a controladora decide escrever lixo. A segunda é o RAID, que trata de disponibilidade, que é outra coisa: protege-te de um disco a morrer, não te protege de ti.

Para máquinas virtuais e contentores, o Proxmox Backup Server é a escolha natural. Deduplica ao nível do bloco, o que significa que trinta dias de backups de uma VM de 50 GB ocupam muito menos do que trinta vezes 50 GB, verifica periodicamente a integridade do que guardou, e permite recuperar ficheiros individuais sem restaurar a VM inteira. Idealmente corre numa máquina diferente da que está a proteger. Um PBS numa VM do mesmo Proxmox de que faz backup é melhor do que nada, mas só um bocadinho.

Para ficheiros, fotografias, documentos e as configurações dos teus serviços, o restic e o BorgBackup são as duas ferramentas que recomendo sem hesitar. Ambos cifram do lado do cliente, ambos deduplicam, e ambos enviam para destinos remotos (o restic fala diretamente com armazenamento compatível com S3, o que dá jeito para a cópia fora de casa). O Bareos, que o rascunho antigo sugeria, é excelente numa empresa com uma biblioteca de VLS. Em casa é um canhão para matar uma mosca. Mas para quem quer aprender como funcionam ambientes verdadeiramente corporativos, é uma escolha a considerar.

A cópia externa pode ir para um fornecedor de armazenamento de objetos, para um disco em casa de um familiar, ou para o homelab de um amigo: troca-se espaço, e cada um guarda os backups cifrados do outro. Esta última é a minha preferida, e custa zero euros por mês.

Agora a parte significativa. Um backup que nunca foi restaurado é uma esperança com nome técnico. Marca no calendário, uma vez por trimestre, uma hora para escolheres uma VM ao acaso e a restaurares com um ID novo, desligada da rede. Escolhe também um ficheiro qualquer do repositório do restic ou do Borg e confirma que abre. Mesma coisa um Bareos backup. Da primeira vez vais descobrir alguma coisa: uma palavra-passe de cifra que não está onde julgavas, um volume que ficou de fora, uma base de dados copiada a meio de uma escrita. É muito melhor descobri-lo numa tarde de sábado do que no dia em que precisas.

E a palavra-passe da cifra dos backups não pode viver apenas dentro do homelab que os backups protegem. Parece óbvio. A julgar pelo número de pessoas que conheço que a guardaram no gestor de palavras-passe que corria no servidor que morreu, não é.

Serviço 2: DNS. It’s almost always the DNS.

O DNS local faz duas coisas. Resolve nomes internos, para escreveres jellyfin.casa.exemplo.pt em vez de um endereço IP com uma porta pendurada, e filtra publicidade e rastreadores para toda a rede, incluindo a smart TV onde não se consegue instalar bloqueador nenhum.

O Pi-hole continua a ser a escolha mais popular, e a versão 6, lançada em fevereiro de 2025, mudou bastante por dentro: o servidor web e uma API REST passaram a estar embutidos no próprio binário pihole-FTL, e deixou de ser preciso o lighttpd e o PHP. Na prática, a instalação ficou mais leve e pô-lo atrás de um reverse proxy deixou de ser um exercício de paciência. Um aviso a quem ainda está na v5: a atualização é só num sentido, por isso guarda a configuração antes de avançar.

O AdGuard Home é a alternativa séria. Tem DNS sobre HTTPS e sobre TLS nativos, uma interface que muita gente acha mais clara, e é um único binário. Honestamente, a diferença entre os dois é menor do que as discussões na internet sugerem. Escolhe um e segue em frente.

O BIND, que também estava no rascunho, é o que eu usaria para gerir DNS autoritativo numa organização. Numa casa, é complexidade sem retorno.

A escolha entre Pi-hole e AdGuard importa pouco. O número de instâncias importa muito. Um só servidor de DNS é um ponto único de falha para a casa inteira, e vai falhar precisamente no dia em que estás fora e alguém em casa precisa de entregar um trabalho. A solução é ter dois, em máquinas físicas diferentes (um no servidor principal, outro num Raspberry Pi antigo, por exemplo), e anunciar os dois por DHCP. Para manter listas e entradas locais sincronizadas entre ambos há ferramentas próprias, como o nebula-sync para o Pi-hole v6 ou o adguardhome-sync para o AdGuard.

Um último conselho de nomenclatura, porque vejo muita gente a sofrer com isto: não uses .local para os teus nomes internos. Esse sufixo está reservado para mDNS e vai dar conflitos estranhos com dispositivos Apple e impressoras. As opções corretas são home.arpa, que foi reservado precisamente para redes domésticas, ou um subdomínio de um domínio teu. Esta segunda opção tem uma vantagem enorme, que fica clara já a seguir.

Serviço 3: reverse proxy e certificados

Com vários serviços a correr, deixas de querer decorar portas. Um reverse proxy recebe todos os pedidos numa só porta (a 443), olha para o nome pedido e encaminha para o serviço certo. É também ele que trata dos certificados TLS.

As três opções mais comuns são o Caddy, o Traefik e o Nginx Proxy Manager. O Caddy é o que recomendo a quem está a começar: o ficheiro de configuração é curto e legível, e os certificados são automáticos por omissão. O Traefik faz mais sentido quando tens muitos contentores Docker e queres que a configuração venha das labels de cada um. O Nginx Proxy Manager tem interface gráfica e é muito popular, mas quando alguma coisa corre mal estás a depurar uma camada por cima do Nginx, e o problema costuma estar escondido exatamente nessa camada.
Menção honrosa para quem como eu ainda usa o apache como reverse proxy e mod_waf para garantir a segurança.

É por isto que vale a pena ter um domínio próprio. Com um domínio verdadeiro, que custa entre dez e vinte euros por ano, e o desafio DNS-01 do protocolo ACME, consegues certificados válidos da Let’s Encrypt para serviços que nunca estão expostos à internet. O proxy prova que controla o domínio criando um registo TXT temporário através da API do teu fornecedor de DNS, e não precisa de abrir porta nenhuma. Resultado: acaba o aviso de certificado inválido em todos os browsers da casa, e acaba o hábito perigoso de carregar em “avançar mesmo assim”, que é exatamente o hábito que um atacante adora encontrar.

Há uma mudança em curso que convém conhecer. A Let’s Encrypt anunciou em dezembro passado que vai encurtar a validade dos certificados por fases. Desde maio de 2026 existe um perfil opcional com certificados de 45 dias; em fevereiro de 2027 o perfil por omissão passa para 64 dias; e em fevereiro de 2028 chega aos 45 dias, com o período de reutilização da validação do domínio a cair para apenas sete horas. Se a tua renovação é automática e o cliente ACME está atualizado, não precisas de fazer nada. Se tens algures um cron que renova “a cada 60 dias”, esse cron vai deixar certificados expirar.

Um pormenor que apanhou muita gente desprevenida: a Let’s Encrypt deixou de enviar emails de aviso de expiração em junho de 2025. Se contavas com esse email como rede de segurança, ela já não existe. A monitorização da validade dos certificados passou a ser tua, e isso é mais um bom motivo para o serviço 6.

Serviço 4: acesso remoto sem abrir portas

Esta é a secção onde o rascunho antigo estava mais errado. Sugeria TeamViewer e AnyDesk para chegar ao homelab. São ferramentas de suporte remoto a ambientes de trabalho, pensadas para ajudar a tia a instalar a impressora. Pô-las num servidor significa ter um serviço proprietário, com conta na nuvem de um terceiro, a dar controlo gráfico total da máquina. É o oposto do que se procura num homelab.

A segunda tentação é o port forwarding: abrir a porta 443 no router e expor o reverse proxy à internet. Pode ser feito com cuidado, mas cada serviço exposto passa a receber varrimentos automáticos minutos depois de ficar acessível, e basta uma aplicação com uma falha de autenticação para a porta da frente ficar aberta. Para a esmagadora maioria dos casos, a resposta certa é uma VPN.

O WireGuard é a base de quase tudo o que presta nesta área. Está no kernel Linux, é rápido, a configuração cabe num ecrã, e num router que o suporte (OPNsense, OpenWrt e afins) monta-se numa tarde. Tem uma limitação: precisa que o teu router seja alcançável a partir de fora. E em Portugal isso é cada vez menos garantido, porque há tarifários que colocam o cliente atrás de CG-NAT, sem endereço IPv4 público próprio. Se é o teu caso, o WireGuard clássico não te serve sem ajuda.

Foi por isso que o Tailscale conquistou tanta gente. Usa WireGuard por baixo, atravessa NAT e CG-NAT sem configurar nada no router, e liga os teus dispositivos numa rede privada em minutos. O senão é que o servidor de coordenação, o componente que troca as chaves e decide quem fala com quem, pertence à Tailscale e vive na nuvem deles. O tráfego em si não passa por lá quando a ligação direta é possível, mas o controlo da rede está fora de casa. Atenção a isto caso sejam neuróticos como eu com temas de segurança.

Quem quer esse controlo tem o Headscale, uma implementação open source do servidor de coordenação, compatível com os clientes oficiais. O projeto assume um âmbito limitado: uma única rede privada, pensada para uso pessoal ou para uma organização pequena. Para um homelab, é exatamente o que faz falta. Tem uma particularidade curiosa: um dos mantenedores ativos trabalha na Tailscale e tem autorização para contribuir em horário de trabalho. Há quem veja nisto um conflito de interesses. Eu vejo um sinal de que a empresa não tem pressa nenhuma em matar o projeto.

A contrapartida do Headscale é que ele próprio precisa de estar alcançável, o que normalmente quer dizer um VPS pequeno, fora de casa. Parece contraditório, e em parte é. Mas um VPS de poucos euros que só coordena chaves representa um risco muito menor do que um router com portas abertas para meia dúzia de aplicações web.

Serviço 5: identidade, ou quantas palavras-passe tens no homelab

Conta os serviços com interface web que tens a correr. Agora conta quantas contas de administrador diferentes isso representa, e quantas partilham a mesma palavra-passe. Se a resposta te deixou desconfortável, este serviço é para ti.

Um fornecedor de identidade centralizado permite que entres uma vez e sejas reconhecido em todos os serviços que suportam OIDC ou SAML, com autenticação de dois fatores num único sítio. Quando um familiar deixa de precisar de acesso, desativas uma conta em vez de doze.

As opções mais usadas em homelabs são três, com perfis bem diferentes. O Authelia é leve e funciona muito bem acoplado ao reverse proxy, protegendo até serviços que não têm autenticação própria. O Authentik é bastante mais completo, com fluxos configuráveis, suporte a LDAP e SAML e uma interface de administração rica, mas pede mais recursos e mais tempo para se perceber. O Pocket ID é o mais recente e o mais minimalista: um fornecedor OIDC que funciona apenas com passkeys, sem palavras-passe de todo. Para quem já usa passkeys no telemóvel, é surpreendentemente agradável.

O próprio Proxmox suporta login por OpenID Connect, e o mesmo acontece com o Immich, o Grafana, o Forgejo e o Jellyfin (este último através de um plugin). Nem tudo suporta, e para esses casos o Authelia à frente do proxy resolve o problema.

O rascunho antigo sugeria LDAP e FreeIPA. O FreeIPA é uma ferramenta excelente, e se o objetivo do teu homelab é aprender gestão de identidade empresarial, com Kerberos e tudo, monta-o. Se o objetivo é ter a casa organizada, é demasiado.

Uma palavra sobre o gestor de palavras-passe, porque é o serviço que mais gente quer alojar em casa. O Vaultwarden, uma implementação alternativa e leve do servidor do Bitwarden, compatível com as aplicações oficiais, funciona muito bem. Mas pensa no cenário em que o homelab está em baixo e estás fora de casa a precisar de uma palavra-passe. As aplicações guardam uma cópia local cifrada, o que ajuda, mas não substitui ter uma exportação cifrada guardada fora do homelab. E lembra-te do que ficou dito na secção do backup sobre a chave de cifra.

Serviço 6: monitorização que te acorda (pouco)

O rascunho antigo tinha duas categorias separadas para isto, com Prometheus, Grafana, Zabbix, Nagios e Netdata. Cinco ferramentas para uma casa.

A monitorização de um homelab tem de responder a três perguntas. Está tudo a responder? Algum disco está a morrer? Alguma coisa vai acabar em breve, seja espaço em disco ou a validade de um certificado? E a resposta tem de chegar ao teu telemóvel, porque um painel bonito que ninguém abre não monitoriza nada.

Para a primeira pergunta, o Uptime Kuma é difícil de bater. A versão 2.0 saiu em outubro de 2025, depois de uma espera longa, trouxe suporte a MariaDB para quem tem centenas de verificações e passou a permitir correr o contentor sem privilégios de root. Verifica HTTP, portas, DNS e pings, avisa quando um certificado está perto de expirar, e envia alertas para Telegram, ntfy, email, Discord e dezenas de outros destinos. Um compose mínimo é isto:

services:
  uptime-kuma:
    image: louislam/uptime-kuma:2
    container_name: uptime-kuma
    restart: unless-stopped
    volumes:
      - ./data:/app/data
    ports:
      - "3001:3001"

Um conselho: não o corras na mesma máquina que está a vigiar. Se o servidor morrer, o Uptime Kuma morre com ele e não avisa ninguém. Um Raspberry Pi, a máquina do segundo servidor de DNS ou um VPS pequeno são sítios bem melhores.

Para a segunda pergunta, ativa os alertas de SMART. O Proxmox e o TrueNAS enviam notificações por email ou webhook quando um disco começa a acumular setores realocados. Configura-as hoje. Um disco raramente morre sem avisar, só que avisa num sítio onde ninguém está a olhar.

O Prometheus com o Grafana fica para quando quiseres aprender observabilidade a sério, ou quando tiveres métricas próprias que valha a pena guardar ao longo do tempo. É uma combinação muito usada profissionalmente, o que faz dela uma boa escola. Para quem quer algo intermédio, o Beszel é um agente leve que mostra CPU, memória, disco e contentores de várias máquinas num único painel, com alertas, sem a curva de aprendizagem do PromQL.

O Nagios, esse, deixo-o descansar. Serviu muito bem durante muitos anos. Hoje há formas menos dolorosas de fazer o mesmo.

A prática que agrega tudo: configuração como código

Também não é um serviço, mas é o que decide se o teu homelab é recuperável ou um castelo de cartas. E acredita que se trabalhares ou quereres trabalhar com infra profissionalmente isto é algo que faz verdadeira falta ter prática.

Cada docker-compose.yml, cada Caddyfile, cada ficheiro de configuração que editaste à mão deve estar num repositório Git. Pode ser um Forgejo ou um Gitea alojado em casa (o Forgejo nasceu como fork comunitário do Gitea e é hoje a minha sugestão por omissão), ou um repositório privado num serviço externo, desde que não leve segredos em texto simples lá dentro. O GitLab, que o rascunho antigo sugeria, é pesado demais para esta função num homelab: pede vários gigabytes de RAM só para existir.

Para a gestão de configuração propriamente dita, o Ansible ganha em casa por uma razão simples: não precisa de agente. Liga-se por SSH, aplica o playbook e sai. O Puppet e o Chef foram desenhados para frotas de centenas de servidores com um servidor central, e fazem muito bem esse trabalho. Num homelab, a infraestrutura de gestão acabaria maior do que aquilo que gere.

Isto liga-se diretamente ao que escrevi há umas semanas sobre o CERN e a migração de parte dos sistemas de controlo para Debian. A lição mais valiosa desse caso foi a capacidade de mudar de distribuição sem que isso fosse uma emergência; a distribuição escolhida era quase secundária. À escala de uma casa, o princípio mantém-se. Se o teu servidor morrer amanhã, quanto tempo demoras a pôr tudo a correr noutra máquina? Com configuração em Git, backups testados e meia dúzia de playbooks, a resposta é uma tarde. Sem isso, é um fim de semana inteiro a tentar lembrar-te do que fizeste há dois anos.

Agora sim, the fun bit!

Com a base montada, tudo o que vem a seguir é gosto pessoal. Ainda assim, algumas decisões mudaram bastante desde que o rascunho antigo foi escrito.

Media. O rascunho recomendava o Emby e depois instalava o Jellyfin, chamando-lhe Emby. Para esclarecer de vez: o Jellyfin nasceu em 2018 como fork do Emby, quando este fechou o código, e hoje são projetos diferentes. A escolha entre o Jellyfin e o Plex também mudou muito no último ano e meio. Desde 29 de abril de 2025 que o Plex exige subscrição para veres remotamente a tua própria biblioteca: ou o dono do servidor tem Plex Pass, ou cada pessoa que vê de fora paga um passe específico para isso. A aplicação da regra foi chegando aos vários dispositivos ao longo de 2025 e 2026, e em julho deste ano o Plex Pass vitalício passou de 249,99 para 749,99 dólares. O Plex continua a ser o mais polido e o mais fácil para familiares pouco técnicos. O Jellyfin é gratuito em tudo, incluindo a transcodificação por hardware, e combinado com a VPN do serviço 4 resolve o acesso remoto sem pagar nada. Para um homelab novo, eu começava pelo Jellyfin.

Fotografias. O Immich tornou-se a referência para quem quer sair do Google Fotos ou do iCloud. Faz cópia automática a partir do telemóvel, reconhecimento facial e pesquisa por conteúdo, tudo localmente, e a versão 2.0, a primeira que o projeto considera estável, saiu em outubro de 2025. Aviso importante: o Immich não é o backup das tuas fotografias, é apenas mais um sítio onde elas estão. As fotografias entram no plano do serviço 1 como tudo o resto, e se calhar com mais prioridade do que tudo o resto, porque são das poucas coisas num homelab que não se voltam a descarregar de lado nenhum.

Domótica. O Home Assistant continua sem concorrência séria para a maioria das pessoas. O openHAB tem os seus fiéis e é perfeitamente capaz, mas a dimensão da comunidade do Home Assistant, e o número de integrações que daí resulta, pesa muito. Recomendação prática: corre-o como VM com o sistema operativo próprio do Home Assistant, em vez de o espremer num contentor simples, porque assim ficas com a gestão de extensões e os backups integrados. E se tens dispositivos Zigbee, um adaptador USB passado para a VM, com o Zigbee2MQTT ou o ZHA, liberta-te das bridges de cada fabricante.

Documentos. O Paperless-ngx transforma a pilha de papel (faturas da luz, declarações de IRS, garantias de eletrodomésticos) num arquivo pesquisável com OCR. É daqueles serviços que parecem desnecessários até ao dia em que precisas da fatura do frigorífico para acionar a garantia e ela está numa caixa de sapatos algures na arrecadação.

Quem leu o post sobre o Sandstorm no início do mês sabe que há outras formas de pensar o empacotamento e o isolamento destas aplicações. Seja qual for a forma, a ordem não muda: primeiro a base, depois isto.

O que tirei da lista, e porquê

Para ser justo com o rascunho antigo, nem tudo o que lá estava era mau. Algumas coisas estavam apenas no sítio errado.

O TeamViewer e o AnyDesk saíram pelas razões já explicadas: ferramentas de suporte a ambientes de trabalho, com conta num terceiro, a controlar servidores.

O Fail2ban continua útil para bloquear tentativas repetidas de login por força bruta, sobretudo com SSH exposto. E se seguiste o conselho da VPN, o teu SSH nem sequer está exposto.

O Snort é interessante para aprender deteção de intrusões, mas numa rede doméstica gera sobretudo ruído, e ruído que ninguém lê é pior do que silêncio, porque dá uma falsa sensação de proteção. Se usas OPNsense como firewall, o Suricata está integrado e é um bom ponto de partida para quando o tema te interessar.

O Supervisor, como gestor de processos, perdeu a razão de ser na maior parte dos casos. Em Linux, o systemd faz esse trabalho, e dentro de contentores quem gere o ciclo de vida é o próprio Docker ou Podman.

O FRRouting é software sério, e o próprio Proxmox usa-o por baixo nas funcionalidades de rede definida por software. Mas encaminhamento dinâmico em casa só faz sentido se o objetivo for estudar para uma certificação de redes. Nesse caso, força.

Na altura falei da possibilidade de instalação no Raspberry Pi tinha pelo menos três problemas: a imagem era de 2021, o utilizador “pi” com a palavra-passe “raspberry” deixou de existir por omissão em abril de 2022, e o apt-key usado para adicionar repositórios está obsoleto há anos e já nem existe nas versões recentes do Debian. Um guia de instalação envelhece mais depressa do que qualquer outra coisa num blog, e é por isso que este post quase não tem comandos.

A ordem, para quem quer começar este fim de semana

Se estás a começar do zero, ou a recomeçar, esta é a ordem que eu seguiria. A razão é simples: cada passo depende do anterior.

  1. Instalar o Proxmox (ou a base que escolheste) e pôr o armazenamento a funcionar com ZFS ou equivalente.
  2. Montar o backup antes de qualquer serviço que te importe: Proxmox Backup Server para VMs e contentores, restic ou Borg para ficheiros, e uma cópia fora de casa. Fazer o primeiro restauro de teste logo no primeiro dia, quando ainda não há nada a perder.
  3. Dois servidores de DNS em máquinas diferentes, com um domínio próprio ou home.arpa para os nomes internos.
  4. Reverse proxy com certificados obtidos por DNS-01.
  5. Acesso remoto por WireGuard, Tailscale ou Headscale, sem portas abertas no router.
  6. Fornecedor de identidade, ligado aos serviços à medida que os fores acrescentando.
  7. Uptime Kuma fora do servidor principal, com alertas para o telemóvel, e SMART configurado.
  8. Tudo o que fizeste até aqui, num repositório Git.
  9. Só agora: Jellyfin, Immich, Home Assistant, Paperless, e o que mais te apetecer.

Parece muito. Na prática, os passos 3 a 7 cabem num fim de semana para quem já tem alguma prática, e em dois para quem não tem. O passo 9 nunca acaba, e ainda bem.

Deixo o critério do início aplicado ao contrário. Quando fores tentado a acrescentar mais um serviço ao homelab (e vais ser, porque é esse o prazer da coisa), faz-lhe as mesmas duas perguntas. Se ele não é crítico para ninguém e não protege nada, instala-o à vontade, desde que fique coberto pelo backup, atrás do proxy, atrás da VPN e com o login no SSO. Se não consegues garantir isso, ainda não é altura.

O homelab que dura é aquele em que o dono dorme descansado quando um disco decide morrer numa quinta-feira à noite.

Até ao próximo post!
Nuno

Documentação:

Base e armazenamento

Backup

DNS

Reverse proxy e certificados

Acesso remoto

Identidade e palavras-passe

Monitorização

Configuração como código

Serviços de uso pessoal

Nota: Este post foi feito com o auxílio de um LLM privado.

Related Posts