[On Hold] Deprecating Home Assistant Supervised on generic Linux

This is really a philosophical discussion on what Home Assistant is to be…
Is it an embedded system with it’s own OS and it’s strategy to dockerize everything? (HassOS), installable as an OS image or through VM or docker.
Or is it a program which can be installed on any Linux distro and platform?

The former means that the OS is very limited and is much easier to install and support.
The latter is much more flexible but is what is causing all the support/maintenance issues as it may have outgrown this status for many installations.

Right now it is both and the question is whether it is sustainable that way.
The addition of the supervisor gave the latter some of the characteristics of the former. For my particular use case it adds very little value so I never installed it. I use only the core and not even in a venv which I found to add also unnecessary complexity.

1 Like

In the interests of helping the development team gain a better understanding of its user-base, I’d like to share my story (as briefly as possible).

Life with Venv

I started with Home Assistant installed in a python virtual environment on an old laptop running Lubuntu. The concepts and terminology, of both python and linux, were all new to me but I had the time and desire to learn it. This device became my production system. Upgrading is a multi-step procedure so I chose to upgrade infrequently.

Docker Days

For my test system, I learned about docker and used docker-compose to run Home Assistant on another old laptop (with Ubuntu). Upgrading/downgrading is easy and I keep it up-to-date. I had planned to convert my venv-based production system to docker-compose.

New flagship

Along the way, Home Assistant was rebranded. My Home Assistant effectively became “Coke Classic” and Hass.io became the new “Coke”. What was once recommended for novices was promoted to flagship status. However, I didn’t switch. Home Assistant Core served my needs and I was already managing separate instances of mosquitto and Node-Red on an RPI3.

Toe in the water

Nevertheless, I was now curious to learn about the flagship’s amenities. I installed Home Assistant Supervised on yet another old laptop running Ubuntu. Why? Mostly because I was unwilling to spend money on new hardware that’s compatible with the available images. Plus I prefer an operating system with more flexibility than the purpose-built HassOS. I have SSH and samba services installed in Ubuntu, as opposed to using docker-based Add-Ons. In the event of a docker screwup, I have a robust means of accessing the system to fix the problem.

Acceptance and Adoption

After using it, I liked what I saw and gained a greater appreciation for why the development team chose it to be the flagship. In a nutshell, management is greatly simplified. Despite being at ease with performing upgrades in venv (and docker-compose), I preferred the simplicity of one-click upgrades, easy backups, and simplified management of related services via the Add-On system.

Ultimately, I decommissioned my old production system and the RPI3 hosting mosquitto and Node-Red. Everything was consolidated on an old laptop running Home Assistant Supervised on Ubuntu. This is a valuable means of running Home Assistant and it would be a shame to have it demoted to unofficial, non-supported status.


That happened to me as well, but it seems that if you download the script and run it from your computer it WILL work. I’m doing this in OpenMediaVault but I suspect it works on other OS’s too. I don’t know why the officially suggested command fails.

This is what I did to download the script:

curl -sL https://raw.githubusercontent.com/home-assistant/supervised-installer/master/installer.sh > installer.sh

Followed by:

./installer.sh -d /your/preferred/hassio/directory

Caveat: I’m not a Linux-expert, this was found through a little experimenting, any action on your part is on you, not me!

1 Like

Thanks! It worked. Just had to give permission to the file (chmod u+x ./installer.sh) and we are ready to go!!!

I’m sorry, but I’m lost also somewhere on the road…

I started with RPI3, but got some crashes of the SD card. Also it was not fast enough for me.
Then I installed HA (Hassio?) on my Synology NAS in the virtual machine from Syno (not docker). Worked well, but also on heavy load or updates from Syno my HA sufferd from it.
I wanted a robust system After long searching, reading,…
I purchased a NUC, and for some reason the native image didn’t work, and after a lot of searching and good help from the community the consensus was that I better installed Ubuntu on it so all driver issues etc would be handled by that (is that correct?)
afterwards I ran these commands:

sudo -i
add-apt-repository universe
apt-get update
apt-get install -y apparmor-utils apt-transport-https avahi-daemon ca-certificates curl dbus jq network-manager socat software-properties-common
curl -sSL https://get.docker.com | sh
curl -sL https://raw.githubusercontent.com/home-assistant/hassio-installer/master/hassio_install.sh | bash -s – -m intel-nuc

I have to say, this is really rock solid, and runs absolutely perfect. Also with all add-ons from Frenck etc…
Can anyone tell me if this is the “right” way, and supported for the future?
If not, what are my options? (Staying on the NUC of course…)

1 Like

First off, please see the sticky post - particularly point 16 about whether or not you should tag folks to demand somebody answers you.

That question is what this whole thread, and the blog post, is about. The answer is to keep an eye on the blog post since the answer has gone from no to we’ll get back to you.


just installed proxmox on a second ssd, installed home assistant with the mentioned script, recovered my snapshot, now mariadb is broken, and the performance has decreased, a lot.
My system is an old pc i used with pfsense, asrock j1900, 8 gb ram

