Home Assistant Installation Methods Compared: OS, Supervised, Container, and Core

We've covered running Home Assistant on a Pi 4, comparing Home Assistant Green against a DIY Pi 5 build, and designing dashboards once it's running — but every one of those guides glosses over a decision that trips up more new users than almost anything else: Home Assistant actually ships as four distinctly different installation methods, and they are not interchangeable later without real migration work. Picking the wrong one for your needs means either hitting a wall when you want to add a USB Zigbee stick, or carrying far more overhead than a Pi needs to run a handful of automations. This guide lays out exactly what each method gives you and takes away, so the decision gets made once, correctly, instead of twice.

The Four Methods at a Glance

MethodWhat It IsAdd-on Store?Runs Alongside Other Docker Containers?Update Mechanism Home Assistant OS (HAOS)A full, dedicated Linux OS image — Home Assistant is the operating systemYes, fullNo — it owns the whole deviceOne-click OS + Core updates from the UI SupervisedSupervisor + Core installed on top of an existing Debian OSYes, fullAwkwardly — officially unsupported outside specific distrosUI-driven, same as HAOS ContainerJust Home Assistant Core as a Docker containerNoYes, natively — this is the pointManual: pull a new image, recreate the container Core (Python venv)Home Assistant installed directly as a Python applicationNoYes, since it's just a process on your OSManual: pip upgrade inside the venv

Home Assistant OS: The Default Recommendation, and Why

HAOS is what you get from the official Raspberry Pi installer and what ships on Home Assistant Green and Yellow. It takes over the entire SD card or SSD — there's no underlying general-purpose Linux for you to SSH into and install other software on in the conventional sense (though it does offer an SSH add-on and a protected host-level shell for advanced users). In exchange, you get:

• The full Supervisor layer, which runs add-ons (Pi-hole, Node-RED, ESPHome, Mosquitto, file editors, and hundreds more) as managed, sandboxed containers with one-click install, config UIs, and automatic updates
• Automatic OS-level updates and backups through the UI, no command line required
• Official support — this is the install method Home Assistant's own team builds and tests against first, and the one referenced by default in their documentation and forums
• Hardware passthrough handled automatically for most common Zigbee/Z-Wave USB sticks

The tradeoff: the Pi running HAOS is now a single-purpose appliance. If you also wanted that Pi to run Pi-hole directly, or your Klipper print farm's Moonraker instance, or a Samba share, you either do it through a Home Assistant add-on (if one exists for your use case) or you run those things on a separate device. For most home setups this single-purpose approach is exactly right, and it's what we recommend defaulting to in our Pi 4 Home Assistant setup guide for that reason.

Supervised: Technically Possible, Not Recommended for New Setups

Supervised installs the same Supervisor layer as HAOS, but on top of a general-purpose Debian installation you control. In theory this gets you the add-on ecosystem and a full OS you can install other software on directly. In practice: Home Assistant's own team officially supports Supervised only on a short, specific list of OSes and architectures, actively discourages running it elsewhere, and the "Supervised on unsupported system" warning banner that frequently appears for anyone who deviates from the exact supported path is a direct signal that updates may silently break. Unless you have a very specific infrastructure reason to need this exact combination (and most people who think they do are actually better served by Container), skip it. It's effectively a legacy path kept around for a narrow set of existing deployments rather than a recommended starting point in 2026.

Container: For People Who Already Run Docker Infrastructure

If your Raspberry Pi (or NAS, or homelab server) already runs a Docker Compose stack for other self-hosted services — Pi-hole, a Grafana dashboard, Uptime Kuma, whatever — Container installs Home Assistant Core as one more service in that same stack, managed with the same tooling you already use for everything else:

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

network_mode: host matters here — Home Assistant relies heavily on local network discovery (mDNS/SSDP) for finding devices automatically, which doesn't traverse Docker's default bridge networking cleanly. You lose the Supervisor and the add-on store entirely: no one-click Mosquitto, no Node-RED add-on, no ESPHome add-on. You replace each of those with your own separate container in the same Compose file (Eclipse Mosquitto, Node-RED's own official image, and so on) and wire them together with manual configuration rather than Supervisor's guided setup. Updates are manual too — pull the new image tag, recreate the container, read the breaking-changes section of the release notes yourself before you do.

This is the right call specifically when you want Home Assistant to live inside infrastructure you already manage uniformly — our Docker Swarm cluster guide and K3s cluster guide both assume this is how you'd eventually fold Home Assistant into a broader self-hosted stack, since neither orchestrator has a concept of "add-ons" the way Supervisor does.

Core: The Bare-Metal Python Install

Core installs Home Assistant directly as a Python package inside a virtual environment on your OS of choice, with no container layer and no Supervisor at all. It's the most hands-on method, the hardest to keep updated cleanly (Python dependency conflicts are a real risk over time), and offers the least isolation from the rest of your system. It exists mainly for developers working on Home Assistant itself, or users running it on hardware/OS combinations where Docker genuinely isn't viable. For nearly everyone else there's a better method above that gets the same result with far less ongoing maintenance burden.

Picking One

• Dedicating a Pi (or Home Assistant Green/Yellow) entirely to Home Assistant, and you want the smoothest experience — HAOS. This is correct for most people reading this.
• Already running a Docker Compose or Swarm stack on that device for other self-hosted services, and comfortable wiring up MQTT/Node-RED yourself as separate containers — Container.
• Developing Home Assistant integrations or core code — Core, in a dev environment specifically.
• Considering Supervised — reconsider; Container almost always gets you what you actually wanted with a supported, documented path.

Migrating Between Methods Later

Your Home Assistant configuration itself (the config/ directory: automations, entities, dashboards, the full backup snapshot) moves cleanly between HAOS and Container — a full backup from one restores into the other, since the underlying Core application and config schema are identical. What doesn't move automatically is anything add-on-specific: if you migrate from HAOS to Container, every add-on you were relying on (Node-RED, Mosquitto, the various integrations' companion add-ons) needs to be stood up as its own container and reconnected, which is real work, not a button press. Decide up front rather than planning to switch later; it's not difficult, but it's also not free.