[On Hold] Deprecating Home Assistant Supervised on generic Linux

You’re making way too much out of this!


That ship has sailed, time to move on


I’ll refer you to my comment from a few days ago because this is becoming painful.


Hi All,
I have to admit I was quite sadden to read this whole thread, I thought this was a platform for enthusiasts yet the enthusiasm seem to have disappeared. I am also running Home Assistant Supervised on a generic debian 10 linux machine and if the way to install it changes then I will adapt. I agree with Sparkydave there.
So I’d like to take this as an opportunity to say thank you to Frenck, Paulus and the rest of the team as well as all others who have created scripts, collaborated and created wiki to help me. Please remember there is always an opportunity to learn something new and to improve things.



Wow, just WOW! I am a new user to HA, but seriously thinking I made such a bad mistake to (try to) use HA. This thread shows everything that is wrong with HA. Going on since May! There is clearly so much discontent here, it can hardly be called a community. As a new user, I find it SUPER frustrating to try to figure out all the possible combinations of docker/venv/VM/Supervisor/linux/debian/ubuntu/…

No clear installation documentation, no upfront support matrix, no dev feedback. Not really what I signed up for.

I honestly don’t care how I install HA, I just want it to run on my platform (RPi 4) efficiently and most importantly reliably and supportable. I want to concentrate on building stuff on top of HA, without having to worry about installation/updates/support - or lack of it.

It’s really not that hard. Go to https://www.home-assistant.io/, click on “Getting Started”, scroll down to Installation and follow the (rather simple) 9 steps just as it lays out.

Is that not clear documentation?

As for “no upfront support matrix”, on the Getting Started page there’s links for:

For advanced users (or if you don’t have a device that is supported by this guide), check out our alternative installation methods.

If you click on the first link, you can see the 11 devices supported for the basic installation method. An additional 5 supported VM images, and instructions on how to install it as a VM (these instructions don’t cover all possible contingencies, but as this is an “advanced” install method, the user is expected to have some assumed knowledge).
The second link has additional hardware requirements and performance expectations.

The rest of the stuff (“docker/venv/VM/Supervisor/linux/debian/ubuntu/”) probably isnt for you if you’re just looking to run it on a Pi and don’t understand what the other options are. Those are considered “advanced” methods, and again assume some existing level of knowledge of the user. However the community forum has plenty of threads to read through to get an idea of what each ones is and how it works.

There are additional community guides available for these install methods, including one that has a nice matrix of what you get/loose with each install method.

Then open source projects might not be the best fit; and one that’s still in a beta phase before a 1.0 release (like HA is) especially.
HA is great software, but if you don’t want to worry about updates I fear that you may not enjoy yourself. HA is on a 3(ish) week release cycle, and while the devs do their best to avoid it, there are typically breaking updates in each and every update. That’s something that’s going to be on you to manage and deal with (with the support of the community, obviously), since there’s no tech support phone number to call if/when it stops working.

HA isnt a “fully mature” software product yet. There is a lot of individual learning and maintenance that the users will have to do themselves. Many new features of HA in the past year have worked to cut down on that but we’re not yet at a 1.0 release for a reason, however home automation is inherently a technically complex venture.


On the contrary. This is the first time I read so much discontent. There is a community of people ready to help and assist. I have tried other solutions out there and Home Assistant is by far the best (subjective view)

Documentation is extensive albeit at times late in catching up with developments, the users are friendly (with the exception of the above exchanges) and the solution works.

I encourage you to read the blog and the vision of the founder it helps understanding what home assistant is for and where it is going.

Not sure what you signed for, I cannot remember having agreed to anything other than gaining new skills, discovering new technologies and having fun!


It is true that this thread is not a great advertisement for HA, but it is not typical.


@Silicon_Avatar - thank you for the very thoughtful response, really appreciate it! I consider myself a power user, I am using docker/python/venv on my day to day job, so I do understand the concepts. I don’t really understand HA yet, I will check the links you mentioned. When I said I don’t want to learn all the inner workings of HA, it is because I don’t want to spend the time in doing that, but concentrate on building on top of it.

To give an very recent example: I was trying to follow this guide to install an add-on (I’d say a pretty basic thing to do). However, there’s no Supervisor panel in my (venv based) direct on rasbian install. Now, to do a simple task, I need to understand what to do (that’s how I came to see this thread), as there is no link to any documentation: “If you installed Home Assistant using any other method then you cannot use add-ons (but you can achieve the same result manually).” - very helpful, I’d like to see a link to how to “achieve the same result manually”.

This is just the latest in a set of issues I ran into and I had a really hard time finding any documentation. It might be me, but trust me, I used dozens (hundreds?) of open source projects. Some are better, some are worse. HA might have been well documented at some point, but given the super messy installation options snafu, I think documentation needs some love.

Meanwhile, I’ll go searching for answers in some other place, but frustrated by having to go through this process every few days.

Take look here https://community.home-assistant.io/c/community-guides/51

Understood. That’s definitely the goal! I think at this point in the project, that’s true except when you get into troubleshooting why things don’t work (which can unfortunately be often, depending on the complexity of what you’re trying to achieve).
Thankfully a lot of really great content/information exists on the forum, just be careful when searching that the information isnt too outdated. HA development moves at a fast pace so information can become outdated quickly.

