Do I need Supervisor, and does that mean HAOS?

Supervisor is the add-on management layer that gives you the Add-on Store, one-click backups, and the ability to install things like ESPHome or a Zigbee2MQTT add-on without touching Docker yourself. Supervisor runs on Home Assistant OS, not on the plain Container install. Home Assistant Supervised also had it, but Supervised and Core were deprecated in 2025 and support ended with release 2025.12, so for a new install HAOS is the way to get add-ons.

Why a VM instead of Home Assistant Container on Docker?

Container is lighter and fine if you only need integrations, but you give up Supervisor and the Add-on Store, and USB passthrough for a Zigbee or Z-Wave stick has to go through Docker's device mapping instead of Proxmox's own USB hardware controls. HAOS as a VM gets you Supervisor, a known-good upgrade path straight from Home Assistant's own release process, and USB passthrough that's a Proxmox-native feature instead of a container workaround. The tradeoff is a few extra minutes of RAM and disk overhead for a full VM, which an N100 box with 16GB has to spare.

How much RAM and CPU does HAOS actually need?

Home Assistant's own documentation lists 32GB of storage and 2GB of RAM as the minimum for HAOS, with more recommended once you add the Recorder database, several integrations, and any heavier add-ons like a voice assistant pipeline. Budget 2 vCPU and 4GB of RAM for the VM on a mini PC that also runs other guests, and give the virtual disk at least 32GB so updates and snapshots have room.

Can I run Frigate or a voice assistant on the same VM?

Frigate's object detection is the add-on most likely to need more than this VM's baseline sizing, especially with multiple camera streams. If you're planning for that from the start, size the VM up front rather than migrating later, and consider a dedicated detector like a Coral TPU, which still needs USB passthrough into the VM the same way a Zigbee stick does.

Is Nabu Casa worth it over a reverse proxy?

Nabu Casa is Home Assistant's own cloud service: a subscription that gives you remote access and Google/Alexa integration with no port forwarding and no certificate management. A reverse proxy is free beyond what you already run but means you're the one responsible for keeping it patched and exposed correctly. Tailscale sits in between: no exposure to the open internet at all, free for personal use, but your phone needs the Tailscale app running to reach your home network. None of these is wrong. Pick based on how much ongoing maintenance you want.

Home Assistant on Proxmox: HAOS VM Setup

This post contains affiliate links. If you buy through them, I earn a small commission at no extra cost to you.

If you read the mini PC buying guide for Home Assistant and already own the hardware, this is the part that guide doesn’t cover: actually getting Home Assistant OS running on it. The short version is that HAOS belongs in a Proxmox VM, not a Docker container and not bare metal, and this guide walks the whole path from a blank VM to a working install with a Zigbee or Z-Wave stick passed through.

If you haven’t decided VM vs. LXC in general, Proxmox VM vs LXC covers the broader decision. HAOS is a specific case of that decision with only one right answer, which the next section explains. If Proxmox itself is new to you, start with the beginner’s guide first; this one assumes you already have a Proxmox host up and a VM or two running on it.

Quick Answer

Download the Proxmox-specific HAOS qcow2 image, create an empty UEFI VM (OVMF firmware, q35 machine type, EFI disk), import the qcow2 as its disk, set CPU type to host, and boot it. Home Assistant requires UEFI to boot, so a VM left on the default SeaBIOS will sit at a blank console. Pass a Zigbee or Z-Wave USB stick in by vendor:product ID so it survives reboots.

# on the Proxmox host
# check the current HAOS release number first (18.3 at time of writing)
VER=18.3
wget https://github.com/home-assistant/operating-system/releases/download/${VER}/haos_ova-${VER}.qcow2.xz
unxz haos_ova-${VER}.qcow2.xz

qm create 900 --name haos --memory 4096 --cores 2 --net0 virtio,bridge=vmbr0 \
  --bios ovmf --machine q35 --efidisk0 local-lvm:1,efitype=4m,pre-enrolled-keys=0
qm importdisk 900 haos_ova-${VER}.qcow2 local-lvm
# the EFI disk took vm-900-disk-0, so the imported image is vm-900-disk-1
qm set 900 --scsihw virtio-scsi-pci --scsi0 local-lvm:vm-900-disk-1
qm set 900 --boot order=scsi0
qm set 900 --cpu host
qm start 900

