Considering all the virtualization experiments you can run on them, home server platforms tend to require somewhat decent systems. But then you have tools like Proxmox that can run on potato hardware despite offering killer features. In fact, I’ve deployed PVE on several dinosaur machines, and it has served my needs pretty well. However, aside from an LXC-hosting decade-old laptop (and that one time I tried running a Hackintosh on an SBC), I often end up clustering low-power devices with a somewhat capable system for a high-availability setup.

So, I figured I could try a little experiment where I’d repurpose an old Intel N100 system into a standalone Proxmox rig. The device in question is my Aiffro K100 mini-PC/NAS, which has served as a node in my HA cluster up until now. Considering that the N100 is a low-end embedded processor with slow clock speeds and only four cores + four threads, I figured a few LXCs would be enough to max out the CPU resources. But after using it as a dedicated PVE workstation, I can confirm that an N100 node works as a decent primary node when you’re a fledgling home labber.

The N100 is surprisingly decent at running VMs

If anything, the mini-PC was running out of memory, not CPU cores

Having gone through the PVE installation sequence dozens of times, I’ll spare you the details of the setup process. Proxmox 9.1 barely changes anything in the initial setup wizard, and since I was using an NVMe SSD as the boot drive, my N100-based PVE system was up and running before I knew it. As is customary for every Proxmox node, I ran the PVE Post Install script by executing bash -c "$(curl -fsSL https://raw.githubusercontent.com/community-scripts/ProxmoxVE/main/tools/pve/post-pve-install.sh)" within the Shell tab of my new workstation. Since I wanted to maximize the resources at my disposal, I agreed to disable Corosync and other cluster services within the script. And with that, it was time to test the VMs.

Call me a Debian fanboy if you must, but I always stick to the king of vanilla distros for my virtualization experiments. My goal here was to gauge the responsiveness of the OS, so I picked the GUI variant – one with KDE Plasma, no less – of Debian as the ISO file for the virtual machine. Once I’d allocated 2 CPU cores and 2048MB of memory to the VM, I booted it and began installing the OS. To my surprise, Debian was pretty responsive, and the installation process completed smoothly. I also modified the Display option to SPICE within the Hardware tab, and the virtual machine felt smooth as butter. Opening a dozen tabs in Chromium didn’t introduce any latency either, and neither did running Krita, LibreOffice, Darktable, VS Code, and other essential apps.

Next, I figured I could try deploying a CLI distro and gauge the performance of the setup. Alpine Linux would’ve been my first choice, but I wanted something slightly bulkier, like Ubuntu Server. Running the two virtual machines in tandem had zero impact on performance, and the situation was the same even after I installed ZFS, Docker, Podman, and MicroCloud on Ubuntu Server.

Here’s where the fun part begins: I decided to go all out and deploy EndeavourOS in a VM – one with a single CPU core but 2048MB of RAM. Since my CPU cores were already overprovisioned, I expected a lot of stutter after running the three virtual machines simultaneously. Although the Proxmox web UI didn’t feel all that responsive anymore, I was surprised to see that the CPU utilization was still below 50%, while the RAM metrics had hit the red zone. So, my system was running into performance issues because the 8GB memory wasn’t enough to power the VMs at once, and not due to the 4-core limitation of the CPU. And that brings us to LXCs…

Thanks to LXCs, it was able to keep up with my self-hosting needs

The N100 system was able to run most of my essential containers

Unlike hardcore virtual machines, LXCs are far more lightweight and consume only a handful of resources. I tend to use my Proxmox nodes to self-host important services, so I started firing up commands from the Proxmox VE Helper-Scripts repository. Within a few minutes, Vaultwarden, Trilium Notes, Firefly III, Paperless-ngx, ConvertX, and other quality-of-life services were up and running on my PVE workstation, with the CPU and memory resources well under 50% load, even though I had my Debian VM running alongside the LXCs.

I also use Pi-hole in tandem with Nginx Proxy Manager to assign local DNS names to my services, so I deployed the two LXCs on my standalone machine. Plus, CasaOS is responsible for running certain services that aren’t available as LXCs, so I went ahead and deployed it as a container. Now that I had a robust set of LXCs (and one VM) running, I wanted a way to monitor my collection, which is where Pulse drops in. It also doubles as a dashboard UI and supports external notification servers like Gotify, which was the last LXC I wanted to deploy on this node.

You don’t need a powerful server to begin your home lab journey

After leaving my server running for a few hours, the CPU consumption stats averaged at 60%, while the RAM utilization was slightly higher at 75%. Considering that I had a full-fledged VM running alongside LXCs, I was quite surprised to see my old N100 system work this well. I don’t need every single service (especially the Debian VM) running 24/7, so a little bit of micromanagement could essentially turn this N100 system into a solid standalone Proxmox node.

Now, I probably won’t be able to run complex Home Assistant automations, GPU-heavy AI workloads, or high-resolution transcoding operations via Jellyfin on an N100 system, even with a lot of optimization wizardry. But if I had to start my home lab journey once again and didn’t have access to old PCs or server-grade hardware, I’d probably be satisfied with an Intel N100 node – at least for a couple of months before my tinkering addiction overpowers my financial management skills.