This is the reason most of us don’t recommend blindly following guides online (outside of the official website) or youtube tutorials, since all too often they lead people down the wrong path when things don’t work.
The Community Guides section of the forum is a great place to learn more about the install methods, and has (usually) up-to-date information.

Good example. The short answer would be to install the software/program on the bare metal of your machine or as docker containers if you have the option.
For example I run some non-addon containers in docker with the image obtained from somewhere generic like LinuxServer, some of which (like ombi) have HA integrations to talk to it.
So if, for example, you didnt or couldn’t use the deCONZ addon, you could run the marthoc container (avilable on docker hub), or install it right on your server, and then you could configure HA to talk to it (getting the same end result as running the addon version).
HOWEVER if you run things like this, you loose some addon specific things like ingress. That’s just not available unless you run it as an addon.

What's ingress?

Introduced in 0.92 (?), ingress is a way of accessing the web based configurations, or webpages, hosted by addons. It used to be that the supervisor would let you re-map the addon’s port 80 to a new port, then you would use the new port to access the addon’s web page. For example you’re HomeAssistant interface may be http://My.IP:8123 and the deCONZ config page would be http://My.IP:8951.
Ingress acts as a nginx proxy server to let those pages be hosted as subdomains. This is great for external access, since you no longer need to forward all those other ports as well in your router. And the ingress pages are protected via your HA authentication, so you can only access them after logging in.
You can acomplish a similar thing running your own nginx proxy server, and their might even be a way to leverage the HA auth system (maybe?), but it would be all manual work you have to do and research. Running supervised HA means ingress is built in and enabled with 1 button press.


One of the main struggles in documentation is the dev cycle. It sounds like an excuse (and pretty much is) but keeping up with all the scattered documentation when things can change very dramatically very quickly is a weak spot here that pretty much all users and devs agree needs some love. All of the documentation is hosted from github though, so every page has an “edit” button. ALL community members are encouraged to use this to submit PRs to fix documentation problems when found.

I hope you can stick with it without too much more frustration, as the platform is super powerful already, and only getting better every 3(ish) weeks.


TBH the community guides are not of major consolation to me. I’m sitting on Ubuntu waiting to migrate to Debian, but waiting for the new installer and documentation about it as teased by Frenck. If I’m going to go through all the work to migrate, I’m going to do it the official-official way…


There is plenty of other documentation there though.

@nickrout thanks for the pointer, but https://community.home-assistant.io/c/community-guides/51 does not seem to link to anything but the main page for me…

Also, this is in the same vein, CYA style: “Please note, guides provided in this section may be outdated/broken and are not supported by Home Assistant. Use these at your own risk.”

Thanks for all the help, I don’t mean to be ungrateful.
I have found an (outdated, but usable) guide on how to install appdaemon here: Installing AppDaemon on Ubuntu with virtualenv

(and sorry for hijacking this thread, if it could be more than it already is :slight_smile: )

I just got done migrating from HA OS to HA Core in Docker. I don’t know what all the fuss is about supervised. I’m loving the stripped down experience. I’m also really enjoying managing the docker environment in my own. If you can figure out how to get supervised running on your own OS, then why not just run core in docker?

1 Like

Because it’s honestly not as nice of an experience and has less features (without having to work for it), even for someone capable of running it as just core with docker addons. Ingress it just nice. Can I do it myself with nginx? Yes, I do that for all my non-ingress stuff, but ingress is just nice. Snapshots are nice. Not having to manage updating the OS, packages, Python etc is just “nice”.
I can do all of that myself if needed, but when I come home from work I don’t want to be doing more work. There’s nothing that running Core would make easier (for me), but there are plenty of things that running HassOS or supervised install does make easier (for me). But YMMV, so to each their own.


The new installer whatever it may be will give you the same result - Supervised on Debian 10, so there is no real point in waiting if you want to move. The guidelines are clear, they won’t change. Follow ADR-0014 - Install vanilla Debian 10, the dependencies and the install script.

If you are already running Supervised on Ubuntu, take a snapshot, install Debian, dependencies and the script, restore your snapshot. I say this will all honesty - if you can copy/paste and follow instruction, it will take you less than 1hr to completely migrate. I can do it about 30mins start to finish now as I’ve done it so many times writing and testing my guides. It’s really very easy, and fast.

If you aren’t confident in getting it right, swap out your OS drive for a fresh one, that way if you make a mistake, you can pop your Ubuntu drive back in and you’re up and running again.


I subscribe to nabu casa so don’t need to fiddle with ngnix. That definitely makes it easier. I will miss easily getting to the config files through ingress, but all my automations are in node-red now so I don’t mess with yaml all that much anymore. Plus I can get to them in a pinch through VPN and VNC on my phone.

I’m only a few hours in. I may change my mind the first time I bring all down doing something I shouldn’t do. So far I’m digging it.

I will say, it’s not like supervised was a cake walk either. At least in HA OS, I managed to crash and burn a few times over the year I ran it doing what I think was normal stuff like upgrading, etc. Only when it went down it took my whole pi with it. I’m kind of looking forward to the next crash, since bringing one container back up is so easy. I suppose its about the same with supervised on Linux?


I’m not worried about doing it right, but wondering why there is a new install script and documentation coming if the one we have now does everything right?

Do you think you will end up with some different version of Supervised?

I would assume instead of running a script, it may pull a container like installing an add-on, I am likely completely wrong. The installation steps will change, the end result won’t.