From a Patchwork ARM Homelab to Three x86 Servers: Julien’s Migration

Julien simplified a mixed ARM homelab by moving most services to three similar x86 hosts. He kept headless Debian, Docker, ZFS, Borg and Caddy as the foundation, then migrated each service’s data and Compose configuration before changing its reverse-proxy route. For readers facing an x86-only application or a collection of dissimilar boards, his account shows what made a platform change worthwhile.

Thank you, Julien, for sharing the migration sequence, storage layout, printed cooling parts and electricity figures—not just the finished setup. Together they show what became easier to maintain and which experiments, including Uncloud, are still ongoing.

The machines Julien purchased were ZimaBlade 7700 kits. That product family is now named ZimaBoard SE. His original model names, CasaOS-to-Debian change and photographs describe those earlier units; they are not a description of the current SE package out of the box.

A Note Before We Start

When Julien shared his homelab story with us, we asked if he would mind letting us turn it into a community post. His answer: “Of course I don’t mind sharing :)” So we’ve kept this one close to the way he told it — lightly edited and reorganized for readability, but still very much Julien’s setup, opinions, experiments, and words. Here’s how his homelab ended up moving from a collection of very different ARM boards to three ZimaBlades.

It Started With a Collection of SBCs

Over the years, I used to buy ARM SBCs depending on how my needs evolved, both professionally and personally. Most of those decisions came down to cost — not only acquisition cost, but also the cost of keeping everything running. And that is how I gradually ended up with a rather heterogeneous homelab. A couple of Raspberry Pis. Some Pine64 compute modules mounted on a blade. A few RK3588-based boards.

And other machines that had accumulated along the way. All of them running their own dedicated version of Debian, of course :)) For quite a long time, that worked perfectly well. Then two things happened. The first was software. There was a service I wanted to try that was only available for x86_64. I spent quite some time trying to build it myself for ARM, but despite my efforts, it simply refused to work the way it was supposed to.

The second was hardware. One of my SBCs died. When I started looking for replacements, I realized just how much ARM SBC pricing had changed. Once memory, storage and everything else were taken into account, some boards were getting surprisingly close to — and sometimes beyond — the price of regular desktops or even laptops. For the first time, moving the homelab toward x86 started to make sense.

But Changing Everything Is Never an Easy Decision

My first reaction was still to avoid changing platforms. Everything was already there. Everything mostly worked. And rebuilding infrastructure is rarely something you wake up excited to do. So I gave ARM one more try with another high-performance board that looked very promising on paper. The computing power certainly looked impressive. Unfortunately, for what I wanted to do, the overall experience still wasn’t quite ready. At that point, the idea of changing platforms had settled in for good.

I started looking seriously at what was available on the x86 side. And among the options I found, ZimaBlade looked like a very good compromise for what I wanted: relatively affordable, well equipped, low maintenance and not too power hungry. Eventually, my internal debate became very short: “That’s enough: Take my money!!!” So I bought my first ZimaBlade. Apparently it went reasonably well. Because I now have three. Most of my previous hosts have since been retired.

Three Hosts, Almost the Same Recipe

Today, I have three ZimaBlade 7700 kits. I deliberately keep their configurations fairly similar. As I mentioned before, I replaced CasaOS with standard headless Debian. I use SSD storage through the PCIe port for some of the host directories, including things like:

• /var
• /home
• /cache

Then I set up ZFS with mirrored HDDs where needed. The storage configuration varies depending on the job each machine is doing. One has a 512GB SSD. Another uses 2 × 2TB HDDs for cloud storage. The third uses 2 × 4TB HDDs for media and backup storage. Borg and Docker complete most of the foundation. The first ZimaBlade also acts as the entry point to my network, with Caddy handling reverse proxy duties.

The goal was never to build the biggest or most impressive homelab possible. Quite the opposite. I wanted machines that were simple enough to maintain, predictable enough to replace, and flexible enough to run almost everything I needed.

And Then, Of Course, I Had to 3D Print Something

The ZimaBlade kit itself makes assembly very easy. But leaving everything exactly as it came would have been far too reasonable :)) I designed and printed a few additional parts so I could install an 80mm fan and improve airflow underneath the board itself. For me, around 50°C is the limit I try to stay below. So cooling became another little project inside the larger homelab project.

That is probably one of the things I enjoy about this kind of hardware.

It gives you a starting point without preventing you from changing everything around it.

Moving the Services Was Less Dramatic Than Expected

Once the new hosts were ready, the actual migration process was quite straightforward. For each service, I use rsync to copy the persistent volumes from the old host to the new one. Then I check whether any images referenced by the Compose file need updating. After that: 1. Copy or clone the Compose configuration. 2. Start the service on the new host. 3. Check that everything is behaving properly. 4. Update the corresponding reverse proxy configuration in the Caddyfile.

5. Move on to the next service. Once everything is comfortably sitting in its new home, I completely clean up the old host. It is not particularly exciting. Which, when you are migrating infrastructure, is usually a very good thing. As I write this, almost all of my services have now been deployed on the ZimaBlades. I am still keeping one older host around to control my 3D printer and camera using OctoPrint and go2rtc.

Another one has become more nomadic and runs OSMC. Other than those exceptions, the migration is essentially complete.

What Runs on Julien’s Three Hosts?

Quite a lot, apparently. Some of these services support my professional work. Others are for personal use. Some solved a very specific problem. And a few probably exist because one day I looked at the project and thought: “That looks interesting.” Here are some of the more notable ones.

