Skip to content

8 Decisions for Running Home Assistant: From Install Type to Offline Resilience

Most Home Assistant breakage does not happen while wiring up a sensor. It happens in the first eight calls you make - which install form, where the data lives, whether you enable HTTPS, how permissions are split, whether the house survives an outage, how you reach it remotely, whether you back up, and how you roll back. Get these eight right and the automations and integrations you build later will not sit on top of a weak foundation. Get them wrong and you can patch it up later, but the cost is far higher.

I lay out all eight in the order you actually encounter them, from install to running, and each one carries a judgment standard plus a command or a path you can follow. This is not a "what is HA OS" encyclopedia piece; it is the "which of these fits your situation, and why" answer. For the hands-on steps of flashing hardware and wiring up devices, see the HA OS deployment walkthrough and the Docker deployment guide.

The order of the eight decisions (set the skeleton first, fill in the details after)

Order Decision What settling it early saves you
1 HA OS vs Docker decides who owns the machine, shapes every add-on after
2 Data disk decides longevity and smoothness; swapping later means migrating data
3 Local HTTPS one step on the LAN now; adding a cert later means reworking the entry point
4 2FA + user permissions the later you add it, the more history you must migrate
5 Offline local protocols decides whether the whole house survives an outage; locked in once you buy the devices
6 Remote access path decides whether you are tied to the cloud; switchable at any time
7 Backup strategy set once, pays off for the life of the install
8 Upgrade rollback plan a five-minute step before every upgrade

Judgment principle: the first five are the skeleton you must lock in before you start adding devices; the last three are the long-term operating base. Do not start wiring up devices until the skeleton is set, or you are laying bricks on a foundation that may be wrong.

Question 1: HA OS or Docker

The single most common fork in the road when installing Home Assistant. My test is one line: do you have a machine you can dedicate to Home Assistant 24/7?

  • You have an idle x86 box (J4125, N100, a mini PC), a Synology or QNAP NAS, or a PVE/ESXi host - install HA OS. It bundles the base Linux, the HA Core, the Supervisor, and the add-on store, so you install Mosquitto MQTT, Node-RED, Samba, and ESPHome with a click, and full-system snapshot backup and rollback are natively in the Supervisor.
  • You have only one Linux server already running other workloads and you do not want to add a second machine - use Docker. The cost: you lose the official add-ons and have to start Mosquitto, Postgres, and the rest yourself with docker compose, and you own the volume-directory backups.

Verdict: unless you must fit Home Assistant into an existing Linux host, choose HA OS. The add-on store and one-click backup are the two experiences Docker makes very hard to match.

A minimal Docker stack that actually runs (not the full solution - for that see the Docker deployment guide):

# put data on an SSD, never on the overlay layer
mkdir -p /opt/ha/config /opt/ha/mqtt

# the HA image itself (8123 is the default Home Assistant web port)
docker run -d --name ha \
  -v /opt/ha/config:/config \
  -e TZ=Asia/Shanghai \
  -e USER_ID=$(id -u) GROUP_ID=$(id -g) \
  -p 8123:8123 \
  ghcr.io/home-assistant/home-assistant:stable

You must pass USER_ID/GROUP_ID, or the in-container user and the host file owner will not match and the logs will not write.

Question 2: which data disk - SD, SSD, or NVMe

The Home Assistant binary itself is small. What actually hammers the disk is the recorder (history database) and the add-on logs. The recorder logs every state change of every tracked entity by default; a medium home (dozens of sensors and lights) can write tens to hundreds of megabytes into the database a day, and that is what kills an SD card over time.

Medium Fits Verdict
NVMe / M.2 SSD long-term main install, many entities preferred, best write endurance and random read
SATA SSD a box that already has an SSD fine, slightly slower than NVMe
SD / TF card a few-day trial do not run it long-term; speeds and bad sectors appear within months

Verdict: solid state for a real install; an SD card is for short debugging only.

After you are running, narrow the recorder to only the entities you actually care about (door sensors, main lights, temperature) instead of recording every throwaway sensor - it saves disk and slows database growth:

# in the recorder: section of configuration.yaml
recorder:
  include:
    domains:
      - binary_sensor   # only the door-smoke sensors you actually track
      - sensor
      - light
  exclude:
    entity_globs:
      - sensor.power_*   # drop the high-frequency power entities

Question 3: HTTPS on the LAN

Home Assistant defaults to http://box-ip:8123. Every device on the same network can sniff the plaintext, including your 2FA login. The LAN is not a safe zone - a neighbor's device on your Wi-Fi or a compromised IoT gadget can sniff across your network.

Two cheap ways to turn on HTTPS:

  1. Domain + Let's Encrypt: point an internally-resolvable domain (or a real registered domain with internal DNS) at the box and sign a free certificate in front of port 8123.
  2. The built-in reverse-proxy add-on: install the official "reverse proxy" add-on, which manages the Let's Encrypt certificate for you; a few clicks in the UI, ideal for HA OS users.

Verdict: enabling HTTPS on the LAN is nearly free, and 2FA is only as meaningful as the HTTPS underneath it - do HTTPS first, then 2FA; do not reverse the order.

