Home Assistant is an open-source platform for integrating, controlling, and automating home devices, with a special focus on local control and privacy.
In previous articles, we have analyzed different network architectures, commercial ecosystems, and radio frequency communication protocols. The time has come to centralize all of this into a single point. We need a brain, a server that acts as the conductor.
In this course, it will be the common point between our devices, interfaces, and automations. Before installing it, it is important to understand its two currently supported methods, because the choice determines who will be responsible for maintaining the system.
What is Home Assistant?
Home Assistant (often abbreviated as HA) is an open-source home automation software. It is primarily written in Python, and its fundamental goal is to be an agnostic and manufacturer-independent control system, always prioritizing local control and privacy.
Basically, Home Assistant acts as a universal translator and a rule engine.
It connects to the local API of your Shelly bulb, the USB dongle of your Zigbee network, and the cloud of your thermostat (if there’s no other option), and normalizes all that data into a standard internal format. Once all devices “speak the same language” within HA, we can create control interfaces (Dashboards) and complex automations that cross-reference information between different brands without any issues.
Installation Methods
For years, when you visited the official Home Assistant page, you would find four different installation methods. Today the situation is simpler: Home Assistant OS and Home Assistant Container are the two supported paths, while Core and Supervised were discontinued as of Home Assistant 2025.12.
Home Assistant is not a simple executable program (an .exe or a script). It is a complete ecosystem that can be deployed on different layers. Let’s analyze the two recommended paths and the two legacy options that are still worth knowing to avoid confusion when reading old tutorials.
Home Assistant OS (HAOS)
This is the recommended method for 90% of users, and the one we will use as our primary reference for most dedicated installations.
Home Assistant OS is not just the home automation program. It is a complete, minimalist, and optimized operating system (based on Buildroot) designed with the sole purpose of running Home Assistant on dedicated hardware (like a Raspberry Pi or a Mini PC).
The internal architecture of HAOS is divided into several container layers:
- The base Operating System (HAOS).
- Docker, which runs natively on top of the OS.
- The Supervisor: A special container whose only function is to monitor and manage the rest of the system.
- The Core: The container that actually runs the Home Assistant Python code.
- The Applications: Additional containers that the Supervisor installs and configures for us (until recently, these were called Add-ons).
The concept of an application is important. In HAOS, if you need to install an MQTT broker like Mosquitto or the Zigbee2MQTT software, you can do it from the interface. The Supervisor takes care of downloading the image, configuring the internal networks, and starting the container.
Home Assistant Container
This is the preferred option for advanced users who already have a Linux server with containers, for example on a NAS or a dedicated machine.
With this method, we deploy the official image ghcr.io/home-assistant/home-assistant:stable using Docker Compose or another compatible OCI environment.
- Advantage: You have absolute control. Home Assistant is just another container in your ecosystem, sharing resources with your Plex, Nextcloud, or Pi-hole.
- Disadvantage: You don’t have the Supervisor or applications managed by Home Assistant. If you want to install an MQTT broker or Node-RED, you will have to deploy and update their containers yourself.
If you are a system administrator or developer and you master Docker, this option is extremely clean and portable. If you don’t want to touch a Linux terminal, stay away from this method and use HAOS.
The big practical difference isn’t “Docker yes or Docker no.” The difference is who is responsible for operating the ecosystem. In HAOS, Home Assistant manages the Supervisor, applications, updates, and backups from the interface. In Container, that responsibility falls on you.
Home Assistant Supervised (legacy method)
The Supervised method attempted to be a hybrid between the two previous ones. It is no longer supported, although it’s worth recognizing the name when it appears in old tutorials.
It involves installing a pure Debian operating system (strict and unmodified), installing Docker yourself, and then running a script that injects the Supervisor into your system. This way, you kept control of the operating system and retained the application store in the Home Assistant interface.
The problem with this architecture is that the Supervisor is extremely demanding. If you install any other software on that Debian that the Supervisor dislikes (or that changes the network configuration of Docker or AppArmor), your system will mark an error of “Unhealthy” or “Unsupported”, and the Supervisor will refuse to update Home Assistant until you fix it.
Home Assistant Core (legacy method)
This was the original method in the early days of the project. Today it remains primarily as an environment for developing Home Assistant and integrations and is no longer offered as a compatible installation for end users.
It involves creating a Python virtual environment (venv) on a Linux machine, macOS, or Windows via WSL, and installing the homeassistant package using pip.
There is no Docker, Supervisor, or managed applications, and you have to maintain the Python versions, system dependencies, and the process startup. This is not the recommended path for a home.
Which Method to Choose for the Course?
To follow the rest of the tutorials in this course and ensure we focus on home automation rather than Linux system administration, our firm recommendation is to use Home Assistant OS (HAOS).
HAOS provides us with a predictable environment and access to the Supervisor, which facilitates the installation of applications like Zigbee2MQTT, ESPHome, or Node-RED.
