Barely Works, but Getting There: Chris’s Mixed x86 and ARM Homelab

Chris gives his homelab two clear jobs: a two-drive Debian NAS collects backups, while a ZimaBoard 2 and four Raspberry Pis provide a separate place to experiment with k3s and Ollama. A Pi Pico display makes the backup jobs visible from outside the printed enclosure. Readers planning a similar lab can see how he separates a routine he relies on from a project he is still figuring out.

Thank you, Chris, for sharing the enclosure, backup schedule and status-display idea, as well as the unfinished cluster. Those details explain how the build works in daily use—and where there is still work to do.

A naming update before the story: ZimaBlade is now ZimaBoard SE. Chris’s NAS and photographs show an earlier unit in that product family, running his own Debian installation. The current SE kits have updated package contents; the name change does not mean that his existing machine was replaced.

“I’m More of a Low-Level Maker/Tinkerer”

That's how Chris described himself when we asked what he was doing with his Zima hardware. It turned out to be a pretty accurate introduction. His setup isn't built around one polished, finished use case. There is a ZimaBoard 2 experimenting with local AI alongside Raspberry Pis. There is a ZimaBlade running as a NAS. There are two hard drives mounted inside a custom 3D-printed case. A Pi Pico drives a small status screen.

Backups run automatically. And, somewhere in the middle of all this, k3s is trying to make x86 and ARM machines cooperate. Chris summed up that part better than we could: “Barely works, but getting there.” Which is probably a familiar feeling to anyone who enjoys building things before they're completely sensible.

The NAS Had the Simple Job

Compared with the rest of Chris's homelab experiments, the NAS is fairly straightforward. A ZimaBlade connects through a SATA Y-cable to two HDDs. Chris deliberately chose hard drives rather than SSDs. At the time he built it, SSD prices made large-capacity storage difficult to justify, while he could still buy 8TB HDDs for a fraction of the cost. That timing worked out rather well. Storage prices have continued to move since then, and Chris considers himself lucky that he bought the drives when he did.

The Blade itself runs Debian rather than ZimaOS. Its job isn't especially glamorous. That's also why it works. It stores local copies of the things Chris doesn't want to lose and quietly runs his backup routine in the background.

A NAS Doesn't Have to Look Like a NAS

The enclosure is where things get much more personal. Rather than using a standard case, Chris printed his own in carbon-fibre PLA, with custom faceplates and internal mounting for the HDDs. The design is based on a desktop mini-rack model that he adapted for the build. Chris has also published the models he used on MakerWorld. That means this isn't only a build to look at. Other makers can actually inspect the design and use it as a starting point for their own projects.

The Tiny Screen Actually Has a Job

The small display on the front isn't there just because it looks good. Chris wired the screen to a Raspberry Pi Pico, which connects over USB to the ZimaBlade. The Blade reports the status of its scripted backup jobs to it. That solved a very practical problem. Once the Blade was installed inside the enclosure, its own LEDs became difficult to see. Without opening the case, Chris wanted an easy way to know whether the system was still running normally — or whether something like an authentication token had expired and caused a backup to fail.

So instead of adding a decorative screen, he built himself a little status panel. The screen has become part of the machine.

Chris is still working on a dedicated enclosure for the screen and Pico so that the whole build looks like one finished system. That's probably a good description of the project in general: working perfectly well, but never completely finished.

Quiet, Reliable, and Mostly Left Alone

Chris describes the NAS as: “reliable, quite reliable, and dead quiet.” That's important because this isn't a machine he wants to babysit. During the week, it periodically pulls down local copies of data from several places, including:

• GitHub repositories
• OneDrive
• databases used for his blogs

Then, once a week, it synchronizes around 18GB of backups to Amazon S3. So the backup path looks roughly like this:

1. Collect copies from the online sources.
2. Store the backups on the local HDDs.
3. Synchronize a weekly copy to Amazon S3.

Nothing especially dramatic happens. And that's exactly what Chris wants from this part of the homelab.

