Home assistant supervisor is not very friendly. It's designed so that it must be kept up to date, and handles it's own auto-update features. It also won't run nicely in a docker container with some significant hacks. This means that the only deployment option if you want a complete home assistant install is to use their "Home Assistant OS" or specific debian versions.
Generally it feels like they're making deploying it as hard as possible, doing stuff like checking if supervisor is running in a docker container and just not working if it is.
This is presumably born out of frustrations with users deploying it incorrectly, but there really is no reason a supervisor based HA install can't run in a docker container. I've got a some private hacks doing just that, that I'm hesitant to post publicly in case they find some way to break it.
No idea what the obsession is with keeping a full home assistant install from running in a container, but it's very strange. Trying to add more friction so they can sell more of their dedicated hardware? Their hardware is nice and stands on it's own, the only reason I don't use it is because I want to run on an old touch screen chromebook for very low power usage.
I wanted to hate this aspect of it, but since I like Debian and and use it as my daily driver on a lot of systems anyway, I just couldn't work up enough ire to complain.
Which is part and parcel of distro-maintainer duties - someone has to deal with the complexity, between the upstream project, linux distro or the end user.
Complaining that the upstream project won't support specific configurations or installations reads as incredibly entitled to me, especially for projects like HA or Pihole that aim to be useful to folk who may not know how to fix package dependency issues, fix a broken install, or many other such foot-guns. This would be a magnet for unpaid support.
If one is knowledgeable enough to complain about installing onto an existing install, then one is likely skilled enough to know how to side-load the app and debug and resulting challenges. It's worth noting the upstream provides the installation artifacts!
I've been running home assistant in docker for years. Just the `homeassistant/home-assistant` image. Don't need anything more. Best I can tell is that the supervisor is for people who just wanted a managed home assistant in a box setup at which point it's fair for the software to take over the system.
I'm running NodeRED and ESPHome in their own docker containers, integrated with home assistant, just fine. Never used supervisor. It's been a few years since I set them up so I don't remember the details but that also means it wasn't anything notable. They've been stable since.
As one example, they (core contributors and founder) were, and still are, very heavy-handed regarding how you are allowed to install their software: https://news.ycombinator.com/item?id=27505277
I was going to purchase a Home Assistant Yellow for my homelab, glad to know I need to minimize my interaction with the project before I pulled the trigger.
Will be sure to inform others using the project about this too, they deserve to know its a risk to rely on a project with such hostile core contributors.
I wouldn't consider downvotes to mean something is prohibited. I did in the past because that's what I limited myself to downvoting, but people just downvote what they don't like for whatever reason. All you can do is to not let it get to you.
