Home Assistant OS vs Container: Which Install Method to Pick

Pick Home Assistant OS unless you have a specific reason not to. That is the answer the official installation docs give, and it holds for most homes. The interesting question is what a “specific reason” looks like, because the supported methods differ in one structural way that decides most of the rest: whether the Supervisor is present, and therefore whether you can install add-ons.

Get that wrong and you do not find out on day one. You find out three months later, when you want Zigbee2MQTT with one click and cannot have it, or when a restore covers half of what you assumed.

The list got shorter

For years this question involved four methods. It does not any more. In May 2025 the project deprecated Home Assistant Core and Home Assistant Supervised, along with the 32-bit architectures i386, armhf, and armv7. Affected installs got a six-month notice; support ended with the 2025.12 release. Those systems still run, but issue reports are no longer accepted and the doc references were pulled.

So the live choice today is Home Assistant Operating System or Home Assistant Container. Older guides presenting four equal options are simply out of date. Core and Supervised still appear below, because plenty of people are running them.

The Supervisor is the real dividing line

Every method runs the same application, serves the same UI on port 8123, and uses the same YAML and integrations. Your automations do not change between them.

What changes is the management layer. OS and Supervised include the Supervisor, which manages the Home Assistant container, handles updates, and runs the add-on store. Container and Core do not have it. Add-ons are just Docker containers the Supervisor installs, configures, and backs up for you. Dropping the Supervisor does not remove functionality, it transfers that job to you.

A naming note. The official documentation now calls add-ons apps. The Matter integration docs describe the Matter Server as running “as an app (formerly known as add-on)”, and the Z-Wave docs use the same phrasing for the Z-Wave JS app. Nothing about the mechanism changed; the store, the containers and the Supervisor are the same. Community guides, forum threads and this article all still say add-ons, so expect to see both terms for a while yet.

Home Assistant OS: the default answer

Home Assistant OS is a minimal purpose-built Linux image that does nothing except run Home Assistant. You flash it to a device or import it as a virtual machine, and it manages itself: OS updates, Supervisor updates, container lifecycle, and add-ons all arrive through the UI.

Official images cover Raspberry Pi, ODROID boards, and generic x86-64 hardware, alongside the project’s own Green and Yellow boxes. VM appliances ship in the usual formats (OVA, QCOW2, VMDK, VHDX, VDI) for the common hypervisors.

The trade-off is exclusivity. HA OS expects to own the machine. If that same mini PC was also going to run Plex, a download client, and a reverse proxy, HA OS on bare metal is the wrong fit. Run it as a VM instead, which keeps add-on support while letting the box do other work. Choose it if you want a smart home hub, not a Linux administration project.

If you have not bought the machine yet, the box you pick changes this calculation more than the install method does. Home Assistant hardware: what to run it on compares the appliance boxes, a Raspberry Pi, a mini PC and a NAS virtual machine on assembly effort, storage and radio placement.

Home Assistant Container: for people who already run Docker

This is the official Docker image, ghcr.io/home-assistant/home-assistant:stable, run by you, on your host, alongside everything else. You mount a /config volume and let it use the host’s network.

Two things catch people out. First, the documented run command uses host networking rather than a bridge, because local discovery protocols (mDNS, SSDP, and the broadcasts that find Chromecasts, printers, and ESPHome nodes) do not cross a Docker bridge cleanly. Second, there is no add-on store. Anything you would have installed as an add-on becomes another container you run, update, and back up yourself: Mosquitto, Zigbee2MQTT or zwave-js-ui, ESPHome, Node-RED.

For someone already running a Compose stack that is not extra work, just the same work in a familiar place, with upside: you pin versions, roll back with a tag change, and Home Assistant stops being special.

Core and Supervised: what to do if you are on one

Core is the Python application in a virtual environment, with no container and no Supervisor. You own the Python version, the system libraries, and every dependency an integration pulls in. The failure mode was always the same: a release needs a newer Python, your distribution has not shipped it, and you are doing distribution maintenance to apply a smart home update. Migrate to Container.

Supervised gave you the Supervisor and the add-on store on an OS you controlled, at the price of the strictest rules of any method: a minimal Debian 12 (Bookworm) install on a dedicated 64-bit machine, a fixed package set, and no competing container or network management. Deviate and system health flagged the install unsupported or unhealthy, and an unhealthy system blocks updates and add-on installs until you fix it. Migrate to HA OS to keep add-ons, or Container to keep the host.