Give it a few minutes, then open https://<vm-ip>:8123 to start onboarding. The rest of this guide covers the sizing decisions, the USB stick, networking, backups, and remote access, which is most of the actual work.

Why HAOS as a VM, Not Docker, Not Bare Metal

Home Assistant has four install methods, two of which are deprecated, and they are not interchangeable once you want add-ons.

Method	Gets you Supervisor / Add-on Store	Runs on	Best for
Home Assistant OS (HAOS)	Yes	A dedicated VM or appliance (Green, Yellow, Pi)	Most homelab installs. Full add-on support, managed updates.
Home Assistant Container	No	Any Docker host, alongside other containers	Advanced users who only need integrations, not add-ons.
Home Assistant Core	No	A Python venv you manage	Deprecated. Support ended with release 2025.12. Do not start a new install here.
Home Assistant Supervised	Yes	A specific supported Debian install	Deprecated. Support ended with release 2025.12. Do not start a new install here.

The honest version: if you want the Add-on Store, one-click backups, and the upgrade path Home Assistant actually tests against, you want Supervisor, and HAOS is now the supported way to get it. Home Assistant deprecated the Core and Supervised install methods in 2025 and support for both ended with release 2025.12, so neither is a sensible choice for a new homelab install. Container is genuinely fine if all you want is sensors and automations through integrations, but the first time you want a Zigbee2MQTT add-on or ESPHome’s add-on instead of its standalone container, you’ll wish you’d started with HAOS.

Running HAOS as a Proxmox VM rather than on dedicated appliance hardware (Home Assistant Green, Yellow, or a Raspberry Pi) means it shares the mini PC you already run other services on, backs up with the rest of your Proxmox guests, and gets the same snapshot safety net everything else does. The cost is giving the VM its own RAM and vCPU allocation instead of sharing a host kernel the way an LXC would, which is the next thing to get right.

What You Need

A Proxmox host with a VM slot to spare, running on the N100-class mini PC covered in the buying guide or similar.
At minimum, Home Assistant’s own documented requirements of 32GB storage and 2GB RAM for HAOS. In practice, budget 2 vCPU, 4GB RAM, and a 32GB virtual disk if the box has room, since the Recorder database and a handful of integrations use more than the bare minimum fast.
A USB Zigbee or Z-Wave stick if you’re bringing your own sensors over. A Sonoff Zigbee 3.0 USB dongle covers Zigbee; a Zooz 800LR stick covers Z-Wave. A short USB extension cable keeps either one away from the mini PC’s own RF noise, which matters more than people expect.
Some patience for the USB passthrough step, which is where most first-timers lose the most time if they’ve never done Proxmox USB passthrough before.

Step 1: Size the VM Before You Create It

Before touching the Proxmox UI, decide what else this mini PC is already running. HAOS doesn’t need much on its own, but “doesn’t need much” is a different number from “doesn’t need much after six months of integrations, a few automations with history graphs, and a voice assistant pipeline you added on a whim.”

A reasonable starting allocation on a 16GB N100 box that’s already running a Docker VM and a couple of LXC containers:

2 vCPU. HAOS is not CPU-hungry at idle, but automations, template sensors, and anything running computer vision (Frigate, if you add it later) will use what you give it.
4GB RAM. The documented minimum is 2GB, but the Recorder database and a normal integration count push past that quickly. Giving it 4GB up front avoids a resize later.
32GB disk. This is the stated minimum. Snapshots and update images need slack, so don’t shave this down.

If you’re planning to run Frigate for camera object detection on the same install, size up before you start rather than after; Frigate’s detector workload is the thing most likely to make this VM’s baseline numbers look optimistic in hindsight.

Step 2: Download the HAOS Image

Get the Proxmox-specific qcow2 image from Home Assistant’s own operating-system releases page, not a generic cloud image or the Raspberry Pi image. The filename pattern is haos_ova-<version>.qcow2.xz.

cd /var/lib/vz/template/iso
VER=18.3
wget https://github.com/home-assistant/operating-system/releases/download/${VER}/haos_ova-${VER}.qcow2.xz
unxz haos_ova-${VER}.qcow2.xz

