Home Assistant runs home automation locally. Lights, sensors, speakers, cameras and switches are controlled from a machine in your house instead of through the manufacturer's servers, which is the difference between a device that keeps working and one that stops when a company loses interest.

There are several ways to install it, and the choice matters more than any setting you will make afterwards.

Containers give up the add-on store

The supervised installations run a supervisor alongside Home Assistant that provides an add-on store, managed updates and integrated backups. Running the container on its own gives you none of those.

That is a significant trade, not a technicality. Add-ons are how most people install the supporting pieces — the database, the MQTT broker, the voice components — and without the store you install and maintain each of those yourself as ordinary containers.

For someone already running a compose stack, that is often the goal. Everything sits in one file, updated the same way as everything else. For someone who wants a home automation appliance, it is the wrong route, and choosing it because it looked familiar is the most common regret in this software.

Bridge networking silently breaks discovery

This is the critical failure to know about before you start, because the symptom does not point to the cause.

Home Assistant finds devices using protocols that broadcast across the local network. Home Assistant uses multicast for this, and multicast does not cross the boundary of Docker's default bridge network. Inside the bridge, the container has its own address behind a translation layer, and the broadcasts never arrive.

The result is an installation that works perfectly and finds nothing. The interface loads, the logs look healthy, and the speakers, streaming devices and printers that are plainly on the network simply do not appear. Nothing reports an error, because from the container's position nothing failed.

Host networking is the answer, and it is not free

To fix this, run the container on the host's own network interface instead of behind the bridge. It then sees the network the way the machine does, the broadcasts arrive, and discovery works.

What you give up is isolation. The container is no longer separated from the host's network stack, it does not get its own address, and published-port mappings stop applying because it is simply using the host's ports directly. This also introduces the risk of a port conflict with other services on the machine.

For a dedicated machine on a home network this is a reasonable trade and the standard recommendation. On a shared server running other services it deserves more thought, and is one of the better arguments for giving home automation its own small machine.

Decide the storage before the first restart

The configuration directory holds everything: the configuration, the database of state history, the credentials for every integration you connect.

Put it on a real volume from the first run. The history database grows steadily and is the largest thing in there, and it is also the part people discover late, usually when a small disk fills.

The state history has a retention setting. The default keeps more than most households need, and shortening it is the ordinary fix for a database that has grown alarming rather than a sign anything is wrong.

Backups are yours now

The supervised installations have a backup function built in. Running the container does not, so the configuration directory has to be part of whatever backs up the rest of your stack.

This matters more than for most services because of what those files contain. Rebuilding a Home Assistant configuration means re-pairing devices, re-authorising integrations and rewriting automations, and none of that is stored anywhere else. The files are small; there is no excuse for not having them.

Where this comes from, and what will date

Composed from the project's own installation documentation and community discussion of container networking together with several independent published setups, cross-checked against each other on 31 August 2026. Which installation methods are supported changes over time and is worth checking against current documentation before committing to one.

Local control is the reason to run this, and it is not automatic. Plenty of integrations still talk to a manufacturer's cloud, and running Home Assistant yourself does not change what those devices do. If independence from a vendor is the goal, that is a question to ask about each device rather than one the platform answers for you.