ps: just sharing, obviously :wink:

Can we have an estimation when we will get the final dissicion? Will it be a few days or a month for example

What I don’t understand is the architectural choice to do supervisor as distinct from just docker containers. What I mean by that is that given a need to continue to support pure docker setups, why not architect the additional supervisor stuff to be fully compatible with that. I understand the general statement that one can install HA core in docker and then install all the add-ons from their native locations but that requires the user to figure out how to make the relevant connections between the containers which to my searches is not documented anywhere. I run HA Core on Docker but was considering moving to supervised so that I could get VSCode to work. I searched pretty diligently for how to get that via pure Docker but couldn’t find it (and I far from a newbie, having spent nearly 50 years in software). I am fully competent about running my own system - I just don’t want to have to do explorative searches every time some possibly useful new add-on gets identified. Supervisor and the addon stuff should be architected to be compatible with pure Docker installs such that the differences between Supervised and Docker Core go away.

Sorry, wasn’t my intent to demand an answer… I’ll remove it.

My point was mostly that I even don’t understand in what category my own install falls.

It’s really not that easy to understand.

So I have (I think)
[NUC Hardware] => Ubuntu => Docker => HassOS => (=> again docker???) Hassio (=> And addons?)
And I understand the Ubuntu & Docker part need to be removed? (But what about all the different hardware options and possible driver issues)

So apart from the " no to we’ll get back to you" can anyone explain this to me? I try to learn also of couse.

Thanks a lot!

I fairly new to Home Assistant and I guess I am in the minority but I am in support for deprecating the supervisor on a generic install and I think the team did a good job on illustrating the reasons why.

When I first started trying to use HA it wasn’t very clear to me on the differences between Home Assistant, Home Assistant Core, and Supervised Home Assistant. (I think that the majority of the confusion is “Home Assistant” is both the name of service/server as well as the bundled OS). I wanted to run on a NUC running Fedora (so all my automation worked the same way across all my servers) and the documentation made Home Assistant Core sound undesirable (I have learned this is actually what i wanted) and getting Supervised Home Assistant working with podman wasn’t worth it.

Fast forward, I installed HA on a Rpi4, learned a lot of the terminology and how Supervisor, OS, etc all work together and am ready to go back and run Home Assistant Core on a NUC with Fedora/Podman and think this makes the most sense.

What would be nice is for any add-on is if there is good documentation and maybe even “blessed” docker images that would work to just enable or upgrade components allowing for both users to choose their own distro/hardware but get some of the benefits of the complete solution.


If you say you installed Ubuntu and you see a “Supervisor” option in the main menu, then you have installed Home Assistant Supervised on generic Linux.

If you installed Ubuntu and don’t see the “Supervisor” option then you are running Home Assistant Core.

An alternative maybe could be give a kind of setup, where you choose if enable supervisor things ( addons, backup&restore etc etc ) or have plain home assistant, in a way to handle who want addons and who want pure home assistant but having docker under the hood.

That would be a minority opinion because even Paulus himself apologized for the poor communication.

There’s that and the fact a sufficient number of users opposed the deprecation to cause it be put on hold. Basically, they miscalculated its prevelance and popularity.

Nevertheless, it doesn’t change the fact they are short of resources and something has to change. Either volunteers are found to help out or it will be deprecated as originally planned.


Same with me…
Most of the time I am ignored or told that I am not behaving correctly toward core developers, how can be equally mean and dismissing …
I complied about yaml, as configuration template, as it is crap, and even offered to work oin moving this to json or INI key=value pair.
Shutdown, without any reasonable explanation.
Now I am seeing that linux will be dropped, and I do support project via paying for cloud bridge.
I am hoping that linux stays, as I am not interested in topping excellent kernel with another one (docker) and dealing with yet another os.

Please point out to what are the reasons to drop linux generic installation… I did not find anything on this…

That would be a minority opinion because even Paulus himself apologized for the poor communication.

Communication and a proper deprecation plan could have used some work but, for me, the reasoning is fairly sound from a technical point-of-view.

Really there should be two solutions (and which i think was proposed but again maybe without the clearest in communication). Managed OS or non-managed OS. The in-between of supervised adds way to many different variables and supporting even with a fully staffed/employed team is still very difficult if not impossible to support every distro, every version of docker (or podman), every other tool that wants to manage containers, etc.

So the question then is, how do you bring your own hardware and have a managed os. Perhaps Virtual Machines, the solution proposed in the blog, isn’t for everyone but there is a single distro that is blessed that can run supervisor + HA in a good way and leave the “choose your own distro” out.

1 Like

managed OS and non managed OS…but both with all features or one full featured and one lame?
Because with deprecated supervised installation you end up without addons, backup&restore etc etc…why should i lost it if can’t afford to use hassOS?
Why should i lost it if previously there?
Why not give that for both installations?

1 Like