Home Assistant Supervisor

Last reviewed Sep 13, 2026 · 977 words

You do not install the Supervisor. You pick a Home Assistant installation type that ships it, or one that does not, and that single choice decides whether you get the add-on store, one-click backups, and automatic Core updates, or whether you manage all of that yourself with Docker Compose. Most "why is there no add-on tab" questions on the forums are people who chose Home Assistant Container and expected the Supervisor to be there. It is not, by design, and both paths are legitimate; this guide is about choosing knowingly.

Which install types include it

Home Assistant comes in four official flavours. Home Assistant OS is a purpose-built Linux image for a Pi, a mini PC, or a VM, and it includes the Supervisor. Home Assistant Supervised is the same Supervisor installed onto your own Debian system, and it is the only other way to get it. Home Assistant Container is Core in a Docker image with no Supervisor. Home Assistant Core is a Python virtual environment, also without. The Supervisor itself is a Python service, Apache-2.0, running as a privileged Docker container named hassio_supervisor that talks to the Docker socket and orchestrates every other container on the system: Core, the DNS and audio helpers, and each add-on.

So the decision tree is short. Want the appliance experience and do not need the host for anything else: HAOS, and the Supervisor comes along. Already running a Docker host with twenty other services: Container, and no Supervisor. Supervised sits between and is the option with the most rules attached.

What the Supervisor actually manages

Four things, and they are the four things new users value most. The add-on store: Mosquitto, Zigbee2MQTT, ESPHome, Node-RED, a file editor, a VPN, all installed with a click, each one a Docker container with a manifest the Supervisor understands. Backups: full or partial .tar archives containing Core config, add-on data, and add-on configs, scheduled or on demand, with upload to network storage or Google Drive via a community add-on. Updates: Core, the OS, and each add-on, staged and rolled back if they fail to start. Health checks: the Supervisor watches the Docker daemon, disk, and network and marks the system unhealthy or unsupported when something drifts, which is also where it becomes controversial.

None of that is magic. Each add-on is a container image you could run yourself, and the Home Assistant first-month guide shows how much of the initial setup is the same either way.

The Container trap and its honest workaround

If you run Home Assistant Container, you run the add-ons as separate compose services: Mosquitto for MQTT, Zigbee2MQTT for the coordinator, ESPHome for firmware builds, and so on. It is more typing, and the integration settings ask for a hostname instead of auto-discovering core-mosquitto, but the result is the same containers with the same data, and you keep full control of the Docker host. Backups become your job: a nightly tar of the config volume plus each companion's data, shipped off the box. HACS, the community integration store, works on every install type because it lives inside Core rather than in the Supervisor, so HACS is not the thing you lose. What you lose is the one-click install and the coordinated update.

For anyone who already maintains a compose stack, this is the better trade. For anyone who wants the smart-home box to be an appliance, it is not.

Supervised on Debian: the rules that make it "unsupported"

Supervised is the path people take when they want add-ons but also want the host for other things, and it is where the friction lives. The Supervisor expects to own the Docker daemon. Officially supported means the current stable Debian release, the specific Docker version the installer pins, systemd, NetworkManager, no other containers it did not start, and a list of other conditions it checks continuously. Break one and the system flips to "unsupported"; break enough and it flips to "unhealthy", at which point updates stop. Running Portainer alongside, using a different OS, or adjusting Docker's storage driver all trip it. You can still run it that way, and plenty of people do, but you are then outside what the project will help with, and every Supervisor update may re-check the rules with new strictness.

Backups are its best feature

If I had to justify HAOS or Supervised over Container with one line, it is this: a Supervisor backup is a single file that restores an entire smart home, add-ons included, onto new hardware in about 15 minutes, and the onboarding screen on a fresh install offers to restore from one. Compare that with a Container setup, where the restore is a compose file, five volumes, and a hope that you captured the Zigbee coordinator's state. Schedule the Supervisor backup nightly, keep 7 locally and copy them off-box; 512 MB of RAM is the floor for the Supervisor stack but 4 GB is what a Pi-class box realistically wants once a few add-ons run.

What I'd do

New to smart home, or want the box to just work: HAOS on a mini PC or a Pi, Supervisor included, nightly backups to a NAS. Already running a Docker host and comfortable with compose: Container plus Mosquitto and Zigbee2MQTT as sibling services, and skip the Supervisor without regret. Supervised only if you have a spare Debian machine you are willing to dedicate to it and will follow the rules to the letter. The home-automation category covers the rest of the stack, and the Home Assistant versus openHAB comparison is where to go if the whole platform is still in question.