Question 4: 2FA and user permissions

When more than one person touches the system, split the permissions, or a family member will "accidentally" reconfigure an automation and you will waste hours hunting for a ghost.

  • Admin account: enable 2FA (Settings, Security, Two-factor auth), a TOTP phone code is enough.
  • Family accounts: standard users who can control devices and view their own dashboards but cannot reach the integration or automation editors.
  • Elderly panel: a separate Lovelace view, large fonts, only the toggles they use; keep the complex configuration out of their reach.

Verdict: design the panels around the least technical person in the house; lock the admin down with 2FA and give the family read-only control.

Question 5: does it survive an internet outage

This is Home Assistant's core edge over cloud-first smart home - but it only holds if your devices use local protocols.

Still runs offline: Zigbee, Z-Wave, Matter, Thread, and LAN-connected Wi-Fi devices (ESPHome, Tasmota, Hue in LAN mode, Xiaomi in LAN mode). A door sensor firing a hall light, a thermostat tripping an infrared AC - all of these close the loop inside your own network and run in milliseconds even with the modem unplugged.

Stops when offline: closed devices that only expose a cloud API, remote app control, online add-on store updates.

Verdict: pick devices that carry the "Works with Home Assistant" label and favor local protocols; a house genuinely survives an outage only if the core automations do not depend on a cloud hop. For which protocols are local and which integrations lean on the cloud, see Zigbee basics and Matter/Thread.

Question 6: do you have to pay for the cloud for remote access

No. Nabu Casa is the one-click, no-public-IP convenience, but it is a subscription. To keep the data pipeline in your own hands, two free routes:

  • Cloudflare Tunnel: run cloudflared on the box and tunnel to a domain you own; no public IP, no router port forwarding, and your phone reaches Home Assistant over the domain from outside. Detailed steps in the remote access and external security guide.
  • Tailscale / WireGuard: put the phone and the box into the same private mesh; the phone is "home" before it can reach Home Assistant, which isolates it more than a tunnel.

Verdict: do not default to the cloud for remote access - Cloudflare Tunnel or Tailscale are free and controllable, and the more solid operating fallback.

Question 7: set the backup strategy once

Backup is not "do it when something breaks"; it is a one-time setting that stays in effect for the life of the install.

  • HA OS: the Supervisor makes automatic periodic snapshots, but do not rely on that alone. In Settings, System, Backups, take a manual full snapshot and tick "include add-on data" (many people's default excludes add-on databases, so a restore comes back with the Mosquitto and Node-RED configs gone).
  • Docker: there is no Supervisor backup. You must rsync the /config directory to another machine or a NAS on a schedule, and carry out the key add-on volume directories with it.

Verdict: on HA OS, a full Supervisor snapshot including add-on data, synced off the box on a schedule; on Docker, write your own off-box backup of /config and the add-on volumes - there is no built-in safety net.

For the full backup and restore steps and how to restore across machines, see the backup and restore walkthrough.

Question 8: how to roll back when an upgrade breaks

Home Assistant ships a major release on the first Wednesday of each month; always do a full backup (question 7) before you upgrade. After the upgrade, three checkpoints:

  1. The Repairs panel: Settings, System, Repairs. If the upgrade found a deprecated config or a conflict, it surfaces a card that walks you through the fix; do not ignore it.
  2. The automation Trace: an automation that stopped running after the upgrade - open its trace and see which step broke: the trigger never fired, a condition failed, or an action errored.
  3. Roll back: if neither saves you, roll back to the pre-upgrade snapshot in the Supervisor with one click. It is far faster than reinstalling, and do not keep editing the config in place - that only makes it messier.

For the full upgrade and rollback steps, see the HA OS upgrade and rollback guide.

Verdict: full backup before every upgrade, then Repairs, then Trace, then rollback - that three-step order, and do not keep forcing a fix in the wrong direction.

The eight questions as a minimal checklist

Collapse the eight into a list you can work through top to bottom when you stand up a new install:

  1. Pick the form: dedicated machine, HA OS; fitting into an existing Linux, Docker (question 1).
  2. Pick the data disk: NVMe or M.2 SSD, and narrow the recorder scope (question 2).
  3. Turn on HTTPS on the LAN (domain plus Let's Encrypt, or the built-in proxy) (question 3).
  4. 2FA on the admin, read-only accounts for the family, a minimal panel for the elders (question 4).
  5. Core automations on local-protocol devices only; do not count on cloud-only devices to survive an outage (question 5).
  6. Remote via Cloudflare Tunnel or Tailscale, not the cloud by default (question 6).
  7. Backup: HA OS full snapshot with add-on data; Docker, your own off-box backup (question 7).
  8. Upgrade: back up first, then Repairs, Trace, rollback (question 8).

Bottom line: Home Assistant stability is not decided the moment the install finishes; it is decided by these eight calls before you start. Get the skeleton (the first five) right and adding devices and automations is just piling on top of it. Get it wrong and every layer you add is bricks on a foundation that is wrong. Work through the eight before you touch a thing, and you save yourself the cost of patching holes for half a year after the install.