← Back to Blog

Why Running Home Assistant in an HA OS VM Is the Right Call

homelab
home-assistant
proxmox
self-hosting
automation

I’ve run Home Assistant every way you can run it: bare metal on a Pi, Docker container on Unraid, and now as an HA OS virtual machine on Proxmox. The VM approach wins. Not by a little — by a lot. Here’s why.

The four install methods

Home Assistant gives you four official options:

  1. HA OS — a minimal Linux distro purpose-built to run HA, installed as a full OS (bare metal or VM)
  2. HA Container — just the core app in a Docker container, no Supervisor
  3. HA Core — Python install, no Supervisor, manual dependency management
  4. HA Supervised — HA OS behavior layered on top of a general-purpose Linux install (officially supported on Debian only, fragile in practice)

Most homelab folks reach for the Docker container first because it looks familiar. That’s the wrong move for Home Assistant specifically.

What you lose without the Supervisor

The Supervisor is the layer that makes HA OS and HA Supervised special. Without it (i.e., when you run the plain Docker container), you lose:

  • Add-ons — the entire add-on ecosystem: Zigbee2MQTT, ESPHome, Node-RED, Mosquitto, Frigate, and hundreds more. These run as supervised containers managed by HA itself.
  • Native backups — HA OS has a first-class backup system that snapshots your entire config, integrations, history, and add-on data in one shot. Container installs don’t get this.
  • OS-level updates — HA OS updates the underlying OS, HA Core, and the Supervisor atomically. On a container install, you’re managing each layer yourself.
  • Hardware integration — things like the Zigbee or Z-Wave coordinator showing up reliably, Bluetooth, USB device passthrough — these are significantly smoother under HA OS.

Running the plain Docker container means you’re essentially maintaining Home Assistant with one hand tied behind your back.

Why not bare metal?

HA OS on bare metal (like a dedicated Pi or a mini PC) is perfectly functional, but it dedicates an entire machine to a single service. If you already have a Proxmox node, that’s wasteful. A VM gets you the full HA OS experience with none of the hardware commitment:

  • Snapshots before major updates — saved me twice
  • Easy migration if hardware changes
  • Resource limits and guarantees (RAM, CPU) that bare metal doesn’t give you cleanly
  • The VM lives in your backup strategy alongside everything else

The actual setup

On Proxmox, the community HAOS script makes this about a five-minute job:

Terminal window
bash -c "$(wget -qLO - https://github.com/community-scripts/ProxmoxVE/raw/main/vm/haos-vm.sh)"

This pulls the latest HA OS image, creates a VM with sane defaults, and boots it. From there it’s just the normal HA onboarding flow.

For USB passthrough (Zigbee/Z-Wave coordinator), you pass the device through in the VM hardware settings. It shows up to HA exactly as it would on bare metal.

What about HA Supervised on Docker?

This is the worst of both worlds in practice. It runs the Supervisor on top of a general-purpose Linux install, but Supervisor has very specific expectations about the OS environment. The official supported path is Debian with specific package versions. Any drift from that — a kernel update, a package version mismatch — can cause Supervisor to flag your install as “unsupported,” which disables certain features and makes updates unreliable. Avoid it unless you have a very specific reason.

The verdict

If you have a Proxmox node: run HA OS as a VM. No question. If you don’t have a hypervisor: run HA OS on dedicated hardware. Container is only the right answer if you have a hard requirement to not use a hypervisor and have no dedicated hardware — and even then, understand what you’re trading away.

The add-on ecosystem alone is reason enough. Once you’ve got ESPHome, Zigbee2MQTT, and Frigate all managed from inside HA with zero manual container juggling, you won’t want to go back.