Home Assistant

Home Assistant deserves a page of its own rather than a mention inside First Services, because it isn't really a single service the way Pi-hole or Jellyfin is - it's an entire ecosystem (integrations, automations, a supervisor-managed add-on store) that some homelabbers end up building their whole setup around. This page is about where it fits into this guide, not a full Home Assistant tutorial.

Three ways to run it, and what each gives up

• Home Assistant OS (HAOS) - a full appliance OS, meant to run on bare metal or as a dedicated VM, that includes the Supervisor: Home Assistant's own add-on manager, giving you one-click installs for things like ESPHome, a MQTT broker, or Node-RED without managing separate containers yourself. This is the "full" experience most Home Assistant tutorials assume.
• Home Assistant Container - just Home Assistant Core, running as a plain Docker container alongside your other services. No Supervisor, no add-on store - you run anything extra (MQTT, etc.) as its own separate container yourself. Fits naturally into the Docker-Compose-everything approach the rest of this guide uses.
• Home Assistant Core (bare Python) - the underlying application with no packaging at all. Not recommended for a homelab; you gain nothing over the container image and take on manual dependency management.

Recommendation: run HAOS in a dedicated VM if you're committing to Home Assistant as a serious part of your smart home (you'll want the Supervisor and add-on ecosystem eventually); run it as a plain container if you mainly want core automation and don't mind managing any extras yourself. Either is a legitimate choice - this is one of the few places in this guide where "it depends on how deep you're going" is a real, not a hedging, answer.

Why HAOS wants a VM, not an LXC container

HAOS expects to manage its own OS-level updates and, often, direct USB device access for a Zigbee or Z-Wave radio dongle. A VM (see Proxmox VMs and Containers) gives it that full-machine expectation cleanly, including straightforward USB passthrough for the radio dongle. LXC can be made to work with enough manual passthrough configuration, but it fights the tool rather than working with it - not worth the friction for what you save in resource overhead.

Resource expectations: HAOS is comfortable in a VM with 2 vCPU and 2-4GB RAM for a typical household's worth of integrations and automations; budget more RAM if you add heavier add-ons like a local voice assistant or a media library indexer.

Network placement

Home Assistant integrates with a large number of IoT devices, many of which are themselves poorly secured or receive infrequent updates from their manufacturers. Put it - and the devices it talks to - on a dedicated or trusted VLAN per Network Segmentation, rather than flat on your main network, so a compromised smart bulb's blast radius doesn't extend to your NAS or your password manager.

⚠️ Risk: do not port-forward Home Assistant to the internet directly. It controls physical devices in your home - locks, cameras, garage doors in some setups - which makes it a meaningfully worse target to expose than a media server. Use the VPN approach from Remote Access for access away from home; Home Assistant's own optional cloud remote access (Nabu Casa) is a paid, officially-supported alternative if you want zero-config remote access without running your own VPN.

Storage and backups

Home Assistant's recorder database (which logs entity state history for graphs and automations) can grow substantially over time - consider capping its retention period in Home Assistant's own settings rather than letting it grow unbounded. Back up its config/database the same way you back up everything else in this tier - see Proxmox Backups if it's a VM, and consider a ZFS snapshot (see Storage and ZFS) immediately before any Home Assistant version upgrade, since add-on and core upgrades occasionally require a rollback.

Next: Monitoring and Alerting.