Uma nota da Zima
Obrigado, Bob, por transformares o teu tempo com o ZimaCube em algo muito mais útil do que uma análise convencional. O teu diário contínuo acompanha a máquina à medida que muda de função — desde as primeiras impressões e a desmontagem do hardware até ao ZimaOS, Windows Server, Proxmox, cópias de segurança, monitorização, agentes de IA e até um router virtualizado — mantendo no mesmo registo tanto os aspetos de que gostas como os que te frustram. Este tipo de experimentação honesta e de longo prazo ajuda-nos a compreender não só o que o ZimaCube consegue fazer, mas também o que acontece depois de passar a fazer parte de um homelab real.
— Zima
Conheça Bob Loves Tech
Bob Loves Tech é um entusiasta de homelab e criador de conteúdos tecnológicos cujo trabalho abrange Windows, Linux, virtualização, redes, self-hosting e o hardware subjacente.
A relação de Bob com o hardware Zima é anterior a este projeto. Já tinha passado algum tempo com produtos Zima anteriores, incluindo o ZimaBoard e o ZimaBlade, antes de se juntar ao Zima Pioneer Programme. Quando o ZimaCube chegou, decidiu não produzir uma única análise aperfeiçoada e seguir em frente. Em vez disso, criou o ZimaCube Experience Blog, um repositório público que continua a crescer à medida que a máquina muda juntamente com o seu homelab.
Bob descreve-o como um diário contínuo, e não como uma análise formal. Essa distinção explica bem o projeto. Inclui a primeira reação ao hardware, as coisas que descobriu depois de o abrir, os sistemas operativos que experimentou, a infraestrutura que construiu à sua volta e as conclusões que se alteraram após semanas de utilização.
Documentar o ZimaCube para além de uma primeira impressão
As primeiras entradas do projeto de Bob começam onde começam a maioria das histórias sobre hardware: desembalar a máquina, observar a qualidade de construção, verificar as portas e os suportes de discos e decidir o que parece diferente quando o hardware está fisicamente sobre a secretária.
Mas o diário não fica por aqui. Bob regressa ao hardware depois de já ter vivido com ele. O seu repositório inclui uma visão geral dedicada do hardware, uma desmontagem completa, um acompanhamento após seis semanas, uma análise mais detalhada do motivo pelo qual a memória, e não os núcleos do CPU, se tornou o verdadeiro estrangulamento prático, e uma entrada separada que coloca a pergunta que acaba por importar a todos os analistas: gastaria ele realmente o seu próprio dinheiro nele?
É essa evolução que torna o projeto valioso. Uma primeira impressão mostra como um produto chega. Um diário contínuo mostra o que permanece depois de passar o entusiasmo inicial.
Abrir o hardware e acompanhar os pormenores
Um dos capítulos sobre o hardware chama-se simplesmente Desmontá-lo, o que diz muito sobre a abordagem de Bob.
Em vez de tratar o ZimaCube como um aparelho NAS fechado, abriu o chassis e documentou os componentes internos, incluindo o sistema de refrigeração e os pequenos detalhes de hardware que só se tornam visíveis quando alguém decide que a máquina deve ser reparável e modificável.
Essa desmontagem conduz mais tarde a outra parte do diário: o que mudou após seis semanas e o que não mudou. Algumas observações tornam-se menos importantes com o tempo. Outras — incluindo a refrigeração, o comportamento da ventoinha, a capacidade de memória, o acesso às atualizações e a forma como o hardware se integra num ambiente sempre ligado — tornam-se mais importantes.
Para os leitores que querem aprofundar as mesmas questões sobre o hardware, o nosso guia de desmontagem do ZimaCube explica melhor a disposição interna e as possibilidades de atualização, enquanto 7 detalhes engenhosos do design do ZimaCube analisa mais de perto pormenores que se tornam visíveis quando o sistema é aberto, em vez de ser observado apenas através de uma tabela de especificações.
Descobrir que a RAM é mais importante do que mais núcleos de CPU
Uma das entradas de hardware posteriores chega a uma conclusão muito mais útil do que outro gráfico de benchmark: o ZimaCube não precisava de mais núcleos de CPU para a carga de trabalho de Bob. Precisava de mais memória.
O diário descreve um sistema com dez convidados em execução, enquanto a utilização do CPU se mantinha perto dos quatro por cento, mas o consumo de memória tinha subido para cerca de 27 GB. Isto muda a forma como o hardware deve ser avaliado. O processador não foi o primeiro limite prático. Foi a configuração de memória fornecida.
Para uma máquina que gradualmente se torna um anfitrião de virtualização, servidor de cópias de segurança, nó de monitorização, anfitrião de VMs de router e plataforma de experimentação com IA, a capacidade de memória passa a ser infraestrutura, e não apenas uma especificação.
Este é precisamente o tipo de conclusão que um relato de utilização prolongada pode revelar. Não resulta de perguntar o que o CPU consegue fazer teoricamente. Resulta de observar o sistema depois de se terem acumulado cada vez mais cargas de trabalho reais.
Apagar o ZimaOS e instalar o Windows Server 2025
A experiência mais marcante no repositório de Bob começou quando removeu o ZimaOS e instalou o Windows Server 2025 diretamente no ZimaCube.
Bob descreve a combinação como estranha, e é precisamente por isso que a experimentou. O projeto tornou-se uma forma de testar o hardware sem depender do ambiente de software com que foi fornecido: comportamento da instalação, procura de controladores, rede, armazenamento e se uma plataforma NAS compacta ainda fazia sentido quando tratada como um servidor Windows de uso geral.
A experiência também demonstra uma parte importante da filosofia do hardware Zima. Remover o ZimaOS não põe fim à vida útil da máquina. O hardware x86 continua a ser uma plataforma que pode ser reconstruída em torno de um sistema operativo diferente.
Transformámos essa experiência num guia de configuração do Windows Server 2025 no ZimaCube mais estruturado, que aborda o processo de instalação, o trabalho com o controlador de rede Intel e a configuração do armazenamento para utilizadores que queiram explorar a mesma direção.
Dar ao ZimaOS uma oportunidade justa antes de avançar
O Windows Server é apenas uma parte da história dos sistemas operativos. Bob também escreveu uma análise dedicada ao ZimaOS no Diário do Homelab.
A sua conclusão é intencionalmente mais matizada do que “bom” ou “mau”. O repositório descreve o ZimaOS como uma excelente opção para dispositivos mais pequenos, mas questiona se a experiência simplificada corresponde ao que pretende de um ZimaCube cada vez mais orientado para a virtualização e a infraestrutura de homelab.
Essa crítica é útil porque Bob não está a avaliar o ZimaOS como alguém que está a experimentar o self-hosting pela primeira vez. Está a avaliá-lo a partir da perspetiva de alguém que já gere um homelab com vários sistemas e se sente à vontade a gerir ele próprio as camadas inferiores.
Para outro utilizador, a simplicidade pode ser o motivo para ficar. Para Bob, o aumento da complexidade da infraestrutura acabou por ser o motivo para sair.
A mesma escolha é analisada na nossa comparação entre ZimaOS, Proxmox e Windows Server, que resultou do mesmo conjunto mais abrangente de experiências.
Fazer do Proxmox o centro do homelab
Depois de experimentar outras opções, Bob chegou finalmente a uma conclusão muito mais sólida sobre o sistema operativo que queria no ZimaCube: o Proxmox era o ambiente que fazia mais sentido para o seu homelab.
O diário descreve um ZimaCube a trabalhar em conjunto com armazenamento NFS da Synology e a tornar-se parte de uma frota de três hosts. Nesse momento, a máquina já não está principalmente a ser avaliada como NAS. Tornou-se infraestrutura.
Essa mudança abre caminho a várias entradas posteriores do diário, porque o Proxmox fornece a base para as experiências seguintes: infraestrutura de cópias de segurança, monitorização, serviços de IA e virtualização de rede.
Para os utilizadores interessados em criar a mesma base, o nosso guia de configuração do ZimaCube + Proxmox aborda o percurso desde a preparação da BIOS até às VMs, aos contentores LXC, ao armazenamento, à rede e ao passthrough.
Criar cópias de segurança em torno da infraestrutura
Quando uma máquina se torna infraestrutura, a pergunta seguinte já não é se pode executar mais serviços. É o que acontece quando um desses serviços desaparece.
O diário de Cópias de segurança do Bob acompanha essa transição. O Proxmox Backup Server entra em cena, juntamente com a incómoda questão circular de fazer cópias de segurança da infraestrutura utilizando uma infraestrutura que faz parte do próprio sistema que está a ser protegido.
O resultado tem menos que ver com encontrar um único destino de cópia de segurança perfeito e mais com a criação de camadas que tornam a recuperação suficientemente previsível para que as cópias de segurança deixem de ser algo em que o Bob tenha de pensar constantemente.
Essa experiência serviu de base ao nosso guia do Proxmox Backup Server, que desenvolve a ideia através de cópias de segurança incrementais de VMs e contentores, retenção, verificação e camadas de proteção adicionais.
Acompanhar a frota em vez de a verificar constantemente
A próxima pergunta do Bob é familiar para qualquer pessoa cujo homelab tenha crescido para além de alguns serviços: de quanta monitorização precisa realmente uma só pessoa?
O texto Acompanhar a frota explora ferramentas como o Pulse e o Proxmox Data Center Manager, mas o objetivo mais interessante é reduzir a quantidade de atenção manual que a infraestrutura exige.
Um sistema de monitorização útil não deve criar outro painel que tenha de ser vigiado o dia todo. Deve tornar o funcionamento normal discreto e tornar as falhas visíveis quando é realmente necessária atenção.
Desenvolvemos mais essa parte da experiência do Bob no nosso guia de monitorização de servidores domésticos, que aborda o Pulse, o Uptime Kuma, o Proxmox Data Center Manager e o momento em que a monitorização deve reduzir, em vez de criar, a manutenção.
Dar uma casa permanente a um agente de IA
O diário acaba por avançar para outra camada de autoalojamento: executar um agente de IA persistente no ZimaCube.
Em Porque é que o Hermes Agent deve estar no seu ZimaCube, Bob analisa a máquina não apenas como infraestrutura de armazenamento ou virtualização, mas como um local sempre disponível para alojar um agente autoalojado.
A combinação faz sentido no contexto de tudo o que aconteceu antes. Quando o ZimaCube já está online ininterruptamente, ligado ao homelab, com cópias de segurança e monitorizado, um agente pode tornar-se mais um serviço persistente, em vez de ficar dependente de uma sessão num portátil.
Se quiser explorar diretamente no ZimaOS esse fluxo de trabalho, o nosso guia de configuração do Hermes Agent para o ZimaOS aborda a instalação, a configuração do modelo, a integração de mensagens e o acesso ao painel do Hermes.
Transformar o ZimaCube num router OPNsense
Uma das experiências posteriores mais interessantes coloca novamente a máquina num papel completamente diferente: infraestrutura de rede.
O diário de OPNsense de Bob analisa as duas interfaces 2.5GbE do ZimaCube em conjunto com o Proxmox e questiona se uma VM de router poderá ser uma das utilizações mais convincentes do hardware até agora.
É aqui que a decisão anterior sobre o sistema operativo começa a compensar. O Proxmox permite que a mesma máquina física aloje cargas de trabalho que tradicionalmente exigiriam equipamentos separados, enquanto as duas interfaces Ethernet criam um caminho natural para separar a WAN e a LAN numa configuração de firewall virtualizada.
O nosso guia do Proxmox também explora a execução do OPNsense como router de software numa VM no ZimaCube, incluindo a ideia de passar interfaces 2.5GbE separadas para o dispositivo de rede.
O valor está no diário, não numa conclusão final
Visto como um todo, o projeto de Bob é muito mais interessante do que uma análise com uma conclusão fixa.
O mesmo ZimaCube surge sob várias formas diferentes ao longo da vida do repositório.
Começa como uma nova peça de hardware. Bob desembala-o, inspeciona a construção, abre o chassis, questiona a refrigeração e começa a pensar em atualizações.
Transforma-se numa experiência com o Windows Server. Remover o ZimaOS testa se o hardware subjacente continua a ser útil sem o software com que foi fornecido.
Volta à questão do sistema operativo. Bob faz a sua própria avaliação do ZimaOS antes de decidir que o seu ambiente, cada vez mais complexo, precisa de algo diferente.
Torna-se um anfitrião Proxmox. A partir daí, a máquina junta-se a uma frota mais ampla e começa a acumular responsabilidades de infraestrutura.
Passa a fazer parte do sistema de cópias de segurança e monitorização. O Proxmox Backup Server, o Pulse e a gestão da frota mudam o objetivo de “continuar a adicionar serviços” para “tornar os serviços suficientemente fiáveis para deixar de pensar neles”.
Depois, torna-se um anfitrião de IA e um dispositivo de rede. O Hermes Agent e o OPNsense não são experiências isoladas; são possíveis porque as camadas de infraestrutura anteriores já estão implementadas.
O resultado é exatamente aquilo que o Bob prometeu originalmente: não uma análise formal, mas notas, experiências, opiniões que mudam com a experiência e um projeto de homelab cada vez mais ambicioso.
Uma história de utilizador tornou-se uma biblioteca de guias do ZimaCube
O projeto do Bob também demonstra por que razão os testes comunitários a longo prazo têm valor para além do homelab de uma só pessoa.
Várias experiências documentadas no Blog da Experiência com o ZimaCube deram entretanto origem a recursos Zima mais aprofundados: instalação do Windows Server, implementação do Proxmox, seleção do sistema operativo, arquitetura de cópias de segurança e monitorização do homelab.
Isto cria um ciclo útil entre a experiência da comunidade e a documentação. O Bob experimenta algo por curiosidade. O diário regista o que aconteceu. As partes úteis tornam-se mais fáceis de reproduzir para a próxima pessoa.
A história continua a ser escrita
A história do Bob Loves Tech e da Zima continua a ser escrita. O Blog da Experiência com o ZimaCube já passou pelo unboxing e pela desmontagem do hardware, pelo ZimaOS, Windows Server, Proxmox, cópias de segurança, monitorização da frota, Hermes Agent e OPNsense — e o objetivo de um diário em constante atualização é precisamente não ter de existir uma configuração final.
À medida que o homelab muda, o papel do ZimaCube também pode mudar. Se quiser ver o que o Bob vai experimentar a seguir, siga o Blog da Experiência com o ZimaCube no GitHub.
