Durante muito tempo quis ter meu próprio servidor, mas tinha receio dos custos e da complexidade. Então descobri o Proxmox VE — e, olhando para trás, me pergunto por que não fiz isso antes. O Proxmox é uma plataforma de virtualização gratuita e de código aberto baseada em Debian: KVM para VMs completas, LXC para contêineres leves e uma interface web que realmente facilita o dia a dia.
O melhor é que você não precisa de um servidor caro. Comecei com um mini PC usado (um Dell OptiPlex Micro) com RAM ampliada e um SSD NVMe — silencioso, econômico e mais do que suficiente para 10–15 contêineres e algumas VMs. Com os preços da energia por aqui, um mini PC que consome 10–15 watts em idle faz uma diferença enorme em relação a um servidor de rack.
Depois da instalação, a primeira coisa que fiz foi desativar o repositório Enterprise e configurar os repositórios da comunidade, proteger o login SSH com chave e instalar o Fail2ban. Depois vieram os primeiros serviços: Pi-hole como bloqueador de anúncios para toda a rede, Nginx Proxy Manager e Portainer. Essa ordem se mostrou eficaz — comece pequeno, não com vinte contêineres de uma vez.
Meu conselho mais importante, que eu mesmo só aprendi do jeito difícil: configure os backups antes de instalar o primeiro serviço. Seguindo a regra 3-2-1 — e os backups por snapshot integrados do Proxmox tornam isso quase fácil demais. Aliás, RAID não é backup — isso eu também demorei a entender.
Simplesmente comece. Um contêiner, um serviço, e você aprende mais sobre infraestrutura do que em qualquer curso online. E quem quiser apenas experimentar primeiro também pode usar um servidor na nuvem barato para aprender.
Fonte: Homelab Guide
De acordo com o IT之家, o NAS de quatro baias Qu405-N150-8G da QNAP já está à venda no JD.com. Ele vem com 8 GB de memória e garantia padrão de 2 anos. O equipamento sozinho custa 2599 yuans, e o combo com um disco rígido Seagate IronWolf de 4 TB custa 3599 yuans.
O design é simples. O gabinete mede 165 mm x 168 mm x 217 mm e pesa 2,15 kg. O processador é um Intel N150 de 4 núcleos e 4 threads. A fabricante diz que ele dá conta de transcodificar vídeo em 4K e de rodar máquinas virtuais e contêineres Docker, o que é um grande atrativo para quem gosta de mexer em servidores domésticos. A memória SODIMM DDR4 de 8 GB que vem de fábrica pode ser atualizada para 16 GB.
O armazenamento tem quatro baias para discos SATA de 3,5 ou 2,5 polegadas. Por dentro, há ainda duas entradas M.2 2280 NVMe PCIe Gen 3 x1, que podem servir como cache ou para guardar o sistema e os dados dos contêineres. As conexões incluem duas portas de rede 2.5GbE, duas USB-A 3.2 Gen 2, uma USB-C 3.2 Gen 2 e uma HDMI 2.1.
Na minha opinião, a combinação de 2.5G duplo com um N150 já virou uma configuração comum em NAS domésticos de entrada nos últimos dois anos. Ele roda Docker sem consumir muita energia, e o preço é bastante razoável. Só que o artigo traz apenas especificações, sem testes reais. Então, se você pensa em comprar, vale checar antes o ruído, o consumo de energia e a experiência com o software em avaliações de usuários.
Fonte: IT之家
A Synology anunciou para a Alemanha a nova linha neo+, composta pelo DS725neo+, DS925neo+, DS1525neo+ e DS1825neo+. A ComputerBase os descreve como versões mais baratas dos modelos Plus, nas quais só a configuração de memória foi alterada.
Segundo a reportagem, o "neo" significa "opção Non-ECC". Esses aparelhos usam memória comum, sem função ECC, e sempre com apenas 4 GB. Os DS725+ e DS925+ têm 4 GB de memória ECC, enquanto os DS1525+ e DS1825+ têm 8 GB de memória ECC; por isso as versões neo+ têm menos memória. No resto, equipamento, recursos e possibilidade de expansão são iguais aos dos modelos Plus, e o DSM com seus aplicativos também é idêntico.
No preço de venda sugerido pelo fabricante, a diferença fica em torno de 200 euros: o DS725neo+ aparece por 549 euros líquidos e o DS725+ por 748 euros líquidos. No varejo, porém, a distância não é tão grande: o DS725+ está atualmente a partir de 663 euros, e o DS725neo+ a partir de 629 euros. A memória pode depois ser facilmente atualizada para ECC.
A Synology cita como motivo a situação atual do mercado de memória, ou seja, os fortes aumentos de preço que também atingiram os modelos Plus.
Para o universo dos servidores domésticos, acho essa uma escolha interessante. Quem usa o NAS sobretudo para backups, mídia e alguns contêineres provavelmente se dará bem com 4 GB sem ECC. Quem valoriza a integridade dos dados deve analisar com atenção o que recebe pela diferença de preço.
Fonte: ComputerBase
O Hardware.com.br mostrou um homelab que chama atenção pelo tamanho reduzido. Um usuário do Reddit publicou no r/HomeServer um pequeno rack de 10 polegadas com firewall, três mini PCs, NAS e toda a infraestrutura de rede necessária para manter dezenas de serviços funcionando em casa.
A parte de processamento são três mini PCs, cada um com processador de 8 núcleos e 16 threads e 32 GB de RAM, somando 24 núcleos, 48 threads e 96 GB para virtualização. Ele usa Proxmox para criar máquinas virtuais e containers LXC. Entre as cargas há uma VM para o Jellyfin, o chamado arr stack rodando em Docker e outro host Docker com Portainer, Pi-hole e dashboards como Homer e Homepage, além de servidores de jogos como Terraria e Core Keeper.
O armazenamento fica em um HP ProLiant MicroServer com quatro HDs de 4 TB em RAIDZ1 do ZFS, que permite continuar acessando os dados mesmo se um disco falhar. São 16 TB brutos, com espaço útil menor por causa da paridade. A rede é controlada por um Fortinet FortiGate, que cuida de roteamento, VLANs e VPN SSL, e um no-break APC Back-UPS 850 protege contra quedas de energia.
A parte mais interessante, na minha opinião, está fora de casa: o dono mantém dois VPS com Debian em datacenters externos, ligados ao homelab por uma rede WireGuard em configuração hub-and-spoke. Eles funcionam como a camada pública da infraestrutura, com o Traefik atuando como proxy reverso.
É um bom exemplo de que um homelab não precisa de um rack gigante: com planejamento, caixas pequenas e boa organização, dá para rodar muita coisa em pouco espaço.
Fonte: Hardware.com.br
Quando um mesmo servidor roda mais de um projeto, cedo ou tarde esbarra-se nas portas 80 e 443, que só um processo pode escutar. Um artigo do Habr, publicado no blog da Selectel, mostra passo a passo como resolver isso com o Nginx Proxy Manager.
O autor começa explicando o problema: portas privilegiadas, a regra de um ouvinte por porta, problemas de CORS quando frontend e backend ficam em portas separadas e a falta de HTTPS. Um proxy reverso resolve isso como intermediário, roteando o tráfego por domínio e caminho. Outra vantagem é que o firewall só precisa das portas 22, 80 e 443 abertas.
O ambiente de teste é um VDS com 2 vCPUs, 2 GB de RAM e 40 GB NVMe, com Ubuntu 24.04 e Docker do repositório oficial. A rede é criada com docker network create proxy e o contêiner jc21/nginx-proxy-manager é iniciado com volumes para dados e certificados. Gostei de que o painel administrativo, na porta 81, fique vinculado apenas a 127.0.0.1 e seja acessado por túnel SSH.
Em seguida, configura-se um host de proxy: o Forward Hostname recebe o nome do contêiner e o certificado SSL é associado na aba SSL. Para os testes usa-se o traefik/whoami. O caso em que a aplicação roda diretamente no host também é tratado: o endereço do gateway da rede Docker é obtido com docker network inspect, e o firewall é ajustado para que a aplicação não seja acessada contornando o proxy.
Há também ressalvas. Os exemplos misturam domínios diferentes e a imagem usa a tag latest, o que pode prejudicar a reprodutibilidade com o tempo. Mesmo assim, é um bom ponto de partida para quem quer rodar vários serviços em casa ou em um VDS sem editar configurações do nginx à mão.
Fonte: Habr (blog Selectel)
O Self-Host Weekly desta semana, do selfh.st, reúne notícias que quem tem homelab vai querer conhecer. Gosto desse tipo de resumo porque economiza bastante tempo lendo feeds.
A história principal é confusa: um novo pacote de alternativas de código aberto ao Adobe foi acusado de copiar projetos existentes, principalmente o popular Photopea, cujo desenvolvedor foi um dos primeiros a dar o alarme. Os dois projetos no centro da história, PhotoSuite e PhotoCraft, parecem estar ligados, e a linha do tempo é difícil de acompanhar. O boletim aconselha ficar longe até que provem ser mais do que trabalhos derivados.
Outros pontos merecem destaque. O Let's Encrypt anunciou que, em fevereiro de 2027, reduzirá a validade dos certificados SSL gratuitos de 90 para 64 dias, o que torna a renovação automática confiável ainda mais importante para quem roda um reverse proxy em casa. A Nabu Casa vai renomear o Home Assistant Cloud para Home Assistant Link, por causa da conotação negativa que a palavra "cloud" carrega hoje. O projeto de compartilhamento de segredos criptografados Hemmelig foi arquivado no GitHub, e a NVIDIA Shield TV, uma caixa de streaming de sete anos muito popular entre os homelabbers, ficou 100 dólares mais cara, culpa atribuída à inflação de hardware causada pela IA.
O autor também lançou a Pesquisa de Usuários Self-Host 2026, com 45 perguntas sobre hardware, software, sistemas operacionais, dados demográficos e IA. A pesquisa do ano passado teve pouco mais de 4 mil respostas, e a deste ano já tem 2 mil em apenas dois dias. Ela fica aberta até 31 de outubro, e os resultados saem no início de novembro.
Pessoalmente, a mudança nos certificados é o item mais prático: se a sua configuração de renovação for um pouco frágil, agora é um bom momento para testá-la.
Fonte: selfh.st
A RedesZone responde a uma dúvida muito comum entre quem monta um servidor em casa: é preciso reiniciar o NAS de vez em quando ou dá para deixá-lo ligado o tempo todo?
A resposta curta é que sim, ele pode ficar ligado 24 horas por dia. Um NAS foi projetado para funcionar de forma contínua, usa unidades de armazenamento específicas para isso e serve para backups, para liberar espaço em outros equipamentos ou para compartilhar arquivos grandes. Ele consome energia, claro, assim como o roteador ou uma câmera de segurança, mas esses aparelhos são projetados para gastar pouco em repouso. Mesmo depois de meses de uso contínuo, não há um motivo obrigatório para reiniciá-lo, além de economizar energia ou simplesmente não precisar dele.
Há situações em que vale a pena reiniciar: depois de uma atualização do sistema operacional, do firmware ou de determinados pacotes, mesmo que o equipamento não peça; quando há problemas de software, como um aplicativo que para de funcionar, um serviço lento, uma interface web que se comporta mal ou erros em alguma seção; após uma troca de hardware; e depois de qualquer mudança importante no funcionamento. Às vezes um processo travou ou um programa não foi encerrado corretamente, e um reinício devolve tudo ao normal.
Acho um conselho sensato e sem dramas. Para um laboratório caseiro, a regra prática é deixar o NAS trabalhando e reiniciá-lo de forma intencional, depois de uma atualização ou quando algo se comporta de maneira estranha, em vez de fazer isso por costume.
Fonte: RedesZone
Quando você roda aplicativos de código aberto em um servidor doméstico, muitas vezes precisa enviar e-mails para cadastros ou redefinições de senha. Mas enviar e-mails diretamente de casa exige preparar um servidor SMTP e configurar um domínio de envio, e isso dá mais trabalho do que parece. Este artigo, que encontrei no Qiita, resolve o problema de forma prática usando o Mailpit e o Discord.
O Mailpit era, originalmente, uma ferramenta para testar envio de e-mails. Ele pode funcionar como servidor SMTP e também tem uma API de teste. Se você configurar um webhook, ele pode chamar um aplicativo externo assim que uma mensagem chega. O artigo usa esse recurso para montar um sistema que envia o conteúdo dos e-mails recebidos para o Discord.
A montagem é simples: dois contêineres iniciados com o Docker Compose, o Mailpit e um webhook-handler. O webhook-handler é um pequeno aplicativo em Python feito com FastAPI. Ele recebe os webhooks do Mailpit, formata remetente e destinatário e os encaminha para um webhook do Discord. A notificação também pode incluir um link para a interface web do Mailpit, para consultar a mensagem quando necessário. Configurações como a URL do webhook ficam em um arquivo .env separado.
Mesmo sem enviar nenhum e-mail para fora, saber na hora que chegou um e-mail de redefinição de senha é bem prático. Para quem tem vários apps em um homelab, reunir todos os e-mails em um só lugar deve facilitar bastante a administração. O post é de agosto de 2026.
Fonte: Qiita
Uma história pequena, mas que merece reflexão para quem administra a própria rede doméstica. Segundo o GenK, um usuário do X chamado @NomadsGalaxy estava verificando o Wi-Fi dos pais quando percebeu que uma cafeteira Keurig tinha gerado cerca de 1 TB de upload e quase 10 GB de download em apenas 10 dias.
Ele descobriu isso ao olhar o sistema de rede UniFi da casa dos pais. Esse volume anormal sobrecarregou um dos pontos de acesso Wi-Fi. Em vez de investigar a causa, ele desligou a máquina da tomada e comprou outro produto para os pais. De acordo com o artigo, a maior parte do tráfego parecia ficar dentro da rede interna, sem sair para a Internet, então ainda não há provas de que o aparelho tenha enviado os dados da família para servidores externos. A causa mais provável é um erro de software ou de comunicação na rede, e uma reinicialização pode ter resolvido o problema.
O artigo também fala do quadro maior da casa inteligente: quanto mais dispositivos conectados, maiores as chances de falhas, brechas de segurança ou interrupções de serviço. Dispositivos IoT podem virar porta de entrada para ataques se o fabricante não atualizar o software com frequência, e alguns produtos perdem a maior parte das funções quando a empresa desliga seus servidores.
Para mim, a lição prática é ter uma ferramenta que monitore o tráfego por dispositivo na rede de casa e considerar separar os dispositivos IoT em uma rede própria. Sem números, é muito difícil perceber o que uma cafeteira está fazendo.
Fonte: GenK
Quem administra uma rede doméstica ou um pequeno homelab conhece bem o sufixo .lan: ele aparece nos painéis dos roteadores, nos servidores DNS internos e nos endereços que usamos para acessar dispositivos sem um domínio registrado. O IlSoftware.it informa que uma candidatura apresentada à ICANN pode transformá-lo em um domínio da Internet acessível no mundo todo.
O pedido para o TLD .lan foi apresentado pela Coffee Danger, empresa norte-americana, e ainda está na fase de Pre-Evaluation Processing. Isso significa que o domínio não foi aprovado e ainda não pode ser usado para registrar endereços públicos. A candidatura faz parte da nova rodada de atribuição de domínios de primeiro nível iniciada pela ICANN em 2026, que envolveu centenas de empresas: entre os candidatos estão o Google com .browser, a OpenAI com .openai e .chatgpt, a Meta com .facebook e a italiana Aruba com domínios como .pec, .vps, .lab, .roma e .ciao. Todos os pedidos continuam sujeitos a avaliação.
O ponto delicado é que .lan não é um nome como outro qualquer. Muitos técnicos o usam há tempos, por exemplo nas.lan, router.lan ou camera.lan. Se um nome considerado interno entrar no DNS público, o risco é ter falhas de funcionamento, consultas DNS que saem da rede e comunicações que podem chegar a destinos diferentes dos previstos.
Como entusiasta de redes domésticas, acho a notícia um bom lembrete: para nomes internos, convém usar sufixos pensados para essa finalidade e não depender de convenções de fato. Por enquanto não há nenhuma decisão, mas vale a pena acompanhar.
Fonte: IlSoftware.it
O Korben volta a um comando da Cloudflare que muitos desenvolvedores já usam: cloudflared tunnel --url. Ele publica um servidor que roda na sua máquina em um endereço trycloudflare.com, sem conta, sem nome de domínio e, principalmente, sem precisar abrir nenhuma porta no roteador. Para quem hospeda serviços em casa, é um jeito simples de mostrar um projeto a alguém em um teste rápido.
A novidade recente é a opção --allowed-mail. Antes, qualquer pessoa com o link podia acessar o serviço. Agora o acesso pode ser restrito a alguns endereços de e-mail definidos por você, com um código de uso único enviado pelo Cloudflare Access.
O tutorial começa com um pequeno servidor web local na porta 8080, com uma página de teste servida pelo Python. O cloudflared é o conector de código aberto que estabelece a conexão de saída com a rede da Cloudflare. No Mac, a instalação é feita pelo Homebrew. No Debian ou no Ubuntu, é preciso usar o repositório oficial da Cloudflare, cuja chave de assinatura mudou recentemente, e por isso o autor recomenda seguir os comandos atuais, e não os de tutoriais antigos.
Um ponto que me chamou a atenção: se você faz agentes de IA trabalharem com essa ferramenta, a Cloudflare recomenda um hook PreToolUse que bloqueie qualquer comando sem --allowed-mail, para evitar que um agente exponha um túnel público por engano.
Para um homelab, é uma alternativa leve a abrir portas ou usar uma VPN, desde que você lembre que um túnel público continua sendo uma exposição na internet, mesmo que temporária.
Fonte: Korben
