Home Assistant

Last reviewed Aug 22, 2026 · 724 words

Pick Home Assistant OS on a dedicated box unless you can say precisely why you need something else. That one decision prevents most first-year pain: OS installs get one-click updates, add-ons, and automatic snapshots, while the bare Docker container — tempting if you already run a compose stack — silently gives up the add-on store and the supervisor. The people happiest with Container installs are the ones who already know they want to run Zigbee2MQTT and Node-RED as separate services anyway.

The install-method decision, honestly

Hardware: a Raspberry Pi 4 with an SSD (not an SD card — the database will kill it in a year) runs a serious setup. A used mini PC gives headroom for camera streams and voice. The catalogue's 1 GB RAM minimum is real but 4 GB is comfortable. My month-by-month notes from a fresh start are in Home Assistant: the first month.

If devices aren't discovered, it's the network mode

Home Assistant finds most devices with mDNS and SSDP broadcasts, and those do not cross Docker's default bridge network. If you run the container yourself, network_mode: host is not optional:

services:
  homeassistant:
    image: ghcr.io/home-assistant/home-assistant:stable
    network_mode: host
    volumes:
      - ./config:/config
      - /etc/localtime:/etc/localtime:ro
    restart: unless-stopped

Zigbee and Z-Wave USB sticks need a devices: passthrough too, and one placement tip beats any software: put the stick on a short USB-extension cable away from the server's USB 3 ports, whose radio interference is a famous cause of "my Zigbee network is flaky."

Local-first is the point — buy accordingly

The reason to run Home Assistant is that automations execute on your hardware in milliseconds and keep working when your internet or a vendor's cloud dies. Preserve that by preferring Zigbee, Z-Wave, Thread, or WiFi devices with local APIs (anything ESPHome-based, Shelly, most Tasmota) over cloud-tethered gear. A cloud device demoted to a cloud integration still works, but you have reintroduced exactly the dependency you were escaping. The degoogle map has a longer list of local-first swaps.

Start with three automations, not thirty

The platform's depth is a trap for week-one enthusiasm. The durable path: motion-activated lights in one room, a door-open notification, and something time-based like "turn everything off at midnight." Live with those for two weeks, learn how triggers, conditions, and actions compose, then expand. Automations you copy wholesale from forums before understanding the model are the ones that misfire at 3 a.m., and debugging someone else's YAML is the fastest way to sour on the hobby.

Updates land monthly — read before you click

Home Assistant ships a feature release every month, and a few times a year one includes breaking changes for specific integrations. The release notes flag them explicitly by integration name, so the routine is: skim the breaking-changes section for names you use, take the automatic snapshot, update. Waiting a week after each release (x.x.1 or x.x.2) is the sensible-conservative option. What you should not do is fall six months behind — catching up across many releases at once is where upgrades actually break.

Remote access without opening a port

Three good options, in order of effort: Nabu Casa's cloud ($6.50/month, funds the project's development, zero config), Tailscale (free, ten minutes, invisible to the internet), or a reverse proxy with TLS. If you proxy, add the proxy's IP to trusted_proxies in configuration.yaml or logins will fail with an unhelpful error. Never forward port 8123 raw.

What I'd do

HA OS on a used mini PC with an SSD, a Sonoff or SkyConnect Zigbee stick on an extension cable, three automations in week one, Nabu Casa or Tailscale for remote access, and the monthly update ritual with snapshots. Home Assistant repays patience like nothing else in self-hosting — it just asks that you extend the patience to yourself first.