The catch is that Home Assistant has more setup decisions up front than most self-hosted apps - install method, radio hardware, network layout - and getting those wrong early costs you a migration later. Here’s how to make each call once.

Pick the right install method the first time

Home Assistant ships in four different forms, and they are not interchangeable later without real work:

• Home Assistant OS (HAOS) - a full, purpose-built operating system image. This is what most guides assume. It gets you the Supervisor, which is what runs add-ons (Zigbee2MQTT, Mosquitto, ESPHome dashboard, Node-RED, and hundreds more) as managed containers with a one-click install UI, plus one-click OS updates and built-in backup/restore. Run this as a VM on Proxmox, not an LXC - HAOS expects to own the whole machine, manage its own updates, and in some setups wants direct USB access that’s simpler to grant to a VM than to fight through container confinement for.
• Home Assistant Container - just Home Assistant Core in a single Docker image, no Supervisor, no add-ons, no built-in backup UI. You run everything else (Zigbee2MQTT, MQTT broker, etc.) as separate containers you manage yourself in your existing Compose stack. This is the right call if you want Home Assistant to live alongside your other self-hosted apps under one docker-compose.yml and don’t want a second OS to patch.
• Home Assistant Supervised - Supervisor and add-ons, but installed onto a generic Linux OS you already run, instead of HAOS owning the machine. Technically possible, officially discouraged, and the thing most likely to break on a routine apt upgrade. Skip it unless you have a specific reason HAOS-as-a-VM won’t work for you.
• Home Assistant Core - the bare Python application, for people building something custom. Not what you want for a normal homelab setup.

For most homelab setups, the honest recommendation is HAOS as a dedicated VM. The add-on ecosystem is genuinely most of Home Assistant’s value once you’re past the basics, and Container mode means manually wiring up and maintaining every one of those pieces yourself in Compose. Give the VM 2-4 vCPU, 4GB RAM, and a real disk (not thin-provisioned on already-tight storage) - Home Assistant’s own database grows steadily from state history, and a slow disk shows up as UI lag over time.

The radio hardware decision

Most of what makes Home Assistant worth running is local-protocol devices - Zigbee and Z-Wave - not the cloud-integrated Wi-Fi gadgets that already work fine with their own apps. To talk to those, you need a radio adapter:

• Zigbee: a USB coordinator like a Sonoff Zigbee 3.0 dongle (with the recommended firmware) or a Home Assistant SkyConnect/Connect ZBT-1. Home Assistant’s built-in ZHA integration handles Zigbee directly with no extra add-on. Zigbee2MQTT is the alternative - it needs its own MQTT broker (Mosquitto, trivially added as an HAOS add-on or another container) but has broader device compatibility and better diagnostics for oddball hardware. If you’re starting fresh with mainstream devices, ZHA is simpler. If you already know you’re buying budget or unusual Zigbee gear, Zigbee2MQTT will save you frustration later.
• Z-Wave: a USB stick like a Zooz 800 series or Aeotec Z-Stick, handled by the built-in Z-Wave JS integration. Z-Wave devices tend to cost more than Zigbee equivalents but mesh more reliably in RF-noisy homes, since it runs on a different frequency band than Wi-Fi and Zigbee both share.
• Matter/Thread: the newer cross-vendor standard, increasingly built into new device releases. Home Assistant supports it, and a Thread border router (several Zigbee/Thread combo dongles now do both) is worth having if you’re buying new gear going forward, but don’t treat it as a reason to wait - Zigbee and Z-Wave devices aren’t going anywhere and the ecosystem for them is far larger today.

Whichever coordinator you pick, if it’s on a VM, pass the USB device through directly (qm set <vmid> -usb0 host=<vendor>:<product>) rather than trying to share it - Zigbee and Z-Wave coordinators don’t tolerate being shared between the hypervisor and the guest.

The network gotcha nobody mentions until it bites

A meaningful chunk of Home Assistant’s device discovery (HomeKit integration, some Wi-Fi device auto-discovery, Google Cast) relies on mDNS/multicast traffic. If your VLAN setup segments the Home Assistant VM away from the VLAN your smart devices actually sit on - which is a genuinely good security practice, keeping IoT gear off your main network - discovery breaks unless multicast is explicitly allowed to cross that boundary. Most routers/switches don’t route multicast between VLANs by default. Two real fixes: run an mDNS reflector/repeater (Avahi with reflection enabled, or a dedicated tool like mdns-repeater) between the VLANs, or accept manual IP-based configuration for cross-VLAN integrations instead of relying on auto-discovery. Don’t discover this the hard way after wondering for an hour why a device “isn’t showing up” when it’s actually working fine, just invisible to discovery.

Set it up, then don’t chase every integration on day one

Onboarding creates your admin account and walks you into device/area setup. Resist the urge to connect every cloud integration Home Assistant offers just because it’s available - each one is a dependency on a third party’s API staying stable and free, which is exactly the thing you started self-hosting to get away from. Prioritize local-only integrations (Zigbee/Z-Wave devices, ESPHome nodes, local network cameras via RTSP or ONVIF) and treat cloud integrations as an exception you add deliberately, not a default.

Automations follow the same trigger-condition-action shape everywhere in Home Assistant: something happens (trigger), an optional check passes (condition), and something runs in response (action). The visual automation editor covers the large majority of real homelab automations - motion turns on a light, a door sensor left open for 10 minutes sends a notification, sunset dims things down. Drop into YAML mode only when you hit something the UI genuinely can’t express; most people never need to. Blueprints - shareable automation templates from the community - are worth checking before building something from scratch, since a lot of “turn on this light when that sensor trips, but only after dark and not when I’m away” logic has already been solved and shared.

Back it up like the rest of your homelab, not as an afterthought

HAOS has a built-in backup feature that snapshots the full configuration, including the database, add-ons, and their data. The mistake is leaving those backups sitting only on the same VM they’re backing up - if that disk or VM dies, the backups die with it. Configure automatic backups (the built-in Backup integration can run on a schedule) and make sure the resulting archive lands somewhere off that VM: a Proxmox Backup Server job on the VM itself covers the whole-VM case, and separately pulling the HA-native backup file to your existing backup target covers a config-only restore without rebuilding the VM from scratch. Both are worth having, because they solve different failure modes.

Remote access: don’t just port-forward it

If you want to control your house from outside your home network, the honest options are the same tradeoff every self-hosted app on this site runs into: expose it directly and accept the risk, or don’t expose it directly at all. For Home Assistant specifically, direct exposure means a login screen for something that controls your locks and cameras sitting on the open internet, which is a worse bet than almost anything else you’d self-host. Put it behind a VPN (WireGuard or Tailscale, covered elsewhere on this site) instead, so remote access requires being on your network first. If you want managed remote access without running the VPN yourself, Nabu Casa’s official Home Assistant Cloud subscription funds the project directly and handles the exposure problem for you at a reasonable monthly cost, which is a legitimate choice, not a cop-out, for anyone who’d rather not own that risk.

Start small: one radio coordinator, a handful of devices you actually use daily, and two or three automations that solve a real annoyance. The add-on ecosystem and integration list are enormous, and trying to wire up all of it in the first weekend is the most common way people burn out on Home Assistant before it’s had a chance to prove itself useful.