Comparing Home Assistant deployment methods in Proxmox

I moved Home Assistant onto Proxmox and ended up weighing two choices: LXC or a full VM. Both run the same smarthome stack, but they behave differently once you start adding hardware and updates into the mix.

LXC looks neat because it is light on resources. Containers start quickly and use less memory. For a plain Home Assistant Container setup, that can work well enough. The problem starts when you want Supervisor support and the official add-ons. Those expect a full Home Assistant Operating System environment. Inside LXC, that usually means a privileged container, extra kernel fiddling, and a fair chance of something breaking after an update. Home Assistant has also marked Supervised installs as deprecated, so that route looks shakier than it did a while back (Home Assistant installation methods, deprecation notice).

A VM is the dull but reliable option. It gives you the full Home Assistant OS setup, keeps the stack isolated, and makes add-ons and the Supervisor behave the way upstream expects. USB passthrough is simpler too. If you are using a Zigbee or Z-Wave stick, pass it through to the VM and the OS sees it like a physical machine. The price is some extra CPU, RAM, and storage for backups, but that is usually easier to live with than a pile of odd LXC workarounds.

I used virtio for disk and network where I could. I set a fixed MAC address and reserved the VM’s IP in my router or DHCP server so integrations did not start chasing a moving target. For USB dongles, I passed the host device straight through to the VM rather than proxying serial ports, then checked dmesg inside the VM to confirm it had appeared. If you do try LXC and need Supervisor, a clean, minimal Debian host is the least painful starting point, but the supervised route has less official support now. I also kept the Home Assistant configuration in git outside the VM image, which made it easier to inspect changes and roll back a bad edit without restoring the whole thing.

Testing is the bit people skip and then regret later. Before turning automations back on, I ran them in a test mode or disabled the triggers. I checked that integrations came up in the UI and read the logs for errors. Before any major update, I took a Proxmox snapshot and an exported Home Assistant backup. I also did a restore test on a spare VM or local machine so I knew the process worked end to end. After the migration, I watched CPU, memory, and disk I/O for a week. If automations started stuttering, I gave the VM more resources or moved heavier integrations elsewhere.

The short version: pick a VM if you want the full Home Assistant OS experience and less grief with hardware passthrough. Use LXC only if you care more about a small footprint than supportability. Keep Proxmox snapshots, keep a git-tracked configuration, and test restores before you need them. That kept my setup stable, which is about as much as you can ask for from home automation.

Related posts

Vector | vdev-v0.3.3

Vector vdev v0 3 3: patch release with crash, leak and parsing fixes, connector and tooling improvements, upgrade notes on prechecks, rolling updates, compat

Loki | v3.7.2

Loki v3 7 2: security and CVE fixes, updated S3 client to aws sdk v1 97 3, ruler panic fix for unset validation scheme, S3 Object Lock sends SHA256 checksum

Loki | v3.7.2

Loki v3 7 2: Patch release with CVE fixes, AWS S3 SDK update, ruler panic fix, S3 Object Lock SHA256 checksum support