Infrastructure, Monitoring & Maintenance

• Termix Basic monitoring and terminal access to the hosts.
• dockcheck I use this to manage container updates.
• Caddy Caddy sits at the entry point of my network and handles reverse proxy duties.
• Gotify Notifications. Simple job, useful service.
• Borg Backup Server This replaced Borg-UI in my setup and handles backup duties.
• IT-Tools It's just always there when you need it :))

Files, Cloud & Personal Organization

• Nextcloud I run the AIO edition with quite a few apps. Among them, I particularly recommend Budget.
• Vaultwarden THE inescapable!!!
• Linkding It helps me keep my bookmarks clean and tidy. Which is no small task.
• AFFiNE The Swiss Army knife of note keeping.
• Paperless-ngx Document management. I'd also like to experiment more with its AI-related features.
• Gokapi For sending files.
• Imagor Studio I save images here before moving them to other services when needed.

Development, Design & Creative Work

• Gitea Like GitHub, of course. But better :))
• Penpot I'm not using every feature, but I particularly like the vector design tools.
• draw.io Diagramming.
• Excalidraw Drawing.
• Invoice Ninja Useful for business work, and the mobile apps are a nice extra.
• Automad A curiosity. I like the idea :))

Websites & Client Work

I also host around a dozen Hugo static websites. They are served directly by Caddy. For those sites, I use Mosparo for spam protection. There are also a couple of WordPress instances. Some of my clients simply need WordPress, so WordPress it is. There are plenty of tutorials on the internet, but I found this ServerCompass guide practical to follow.

Home, Media & Personal Projects

• Home Assistant Naturally.
• Jellyfin I use it to serve media presentations and courses to the OSMC system.
• SearXNG A metasearch engine with no nonsense.
• Gramps Web A time machine...
• SnapOtter This replaced several separate file-conversion tools I had been using. Some of its AI features also look interesting enough to experiment with.
• Hi.Events Another service living in the stack.
• Hammer Because maybe someday I'll be a writer :))
• Trek No need to go far to enjoy the journey :)) And yes, a few more services are currently being tested. They may or may not make the cut. That is part of the fun.

The Next Experiment: Distributing Services Across the Hosts

Once most of the hardware migration was finished, I started looking at another question: How could I make distributing services between the three machines easier? Lately, I've started experimenting with Uncloud. Part of the reason it caught my attention is that my setup is already built around Docker and Caddy. Docker Swarm can obviously handle distributed workloads too, but several of my existing Compose files would require fairly extensive rewriting, and a few features would be left out.

Kubernetes is extremely capable. But for a homelab like mine, it adds a lot of additional steps for relatively little benefit. I'm not running a huge datacenter. I just want the services to go where they need to go. With Uncloud, I can add the hostname inside the x-ports: section of the Compose file and let it do its magic. If I need to scale something, it is only a CLI command away.

And for people who prefer GUIs, there is a hosted dashboard as well. I'm still testing it. We will see where it goes. After all, a homelab is never really finished.

One Difference I Definitely Noticed: Power

There was another result from the migration that was much easier to measure. Electricity. With the three ZimaBlades and the network switch included, my setup now draws a little less than 200 watts. At my electricity rate, that works out to around €29 per month. Before the migration, I was paying roughly €60 per month to keep the previous setup running. Of course, those numbers are specific to my own hardware, workloads and electricity rate.

But for me, the difference matters. And the improvement is not just about electricity. The infrastructure itself is much easier to understand now. Instead of maintaining a collection of unrelated boards with different capabilities, limitations and quirks, I have three machines built around almost the same recipe. When I need to move something, I already know how. When I need to replace something, I already know what the replacement looks like.

And when I want to test something new, I spend less time wondering which architecture will actually run it. That was really the goal. Not necessarily a more powerful homelab. Just a simpler one. And, for now at least, I think I got there. — Julien

From the Zima Team

What we like about Julien’s setup isn't that three ZimaBlades ended up replacing most of his previous hosts. It's what happened after he bought them. He replaced the software stack with his own Debian setup. He changed the storage configuration. He designed and 3D printed his own cooling solution. He moved dozens of services over one by one. And now he's already experimenting with what comes next. At some point, the hardware stopped being “our setup” and became completely his.

We think that's the interesting part. Thanks to Julien for opening up his homelab and letting us share it — including the messy parts, the experiments, the projects that worked, and the ones that are still being tested. If you've built something with Zima that has gradually become completely your own, we'd love to see it too.

FAQ

Did Julien keep the supplied operating system?

No. He replaced CasaOS on his earlier 7700 kits with standard headless Debian. This is his custom installation, not the current SE default setup.

Why keep some ARM machines?

They still serve specific roles: OctoPrint and go2rtc for the printer/camera, plus OSMC on another host. The migration did not require replacing working tools without a reason.

Is the 50°C target a product specification?

No. It is Julien’s personal cooling target for his printed fan and airflow modifications.

Should another lab expect the same electricity savings?

No. His figures cover his three-host setup and switch at his electricity rate. Different hardware, loads and tariffs produce different results.

Has Uncloud fully replaced the management setup?

Julien says he has started testing it. Docker and Caddy remain central; a completed failover system is not part of his account.

Conclusion

Julien wanted a lab he could understand and maintain with less friction. Three similar hosts, a familiar Debian stack and a repeatable migration process brought him closer to that goal. The printed cooling parts and Uncloud experiments show that simpler infrastructure can still leave plenty of room to tinker.