18.3 is the current stable release at the time of writing. Check the releases page for the current version number and change VER before running this; HAOS ships new point releases often enough that a hardcoded version in a guide goes stale.

Step 3: Create the VM Shell

Create the VM without attaching an OS, since you’re importing the disk image instead of installing anything through a normal OS installer.

In the Proxmox web UI: Create VM, then on the OS tab select Do not use any media. Set:

System tab, BIOS: OVMF (UEFI). Home Assistant requires UEFI to boot, and the Proxmox default is SeaBIOS.
System tab, Machine: q35
System tab, EFI disk: leave Add EFI Disk checked, pick your storage (typically local-lvm), and uncheck Pre-Enroll keys so Secure Boot stays off
CPU: 2 cores, type host (the backend default is kvm64 and the web UI pre-selects x86-64-v2-AES; host passes the real CPU model through to the guest)
Memory: 4096 MB
Network: your usual bridge, typically vmbr0
Disks: delete the default scsi0 disk on the Disks tab. The disk comes from the imported image in the next step.

Or the same thing from the CLI, which is easier to get consistent across more than one install:

qm create 900 --name haos --memory 4096 --cores 2 --cpu host --net0 virtio,bridge=vmbr0 \
  --bios ovmf --machine q35 --efidisk0 local-lvm:1,efitype=4m,pre-enrolled-keys=0

900 is just a free VM ID on your node; use whatever’s open.

Step 4: Import the Disk

This is the step that differs from a normal VM build. Instead of booting an installer, you attach the qcow2 you downloaded as the VM’s disk directly:

qm importdisk 900 haos_ova-${VER}.qcow2 local-lvm

Run it from the folder where you unpacked the image, with the same VER set. The command prints the new volume ID when it finishes. Because the EFI disk from Step 3 already took vm-900-disk-0, the imported image comes in as vm-900-disk-1. Confirm with qm config 900, where it shows up as an unused0 line. If yours says something different, use the volume ID that your own output shows.

Now wire it up as the actual boot disk:

qm set 900 --scsihw virtio-scsi-pci --scsi0 local-lvm:vm-900-disk-1
qm set 900 --boot order=scsi0

local-lvm is the default storage name on most Proxmox installs; substitute your own storage ID if you’ve renamed it or you’re using something else, like a ZFS pool.

Step 5: Boot It and Reach Onboarding

Start the VM:

qm start 900

Give it a few minutes on first boot. HAOS resizes its filesystem and sets up its own internal supervisor layer before the web UI is reachable. Open a browser to:

https://<vm-ip>:8123

You can find the VM’s IP from the Proxmox console if you attach a display, or from your router’s DHCP client list if you don’t. The onboarding wizard walks you through creating an admin account and naming your home. Skip location and currency details you don’t care about; they’re editable later.

Step 6: Pass Through a Zigbee or Z-Wave Stick

This is the step people actually get stuck on, because it’s easy to pass the stick in by USB port instead of by device ID, and then watch it break the next time you plug something else into the mini PC.

On the Proxmox host, with the stick plugged in, find its vendor and product ID:

lsusb

Look for a line like:

Bus 001 Device 004: ID 10c4:ea60 Silicon Labs CP210x UART Bridge

10c4:ea60 is the vendor:product pair. Add the device to the VM by that ID, not by bus/port position, through the web UI: select the VM, Hardware → Add → USB Device, choose Use USB Vendor/Device ID, and enter the pair.

Or from the CLI:

qm set 900 -usb0 host=10c4:ea60

Reboot the VM once for the device to attach cleanly. Confirm it’s visible from inside HAOS under Settings → System → Hardware, or SSH in (if you’ve enabled the Advanced SSH add-on) and check lsusb from inside the VM itself.

The full version of USB passthrough, including the LXC config-file method for when you’re not using a VM, is covered in the Proxmox USB passthrough guide. The vendor:product method above is the part that matters for HAOS specifically.

Step 7: Set a Static IP

An address that can drift is a problem the moment you’ve pointed a dashboard, an automation, or a reverse proxy host at it. Two ways to fix it, either is fine:

From inside HAOS: Settings → System → Network, switch from DHCP to static, and assign an address outside your router’s DHCP pool, like 192.168.1.50.

