Montei um homelab no meu Mac Mini · drumas

Durante muito tempo eu quis tirar da mesa um problema que muita gente da área técnica conhece bem: minha vida pessoal, meus arquivos, meus testes e parte do meu ambiente de desenvolvimento estavam excessivamente dependentes de equipamento de operadora, roteador doméstico genérico e serviços de terceiros.

Não era uma questão de paranoia. Era uma questão de organização, autonomia e previsibilidade.

Eu queria três coisas ao mesmo tempo:

ter uma rede doméstica mais limpa e mais controlável;
concentrar serviços locais importantes em um equipamento meu, fora do ambiente de trabalho;
preparar a base para, no futuro, transformar esse setup em um servidor doméstico mais sério, com storage maior, backup melhor e alguns serviços self-hosted.

No meu caso, a peça central disponível já era um Mac Mini com 16 GB de RAM e 1 TB de SSD. Então, em vez de pensar em “qual homelab ideal eu compraria do zero”, eu inverti a lógica: “como montar uma arquitetura correta usando bem o que eu já tenho”.

O resultado foi um homelab doméstico focado em macOS, com duas conexões de fibra óptica, Pi-hole para a rede inteira, expansão futura para storage e uma topologia simples o bastante para um leigo manter, mas correta o bastante para um desenvolvedor não passar raiva.

O objetivo real desse projeto

Quando alguém fala em homelab, muita gente imagina rack, switch gerenciável, VLAN em todo lugar, mini PCs em cluster e uma conta de energia questionável.

Não era esse o objetivo aqui.

O objetivo foi montar um ambiente doméstico que resolvesse problemas reais:

separar melhor o que é meu do que é da empresa;
reduzir dependência do roteador da operadora;
ter um ponto central para DNS, bloqueio, arquivos e, depois, automação e mídia;
unificar duas internets de casa em uma arquitetura minimamente profissional;
preparar um caminho de crescimento, sem começar grande demais.

Esse ponto é importante: um homelab útil não precisa nascer complexo. Ele precisa nascer coerente.

A primeira decisão importante: o Mac Mini não deve virar o roteador principal

Aqui vale ser direto, porque esse é o tipo de erro de arquitetura que parece elegante no papel e vira dor de cabeça no uso real.

O Mac Mini é excelente como servidor doméstico. Ele é silencioso, econômico, confiável, tem SSD rápido, consome pouco espaço físico e, para serviços leves e médios, sobra máquina. Docker Desktop roda em Mac com Apple Silicon em versões suportadas do macOS, exigindo pelo menos 4 GB de RAM, então usar containers nesse cenário é plenamente viável.

Mas ele não é a peça certa para unificar duas fibras como roteador principal.

O motivo não é ideológico. É técnico e operacional:

macOS não é uma plataforma de roteamento multi-WAN doméstico nativa;
você não ganha portas físicas suficientes para WAN/LAN sem começar a empilhar adaptadores;
a manutenção fica pior;
o troubleshooting fica pior;
e o dia em que você quiser reiniciar, atualizar ou mexer no host, sua rede inteira sente.

Por isso, a arquitetura correta foi esta:

os dois modems/ONUs das operadoras entram em bridge;
um roteador multi-WAN dedicado faz o trabalho de borda;
o Mac Mini fica atrás dele, como servidor central.

Essa decisão parece menos “hacker” e mais “chata”, mas é exatamente por isso que ela é melhor.

A topologia que usei

A rede ficou conceitualmente assim:

Fibra Claro  -> modem/ONU em bridge -> WAN1 do roteador multi-WAN
Fibra Amigo  -> modem/ONU em bridge -> WAN2 do roteador multi-WAN

Roteador multi-WAN -> switch gigabit -> Mac Mini
                                   -> access point Wi‑Fi
                                   -> demais dispositivos cabeados

O roteador escolhido foi o TP-Link ER605, porque ele existe oficialmente no catálogo Omada como roteador VPN gigabit cabeado, com suporte a múltiplas WANs e gerenciamento no ecossistema Omada. E aqui está um detalhe importante que muita recomendação na internet erra: o ER605 não é Wi‑Fi. Ele é um roteador cabeado. Se você usar ele, vai precisar de um access point separado para a rede sem fio.

Esse detalhe muda a lista de compras e evita uma surpresa desagradável depois.

O papel do Pi-hole nessa história

O Pi-hole não é milagre, e vale deixar isso claro para não vender fantasia.

Ele não “anonimiza” toda sua navegação. Ele não substitui VPN. Ele não impede toda forma de telemetria do mundo. Ele também não bloqueia tudo, porque muita coisa hoje é servida do mesmo domínio que entrega conteúdo legítimo.

