A Note from Zima
Thank you, Bob, for turning your time with ZimaCube into something much more useful than a conventional review. Your running journal follows the machine as it changes roles — from first impressions and hardware teardown to ZimaOS, Windows Server, Proxmox, backups, monitoring, AI agents, and even a virtualized router — while keeping the parts you like and the parts that frustrate you in the same record. That kind of long-term, honest experimentation helps us understand not only what ZimaCube can do, but what happens after it becomes part of a real homelab.
— Zima
Meet Bob Loves Tech
Bob Loves Tech is a homelabber and technology creator whose work moves across Windows, Linux, virtualization, networking, self-hosting, and the hardware underneath them.
His relationship with Zima hardware predates this project. Bob had already spent time with earlier Zima products including ZimaBoard and ZimaBlade before joining the Zima Pioneer Programme. When ZimaCube arrived, he decided not to produce a single polished review and move on. Instead, he created ZimaCube Experience Blog, a public repository that keeps growing as the machine changes with his homelab.
Bob describes it as a running journal rather than a formal review. That distinction explains the project well. It includes the first reaction to the hardware, the things he discovered after opening it, the operating systems he tried, the infrastructure he built around it, and the conclusions that changed after weeks of use.
Documenting the ZimaCube Beyond a First Impression
The earliest entries in Bob's project start where most hardware stories do: unboxing the machine, looking at the build quality, checking the ports and drive caddies, and deciding what feels different once the hardware is physically on the desk.
But the journal does not stop there. Bob returns to the hardware after living with it. His repository includes a dedicated hardware overview, a full teardown, a six-week follow-up, a closer look at why memory rather than CPU cores became the practical bottleneck, and a separate entry asking the question that eventually matters to every reviewer: would he actually spend his own money on it?
That progression makes the project valuable. A first impression tells you how a product arrives. A running journal tells you what survives after the novelty has worn off.
Opening the Hardware and Following the Details
One of the hardware chapters is simply called Taking It Apart, which says a lot about Bob's approach.
Instead of treating the ZimaCube as a sealed NAS appliance, he opened the chassis and documented the internals, including the cooling system and the small hardware details that only become visible once someone decides the machine should be serviceable and modifiable.
That teardown later feeds into another part of the journal: what changed after six weeks and what did not. Some observations become less important with time. Others — including cooling, fan behavior, memory capacity, upgrade access, and the way the hardware fits into an always-on environment — become more important.
For readers who want to go deeper into the same hardware questions, our ZimaCube teardown guide expands on the internal layout and upgrade paths, while 7 Clever Design Details in the ZimaCube looks more closely at details that become visible when the system is opened rather than viewed only through a specification table.
Discovering That RAM Matters More Than More CPU Cores
One of the later hardware entries reaches a conclusion that is much more useful than another benchmark chart: the ZimaCube did not need more CPU cores for Bob's workload. It needed more memory.
His journal describes a system with ten running guests while CPU usage remained around four percent, yet memory consumption had climbed to roughly 27GB. That changes the way the hardware should be evaluated. The processor was not the first practical limit. The shipped memory configuration was.
For a machine gradually becoming a virtualization host, backup server, monitoring node, router VM host, and AI playground, memory capacity becomes infrastructure rather than a specification.
This is exactly the kind of conclusion a long-running user story can surface. It does not come from asking what the CPU can theoretically do. It comes from watching the system after more and more real workloads have accumulated.
Wiping ZimaOS and Installing Windows Server 2025
The standout experiment in Bob's repository began when he removed ZimaOS and installed Windows Server 2025 directly on the ZimaCube.
Bob describes the combination as a strange fit, which is precisely why he tried it. The project became a way to test the hardware without relying on the software environment it shipped with: installation behavior, driver hunting, networking, storage, and whether a compact NAS platform still made sense when treated like a general-purpose Windows server.
The experiment also demonstrates an important part of the Zima hardware philosophy. Removing ZimaOS does not end the useful life of the machine. The x86 hardware remains a platform that can be rebuilt around a different operating system.
We turned that experiment into a more structured Windows Server 2025 on ZimaCube setup guide, covering the installation path, Intel network driver work, and storage configuration for users who want to explore the same direction.
Giving ZimaOS a Fair Test Before Moving On
Windows Server is only part of the operating-system story. Bob also wrote a dedicated ZimaOS Review in the Homelab Journal.
His conclusion is intentionally more nuanced than “good” or “bad.” The repository describes ZimaOS as a strong fit for smaller devices while questioning whether the simplified experience matches what he wants from a ZimaCube being pushed deeper into virtualization and homelab infrastructure.
That criticism is useful because Bob is not evaluating ZimaOS as someone trying self-hosting for the first time. He is evaluating it from the perspective of someone who already operates a multi-system homelab and is comfortable managing the lower layers himself.
For another user, simplicity may be the reason to stay. For Bob, increasing infrastructure complexity eventually became the reason to leave.
The same trade-off is explored in our ZimaOS vs Proxmox vs Windows Server comparison, which grew from the same broader set of experiments.
Making Proxmox the Center of the Homelab
After trying other directions, Bob eventually reached a much stronger conclusion about the operating system he wanted on the ZimaCube: Proxmox was the environment that made the most sense for his homelab.
The journal describes a ZimaCube working alongside NFS storage from Synology and becoming part of a three-host fleet. At that point, the machine is no longer primarily being evaluated as a NAS. It has become infrastructure.
That change opens the door to several later journal entries because Proxmox provides the foundation for the next experiments: backup infrastructure, monitoring, AI services, and network virtualization.
For users interested in building the same foundation, our ZimaCube + Proxmox setup guide covers the path from BIOS preparation to VMs, LXC containers, storage, networking, and passthrough.
Building Backups Around the Infrastructure
Once a machine becomes infrastructure, the next question is no longer whether it can run more services. It is what happens when one of those services disappears.
Bob's Backups journal follows that transition. Proxmox Backup Server enters the picture, along with the awkward circular question of backing up infrastructure using infrastructure that is itself part of the system being protected.
The result is less about finding a single perfect backup target and more about creating layers that make recovery predictable enough that backup stops being something Bob has to constantly think about.
That experience became the basis for our Proxmox Backup Server guide, which expands the idea into incremental VM and container backups, retention, verification, and additional protection layers.
Watching the Fleet Instead of Constantly Checking It
Bob's next question is a familiar one for anyone whose homelab has grown past a couple of services: how much monitoring does one person actually need?
His Watching the Fleet entry explores tools including Pulse and Proxmox Data Center Manager, but the more interesting goal is reducing the amount of manual attention the infrastructure requires.
A useful monitoring system should not create another dashboard that needs to be watched all day. It should make normal operation quiet and make failures visible when attention is actually required.
We developed that part of Bob's experience further in our home server monitoring guide, covering Pulse, Uptime Kuma, Proxmox Data Center Manager, and the point where monitoring should reduce rather than create maintenance.
Giving an AI Agent a Permanent Home
The journal eventually moves into another layer of self-hosting: running a persistent AI agent on the ZimaCube.
In Why Hermes Agent Belongs on Your ZimaCube, Bob looks at the machine not simply as storage or virtualization infrastructure, but as an always-on place for a self-hosted agent to live.
The pairing makes sense in the context of everything that came before it. Once the ZimaCube is already online around the clock, connected to the homelab, backed up, and monitored, an agent can become another persistent service rather than something tied to a laptop session.
If you want to explore that workflow on ZimaOS directly, our Hermes Agent setup guide for ZimaOS covers installation, model configuration, messaging integration, and access to the Hermes dashboard.
Turning the ZimaCube into an OPNsense Router
One of the most interesting later experiments pushes the machine into an entirely different role again: network infrastructure.
Bob's OPNsense journal looks at the ZimaCube's dual 2.5GbE interfaces together with Proxmox and asks whether a router VM might be one of the most convincing uses for the hardware yet.
This is where the earlier operating-system decision starts paying off. Proxmox allows the same physical machine to host workloads that would traditionally require separate boxes, while the two Ethernet interfaces create a natural path for separating WAN and LAN inside a virtualized firewall setup.
Our Proxmox guide also explores running OPNsense as a software router VM on ZimaCube, including the idea of passing separate 2.5GbE interfaces into the network appliance.
The Value Is in the Journal, Not a Final Verdict
Seen as a whole, Bob's project is much more interesting than a review with a fixed conclusion.
The same ZimaCube appears in several different forms over the life of the repository.
It starts as a new piece of hardware. Bob unboxes it, inspects the construction, opens the chassis, questions the cooling, and starts thinking about upgrades.
It becomes a Windows Server experiment. Removing ZimaOS tests whether the underlying hardware remains useful without the software it shipped with.
It returns to the operating-system question. Bob gives ZimaOS its own assessment before deciding that his increasingly complex environment needs something different.
It becomes a Proxmox host. From there, the machine joins a wider fleet and starts accumulating infrastructure responsibilities.
It becomes part of the backup and monitoring system. Proxmox Backup Server, Pulse, and fleet management change the goal from “keep adding services” to “make the services dependable enough to stop thinking about them.”
Then it becomes an AI host and a network appliance. Hermes Agent and OPNsense are not isolated experiments; they are possible because the earlier infrastructure layers are already in place.
The result is exactly what Bob originally promised: not a formal review, but notes, experiments, opinions that change with experience, and one increasingly ambitious homelab project.
One User Story Became a Library of ZimaCube Guides
Bob's project also demonstrates why long-term community testing has value beyond one person's homelab.
Several experiments documented in the ZimaCube Experience Blog have since developed into deeper Zima resources: Windows Server installation, Proxmox deployment, operating-system selection, backup architecture, and homelab monitoring.
That creates a useful loop between community experience and documentation. Bob tries something because he is curious. The journal records what happened. The useful parts become easier for the next person to reproduce.
The Story Is Still Being Written
Bob Loves Tech and Zima's story is still being written. His ZimaCube Experience Blog has already moved from unboxing and hardware teardown through ZimaOS, Windows Server, Proxmox, backups, fleet monitoring, Hermes Agent, and OPNsense — and the entire point of a running journal is that there does not need to be a final configuration.
As the homelab changes, the role of the ZimaCube can change with it. If you want to see what Bob experiments with next, follow the ongoing ZimaCube Experience Blog on GitHub.