Then There's the Other Side of the Rack

The ZimaBoard 2 has a very different job. Chris initially found the Zima boards somewhat overpowered for simply acting as NAS boxes. Each of his ZimaBoard 2 systems has 16GB of RAM, which opened up more interesting possibilities. So instead of giving them another storage job, he started experimenting with local models. And then brought the Raspberry Pis into it. His current experimental cluster includes:

• ZimaBoard 2
• Raspberry Pi 5
• 3 × Raspberry Pi 4
• k3s
• Ollama

The interesting part is not simply putting several machines into a cluster. They're running different architectures. ZimaBoard 2 provides an x86 node. The Raspberry Pis provide ARM nodes. Chris uses k3s to distribute workloads between them while experimenting with appropriately sized Ollama models for the capabilities of each machine. A larger machine gets one workload. A smaller Pi gets something more suitable. At least, that's the theory.

“Barely Works, But Getting There”

Mixed architectures make the project much more interesting. They also make it more frustrating. Containers, images and workloads aren't automatically interchangeable simply because they're all part of the same cluster. And local models that make sense on a 16GB x86 machine aren't necessarily the models you'd want to throw at a Raspberry Pi. That means Chris is still figuring out what belongs where. His description of the current state was:

“Barely works, but getting there.” We decided not to improve that quote. It captures the project too well. This isn't a tutorial showing a finished production cluster where every component has already been optimized. It's an experiment. And the experiment is still happening.

Two Very Different Ideas of “Useful”

What's interesting about Chris's setup is that the two projects sit at almost opposite ends of the homelab spectrum. The ZimaBlade NAS is boring in the best possible way. It stores data. It runs backups. It tells Chris whether those backups worked. It stays quiet. The ZimaBoard 2 cluster is the opposite. It's experimental. There are different architectures involved. Models need to be sized for different machines. Things don't always work.

And sometimes making it work is the point. One machine exists because Chris wants to forget about it. The other exists because he wants something to tinker with. Both are useful. Just in very different ways.

The Hardware Doesn't Have to Decide the Use Case

Chris originally described himself as a “low-level maker/tinkerer rather than a business user.” We think that's actually the interesting part of this story. There isn't a single prescribed Zima setup here. He replaced ZimaOS with Debian where that made sense for him. He turned a Blade into a two-drive NAS. He printed his own enclosure. He added his own display. And when ZimaBoard 2 felt like more hardware than he needed for storage, he found another problem for it to solve.

Or, perhaps more accurately, another problem to experiment with. The result is a homelab that feels very much like his own. Some of it is finished. Some of it is still evolving. And some of it... barely works, but it's getting there. — Chris

From the Zima Team

There's a temptation with user stories to only show the finished projects. The clean rack. The perfectly configured cluster. The screenshot where everything is green. But that's not really how most home infrastructure gets built. Sometimes a server is already quietly doing exactly what it should. Sometimes there's a Pi Pico hanging off the front because its proper enclosure hasn't been designed yet. And sometimes you're trying to convince x86 and ARM machines to run local AI workloads together and the most accurate progress report is:

“Barely works, but getting there.” We like both kinds of projects. Thanks to Chris for showing us the finished parts — and the unfinished ones too.

FAQ

Does Chris’s NAS use ZimaOS?

No. He installed Debian and runs his own backup scripts. The enclosure and status display are also his custom work.

Does the cluster combine every machine’s memory for one model?

Chris described workload experiments across different nodes, not a demonstrated model split across their combined memory.

What does the Pi Pico screen show?

It receives backup-job status over USB so Chris can spot problems even with the board’s LEDs hidden inside the case.

Which product matches the NAS hardware family today?

The current family is ZimaBoard SE. Chris’s actual build uses an earlier unit and its own software and enclosure; current package contents differ.

Conclusion

Chris has given each side of the rack a useful purpose. The NAS keeps collecting backups and tells him when something needs attention. The cluster gives him room to keep learning. A homelab does not have to be finished everywhere to be worth building.