O que ele faz, e faz muito bem, é atuar como DNS sinkhole para a rede inteira, protegendo dispositivos sem instalar cliente em cada máquina.

Na prática, isso significa:

bloquear boa parte de ads, trackers e domínios inúteis;
limpar navegação em TVs, celulares, tablets e IoT;
reduzir ruído de rede;
centralizar observabilidade básica de consultas DNS;
dar mais controle sobre o que sua casa inteira tenta resolver na internet.

Para ambiente doméstico, isso já é muito.

Quanto custou, de forma honesta

Eu não gosto de artigo que finge custo idealizado. Então aqui vai a versão honesta: montar isso com qualidade mínima ainda é relativamente barato comparado ao ganho de controle, mas não é “quase de graça”.

Os preços variam muito por loja, estoque, versão e importador. Em março de 2026, a faixa observada ficou mais ou menos assim:

TP-Link ER605: encontrei oferta a partir de R$ 477.
TP-Link EAP225 como access point: vi anúncios na casa de R $475**, mas também achei loja grande listando acima de **R$ 800, o que mostra como esse item oscila bastante no Brasil.
Switch TL-SG108: faixa próxima de R$ 216 em marketplace, embora isso também varie.
Nobreak APC 600VA / similar: encontrei referência em torno de R$ 530 para linha APC de 600VA, mas também vi preço significativamente maior em revenda especializada; aqui o mercado varia demais.

Então, sendo franco, o investimento adicional mais realista para sair do zero fica em algo entre R $1.200 e R$ 2.000, dependendo de três fatores:

se você já tem switch;
se vai comprar AP novo ou reaproveitar um roteador antigo em modo access point;
e se vai colocar nobreak logo de início.

Esse número sobe se você já quiser pensar em storage externo decente, enclosure ou discos maiores.

O que eu comprei em conceito, mesmo quando não comprei tudo de uma vez

A pilha mínima recomendável ficou assim:

Mac Mini 16 GB / 1 TB como host principal;
roteador multi-WAN dedicado;
access point separado para Wi‑Fi;
switch gigabit simples;
cabos Cat6;
nobreak;
depois, armazenamento externo.

Essa parte importa porque muita gente tenta pular o access point ou o nobreak para economizar. O primeiro quebra a experiência da casa. O segundo quebra a confiabilidade do homelab.

Por que unificar as duas fibras

No meu caso havia dois links, dois modems e duas redes diferentes. Isso é o tipo de coisa que parece aceitável no começo, mas piora a vida com o tempo.

Do ponto de vista operacional, duas redes separadas em casa geram:

dispositivos caindo em topologias diferentes;
dificuldade para compartilhar serviços locais;
mais confusão com DNS e IP fixo;
troubleshooting mais difícil;
e pouca previsibilidade quando uma operadora oscila.

Ao colocar ambos os links atrás de um roteador multi-WAN, eu passo a ter uma rede só, com uma borda só, uma política de DHCP só, uma política de DNS só e espaço para escolher entre balanceamento e failover.

Não é magia. Uma única conexão TCP não necessariamente “soma” as duas fibras. Mas para uma casa inteira, com múltiplos dispositivos e múltiplas sessões, o ganho operacional é enorme.

Passo a passo da montagem

1. Colocar os modems em bridge

Esse é o primeiro ponto crítico.

No caso da Claro, existe tutorial oficial de configuração de bridge para modelos como o CH8568, o que ajuda bastante quando o equipamento é compatível.

A lógica é simples:

o equipamento da operadora deixa de ser seu roteador principal;
ele passa a entregar o link para o seu roteador multi-WAN;
NAT, DHCP e DNS ficam centralizados na sua própria borda.

Para o segundo provedor, o caminho depende muito do modelo da ONU/modem. Nem sempre haverá bridge facilmente exposta; às vezes você cai em DMZ ou precisa de ajuda do suporte.

Meu conselho sincero é: antes de comprar qualquer coisa, confirme se ambos os equipamentos podem operar em bridge ou, no mínimo, em uma configuração que não sabote seu roteador próprio.

2. Montar a rede física

Depois da parte de bridge, a fiação é direta:

modem/ONU da operadora A na WAN1;
modem/ONU da operadora B na WAN2;
LAN do roteador no switch;
Mac Mini no switch por cabo;
access point no switch;
demais dispositivos onde fizer sentido.

O Mac Mini precisa ficar cabeado. Não faz sentido usar ele como servidor central e deixá-lo no Wi‑Fi.

3. Configurar o roteador multi-WAN

No meu caso, a ideia foi usar o roteador apenas para o que ele deve fazer bem:

borda;
DHCP;
política de WAN;
failover ou load balancing;
firewall básico.