From your router, as a DHCP reservation: find the VM’s MAC address (visible in the Proxmox VM’s Hardware tab under the network device) and reserve an address for it. This keeps HAOS on DHCP while guaranteeing the address never changes, which is usually the less fragile option since it survives a HAOS reinstall.

Step 8: Backups

HAOS has its own backup system built in, separate from Proxmox’s VM-level snapshots, and you want both.

HAOS’s own backups (Settings → System → Backups) capture the Home Assistant configuration, the add-on configs, and optionally the Recorder database, in a format that restores cleanly to a fresh HAOS install. Schedule automatic backups and, if you’re not already shipping them somewhere else, set up the Google Drive or local network backup location in the same screen so a dead VM doesn’t also mean a dead backup.

Proxmox-level snapshots or full VM backups capture the entire VM, disk and all, which is faster to restore from if the VM itself is the thing that broke rather than just the HA configuration inside it. The Proxmox Snapshots and Backups guide covers scheduling this for any VM on your host, HAOS included.

Run both. HAOS’s own backup protects your automations and configuration; Proxmox’s protects the VM you’d otherwise have to rebuild from Step 3 onward.

Step 9: Remote Access, Honestly

You’ll want to reach Home Assistant from outside your network eventually, and there isn’t one objectively correct way to do it. Three real options:

Method	Cost	What you manage	Caveat
Nabu Casa	Subscription (Home Assistant’s own cloud service)	Nothing; no port forwarding, no cert management	You’re trusting a third-party relay for remote traffic
Reverse proxy (NPM, etc.)	Free	TLS cert renewal, keeping the proxy patched, port forwarding	A misconfigured proxy is now an internet-facing attack surface
Tailscale	Free for personal use	A VPN client on every device you want remote access from	No open ports at all, but your phone needs the Tailscale app connected to reach home

Nabu Casa is the Home Assistant project’s own answer to this, and it’s the one to pick if you’d rather not be the one responsible for a certificate expiring or a proxy misconfiguration being reachable from the internet. If you already run a reverse proxy for other services, the Nginx Proxy Manager setup guide covers adding a new proxy host, which is the same process for HAOS as for anything else in your homelab, port 8123 instead of whatever else you’re forwarding. Tailscale sits in the middle: no exposure at all, but it means remembering to have Tailscale running on your phone before you try to adjust a thermostat from out of town.

Don’t expose port 8123 directly to the internet without one of the three methods above in front of it. None of them, including the reverse proxy option, is “set it up once and never think about it again.” Pick based on how much ongoing maintenance you’re willing to own.

What Usually Goes Wrong

Symptom	Likely Cause
VM won’t boot, stuck at a blank console	Firmware left on the default SeaBIOS. HAOS requires UEFI: set BIOS to OVMF, machine to q35, add an EFI disk with Pre-Enroll keys off (Step 3). A wrong boot order (Step 4) is the other usual cause.
USB stick disappears after a reboot	Passed through by port instead of vendor:product ID
Onboarding never loads at `:8123`	Still mid-first-boot filesystem resize; wait another minute before assuming it’s broken
Zigbee stick visible to the host but not inside HAOS	VM needs a restart after the `qm set -usb0` command for the device to attach
Address changes and automations referencing it silently stop	No static IP or DHCP reservation set; see Step 7
Remote access works at home, not away from home	Reverse proxy not actually reachable from the internet (port forward missing), or Tailscale not connected on the remote device

Where This Goes Next

Once HAOS is running and the stick is paired, the usual next steps are adding integrations for whatever’s already in the house, building a dashboard, and writing the first few automations, none of which are Proxmox concerns anymore. If you want push notifications for things outside Home Assistant’s own mobile app, like a VM running low on disk or a backup job that failed, the ntfy guide and the homelab email notifications setup both pair well with a HAOS install that’s now one more thing on your network worth monitoring.

The honest tradeoff of this whole approach: a dedicated Home Assistant Green or Yellow would have skipped the VM sizing and USB passthrough steps above. What you get instead is a Home Assistant install that lives alongside everything else your mini PC already runs, backs up the same way, and didn’t cost anything beyond the hardware you already bought for other reasons.