I've run a ZimaBlade as my main home server for a few months now. It does photos (Immich), single sign-on, the reverse proxy, monitoring, CrowdSec and a Cloudflare tunnel. I like it. But it's a small board and it has proper limits, and most of them I found the hard way.
I already wrote up how I set it up as a server rather than an appliance and the saga of the Quadro P600 in it. This one is the list I wish I'd had before buying.
1. Power comes in over USB-C, and there isn't much of it
The stock power brick is 12 V / 3 A, so 36 W, over USB-C. Kits since late 2025 come with a 60 W one. The board, RAM and two SATA drives already sit around 25-30 W, so there is no headroom for anything else.
I got this wrong in my own repo at first. I'd written instructions about a barrel jack. There is no barrel jack, it's USB-C. Fixed now, but if you're planning to power a riser or a GPU off the same supply, don't. Anything hungry needs its own PSU.
2. The PCIe slot is small in every direction
What the slot actually reports:
- PCIe 2.0 x4, so about 2 GB/s at best
- a 25 W slot power limit, so a 40 W card can't run off it directly
- no hot-plug: a card only gets found at a cold boot, rescanning does nothing
- no Above 4G decoding: the biggest PCI window is about 1.25 GB, fine for a 2 GB card, probably a wall for anything with big VRAM
So "stick a GPU in it" really means a riser, an external PSU and a small, old card.
3. Two power supplies, two grounds, one very confused GPU
My riser setup ran the Zima off its own unearthed brick and the GPU off an earthed ATX PSU. Two ground domains, joined only by the thin grounds in the riser's cable. The fan spun, so I assumed power was fine. The PCIe link never trained at all.
After a lot of physical faff in the loft it did enumerate. Then it ran for about 8.5 hours and dropped off:
The link had also dropped itself to PCIe 1.0 x1. These days a small watcher script records how long the card survives each boot and only shouts when it changes state, rather than every 15 minutes. The full story's in the P600 post.
4. The OS is read-only and you don't get sudo
ZimaOS is immutable. / is a read-only squashfs that always shows 100% full. That's by design, it's not a full disk, but it scared me the first time.
The one SSH user can run Docker without sudo, but sudo itself wants a password I don't have. So editing anything root-owned (a systemd unit, /etc/exports) means borrowing root through a privileged container:
docker run --rm --privileged --pid=host -v /:/host alpine \
chroot /host systemctl status some-unit
If that looks dodgy, it is a bit. But being in the docker group already means being root in all but name, so it's not adding a hole, it's just honest about the one that's there.
5. The app store deleted my dashboard. Twice.
I ran Homepage as a CasaOS app. In July it vanished: container gone, config still on disk. I reinstalled it from the leftover compose file. In September it vanished again, and this time the compose file had gone too.
Now it's a plain docker run with --restart unless-stopped, and CasaOS has no say in whether it lives. Same for Uptime Kuma when I moved it onto the Zima. Anything I care about stays out of the app store.
Related trap: back in July five of my containers had restart=no. CasaOS starts them at boot, so it looked fine, but a container that crashed mid-life just stayed dead. One sat dead for six days before I noticed. I switched them all to unless-stopped then. When I checked again for this post, 8 of the 16 running were on restart=no again, so it's a check worth repeating.
6. 17 GB of eMMC fills up fast
The fast storage is a 29 GB eMMC, with a 17 GB /DATA partition. The two big drives are a separate 5.5 TB array.
12 GB used and 4.7 GB free. The biggest things on it are a 5.2 GB swap file and 3 GB of OS update files. Docker's 12.5 GB of images (5.4 GB of that is old images I could prune) actually sit on the array. Rule I follow now: anything big or cold goes on the array, never /DATA. I also share a "coldstore" folder off the array to my Proxmox boxes over NFS, mounted with nofail and automount so a Zima outage can never stop them booting.
7. It can't watch itself
Uptime Kuma runs on the Zima. Which means when the Zima dies, the thing that's meant to tell me is dead too. So a script on a different box checks Kuma every 5 minutes and restarts the container over SSH if it's gone. I tested it by stopping Kuma, it was back in seconds.
So would I buy one again?
Yeah, for what it is. Two real SATA ports, 16 GB of RAM and an x86 CPU that runs every Docker image without thinking about ARM builds is a lot in a box that size. But it's a 2016-era dual-core Celeron with a weedy PCIe slot and a USB-C power brick, and you have to work around that rather than pretend it's a NAS appliance. Next post is what 16 containers actually cost it.
What's the limit that bit you on your homelab box?
🤖 Drafted with AI assistance from my own homelab notes, logs and repos, then reviewed and edited before publishing.
Top comments (0)