Aqui eu prefiro simplicidade. Nada de inventar regra demais no primeiro dia. Primeiro você estabiliza:

sub-rede da casa;
faixa de DHCP;
WAN1 e WAN2;
teste de conectividade;
depois DNS apontando para o Pi-hole.

4. Dar IP fixo ao Mac Mini

Servidor doméstico sem IP previsível é pedir para criar problema futuro.

O host do Pi-hole, do compartilhamento SMB e de qualquer serviço futuro precisa ter endereço fixo. Isso pode ser feito com reserva DHCP no roteador ou IP estático no próprio macOS. Eu prefiro decidir isso logo no começo e documentar.

5. Subir o Pi-hole em Docker

Para o Mac Mini, isso foi importante por dois motivos:

eu não queria poluir o host com instalação manual desnecessária;
eu queria manter o serviço portável, simples de atualizar e simples de reconstruir.

A estrutura é objetiva: volume persistente, porta 53 TCP/UDP, interface web, senha forte e restart policy.

Depois disso, o roteador passa a distribuir o IP do Pi-hole como DNS primário da rede.

O que melhora na prática

Depois que um setup desses entra em produção doméstica, as melhorias reais não são “cinematográficas”. Elas são cumulativas.

Você percebe:

menos lixo de rede;
menos anúncio em app, smart TV e navegação comum;
mais clareza sobre o que sua rede consulta;
mais previsibilidade na infraestrutura da casa;
um lugar central para crescer serviços pessoais.

E talvez o mais importante para quem trabalha com tecnologia: você finalmente cria um ambiente seu, com lógica sua, governança sua e documentação sua.

Isso tem valor técnico e mental.

O que esse setup não resolve

Também vale registrar o que ele não resolve, porque artigo honesto precisa dizer onde o teto está.

Esse setup não resolve, sozinho:

privacidade completa contra tudo;
bloqueio universal de publicidade em plataformas que servem anúncios do mesmo domínio do conteúdo;
alta disponibilidade real;
backup enterprise;
segurança avançada por padrão;
segmentação de rede madura.

Ele é uma base muito boa. Não é um data center em miniatura.

Se você quiser avançar depois, os próximos passos naturais são:

segundo DNS/Pi-hole para redundância;
VLANs para IoT e visitantes;
NAS dedicado;
backup externo automatizado;
VPN de acesso remoto;
observabilidade melhor.

Por que eu fiz isso em casa, e não no ambiente de trabalho

Esse ponto, para mim, é central.

Eu quis um ambiente local próprio porque não queria que minha organização pessoal, meus arquivos, meus testes e meus experimentos dependessem estruturalmente de contexto corporativo.

Ter um pequeno servidor em casa significa:

meus dados pessoais ficam sob minha guarda;
meus serviços auxiliares não ficam misturados com infraestrutura de empresa;
eu consigo manter laboratório, arquivos e automações fora do notebook principal;
eu ganho autonomia para evoluir isso no meu ritmo.

Para muita gente da nossa área, isso também vira um bom meio-termo entre hobby e utilidade concreta. Não é só brincar de infra. É começar a tratar a própria casa como ambiente computacional com algum desenho técnico.

Sobre expansão de storage

O Mac Mini segura bem a função de host inicial, mas 1 TB interno não é “storage de servidor”. É storage de host.

A expansão natural é via armazenamento externo de qualidade, e aqui eu seria conservador:

no começo, dá para usar SSD externo ou HD externo bom;
no médio prazo, faz sentido pensar em enclosure multi-bay;
no longo prazo, se o volume crescer de verdade, o ideal é migrar a parte pesada para NAS ou máquina dedicada.

O Mac Mini continua ótimo como cérebro de serviços leves. Ele não precisa virar tudo ao mesmo tempo.

Minha conclusão

O maior erro em homelab doméstico é montar uma arquitetura “bonita” demais para a vida real. O segundo maior erro é montar uma arquitetura simplória demais e continuar dependente de equipamento ruim de operadora.

O que eu busquei aqui foi o meio-termo certo:

usar o Mac Mini onde ele realmente é forte;
usar um roteador dedicado onde o macOS não é a ferramenta correta;
colocar Pi-hole como serviço central de rede;
preparar a casa para crescer sem recomeçar do zero depois.

Para quem é desenvolvedor, isso é um projeto excelente porque ensina arquitetura, operação, redes, containers e disciplina de documentação sem exigir orçamento absurdo.

Para quem é leigo, a vantagem é outra: você passa a ter uma rede de casa mais organizada, mais previsível e menos refém do padrão improvisado das operadoras.

No fim, foi exatamente isso que eu queria construir: não um laboratório para impressionar, mas uma infraestrutura pessoal pequena, correta, expansível e realmente minha.