Why I Run the Home on a Small Proxmox Box
A small host keeps home services separate enough to fix without turning the house into a data centre.
All I wanted was…
to give Home Assistant somewhere sensible to live.
Then it escalated quickly.
Why it grew beyond one machine
Once Home Assistant was not the only service, one operating system started to look like a future troubleshooting session. The list grew to automation, DNS filtering, energy analysis, climate history, reverse proxying, speed checks and backup connectivity.
What runs there
A compact Proxmox host separates those responsibilities into a small set of virtual machines and unprivileged containers. The small host currently runs Home Assistant, DNS filtering, an energy dashboard, climate history, a reverse proxy, a backup-WAN component and a speed-test service.
This is not separation for its own sake. Each service has its own lifecycle, backup scope and failure boundary, but the number of moving parts is still manageable. Persistent application data stays with the application that owns it; a separate NAS is used for backups rather than guest storage.
The hardware behind it
| What the records establish | |
|---|---|
| Hardware | GMKtec NucBox G10 Pro with a Ryzen 5 3500U (4 cores / 8 threads), a Samsung 256 GB-class NVMe drive and two documented network interfaces. |
| What I paid | £102.99 for the barebones mini-PC. |
| What was reused | The listing was for a machine with no RAM or storage. Memory came from existing hardware; a second-hand Samsung PM991 256 GB NVMe drive added £24.89. |
| What it does | It is the small virtualisation host for Home Assistant, DNS filtering, energy and climate history, reverse proxying, backup-WAN support and speed testing. It runs a small group of guests rather than one monolithic home server. |
That is the project philosophy in one box: about £128 for the host and its storage, plus reused memory. Spend money where it makes a difference, reuse perfectly good hardware elsewhere. This is the cost of the compute host, not a claim about the cost of every service, backup device or network component around it.
What I checked
The design preserves guest definitions and restore order rather than reconstructing systems from memory. I checked the host, guest configuration, storage and scheduled jobs. One important limitation remains: the host has a single primary storage device and not every recovery scenario has been boot-tested.
What is still untested
The guest map is a useful snapshot, not a promise that every service is healthy at every moment. An isolated host-loss restore remains an outstanding test.
What I would keep
Virtualisation helps when it makes ownership and recovery clearer. Keep the estate small, document the restore dependencies, and do not confuse a configuration archive with proof that a service will start and work after recovery.