Neither stops working today, but both sit outside the support boundary, so staying put is a decision with a shelf life.

Zigbee and Z-Wave dongles change the calculus

If your setup is Wi-Fi and cloud only, the install method barely matters. The moment a USB radio is involved, it does.

ZHA and Z-Wave are integrations, not add-ons, so they run on any method. The friction is hardware access:

• Bare metal is the easy case. The dongle appears and you select it.
• Virtual machines need explicit USB passthrough, and the device path can change across reboots. Pin the radio by its stable /dev/serial/by-id/ path, not /dev/ttyUSB0, which is assigned in enumeration order and will silently move.
• Docker containers need the device mapped in explicitly. A container that cannot see the dongle throws an error that looks like a coordinator fault but is not.

Two hardware notes from the ZHA documentation apply regardless of method. Keep the coordinator on a USB extension cable, away from the machine, because USB 3.0 ports and peripherals are known sources of interference in the 2.4 GHz band Zigbee uses. And do not expect a coordinator plugged into the back of a NAS to hit the range on its datasheet. Skipping that cable is the single most common reason Zigbee devices start going unavailable weeks after an otherwise clean install.

Z-Wave adds a wrinkle: the integration talks to a separate Z-Wave JS server. With the Supervisor that is a one-click add-on. On Container it is another service you stand up and maintain. The same applies to Thread, whose border router support is delivered the same way, which is why the choice between Zigbee, Z-Wave and Thread is partly decided by the install method you are reading about here.

Backups are not equivalent across methods

The Backup integration creates and restores backups on every installation type, which is easy to misread as “backups are the same everywhere”. They are not. With the Supervisor present, a backup can cover the configuration, the installed add-ons, and each add-on’s own data, and automatic backups run on a schedule, keep a set number of copies before deleting older ones, and can push to off-device locations such as network storage or a cloud provider.

On Container there are no add-ons to enumerate, so a backup is your /config directory plus whatever you separately arranged for the MQTT broker, the Zigbee2MQTT database, and the Node-RED flows. Normal enough for a Compose user, and dangerous only when someone assumes appliance-grade coverage and never checks. Whichever method you pick, verify a restore once, on purpose, before you need one.

Storage and the SD card failure mode

The most common Home Assistant hardware complaint is not CPU or RAM but storage wear, from a component people forget is running. The recorder integration writes every state change to a database, by default SQLite in your config folder. Per the recorder documentation, history is kept 10 days by default (purge_keep_days), purged nightly. A house full of power monitors and motion sensors produces a continuous write stream, and a consumer microSD card is the worst medium to absorb it.

Mitigations, in order of impact:

1. Run from SSD or eMMC, not microSD. This matters more than which board you buy.
2. Exclude noisy entities from recorder rather than recording everything and purging later. One fast-polling power sensor can dominate the database.
3. Lower purge_keep_days if you never look at three-week-old history.
4. Move to MariaDB or PostgreSQL when the SQLite file gets unwieldy. Both are supported and are the usual answer for large installs.

Quick reference

	HA OS	Container	Supervised	Core
Still supported	Yes	Yes	No	No
Add-on store	Yes	No	Yes	No
Other software on the box	No	Yes	Yes	Yes
Host OS you maintain	None	Any Docker host	Debian 12, strictly	Any Python host
Backups include add-ons	Yes	Config only	Yes	Config only
Update effort	Lowest	Medium	Low, host is on you	Highest

So which one

Start from Home Assistant OS: as a VM if the hardware must do other jobs, on bare metal if it does not. Move to Container only if you already enjoy maintaining a Docker stack and would rather own the MQTT broker and Zigbee bridge yourself. On Supervised or Core, plan the move.

One thing to internalise: Home Assistant ships a release every month, so whatever maintenance a method demands, you pay it roughly twelve times a year. Choose the one whose recurring cost you will still tolerate in month nine, not the one that is most interesting in week one.

See also

• Home Assistant hardware: what to run it on for choosing the box before you choose the method.
• Zigbee vs Z-Wave vs Thread for the radio decision the Supervisor question constrains.
• Zigbee devices going unavailable for the interference and mesh faults that follow a USB radio around.
• DockerHomeLab for Compose patterns on the Container route.
• SelfHostRealm for the wider self-hosted stack.
• UnraidHub if Home Assistant will live on a NAS.

Related on this site

• How to Install ESPHome on ESP32: Add-on, Docker or pip, Then the First USB Flash