Not sure why this keeps being recommended, instead.
Managing Docker infrastructure is significantly different than HA add-ons. Managing Docker infra is my daily driver job. This is like recommending someone go use more computers. Can it be done? Sure. Does it make sense as a comparative replacement? No.
For example, several add-ons rely on HA ingress. If you terminate your server with TLS, the ingress is secured with a session. So you get a convenient frontend for (mostly secure) managing of multiple insecure backend interfaces through the ingress endpoint.
Home Assistant supervised is acting like an orchestrator similar to Kubernetes; except a normal person can interface with it because of how Add-ons are integrated with home assistant.
This seems to be a heavily slanted view. I just joined; look at my post history at this point. Feels like a pointless attack…
You can relay your points without a generalization.
This thread basically has two camps: those already convinced this should be (with no interest in hearing feedback; just fighting it) and those trying to explain how they arrived at the current setup.
It’s fine that this is the way it is going (support deprecation) but it is a bit disturbing how hard some people are arguing against the feedback in this thread. Why ask for feedback at all?
Yet you have been running the setup for almost an year and have installed it for friends and family.
I could make it more precise and add a “or not a member at all”, but I see not-registered users as passive members too.
I have explained how I arrived at my current setup with HAOS.
I started out with HA supervised on Debian 11 and I managed to get it updated to Debian 12 and Python3.13, but it was not without big complications.
HA supervised installation is easy enough to install and the first many months might be fine, but when HA suddenly requires the OS and python to be updated, then most HA supervised users are ill-equipped to handle it and the users of this installation type are just scarce on the forums, so the few there are there are quickly overwhelmed and because the installation is so different with so man pitfalls, then the experts on this setup also often comes up short.
Seems a bit unreasonable to expect someone to join a project forum and start contributing to support from day 1. There’s a period one must become familiar with it to even do that.
It is unproductive to effectively call someone a leech with this generalization. I’ve started contributing but I guess too little too late? Especially in the spirit of open source; you never know what other open source projects that person might be maintaining that HAOS or your other projects might directly rely without realizing.
I have also not requested support, either. Does that not count for something?
I’ll keep this in mind. Thanks for sharing. At the moment, my constraint of supervised was boxed in by the hardware I bought (orange pi zero 3w and zero 2w are boards I often buy). Unfortunately, HAOS won’t even boot due to driver issues so I use orange pi distribution of Debian 12; Armbian didn’t work either (the vendor OS was my last choice). OrangePi has really good docs and OPi also shares kernel sources but I doubt compiling a custom kernel on HAOS would be any more supported than supervised.
My main point about raising my replies to yours was just to highlight it’s fine for people to share their feedback. It is not fine to tell people their feedback is incorrect. It is feedback and technically there is no wrong answer.
Admins already weighed in they will continue with plan to drop support. Unfortunate for me but it is what it is. HA is still really good at being what it is.
I do understand that there have to be a grace time of introduction before starting to contributing to the project and I did not think of you as a leach.
My point was that the support of HA is mainly the community forums and the supervised and core installations do require a lot more support than HAOS, so if the people who have knowledge about these installations to not step up, then the users will have a feeling of being lost in the world of HA.
The deprecation of those installation types are due to that lack of support and if you are not active on the forum, then you would not know that reality.
I am happy that you have started to contribute and it is required because many will probably try to keep their deprecated installation running, so your knowledge is needed and highly valued.
It is probably too little too latr, but this have been like this for years now and the growth of the project have just made the problem worse. You alone would sadly not be able to shift that.
Perhaps also of interest is that not all of us spend time contributing on these forums… instead we may be contributing in other related communities. I spend way too much time in the cesspool frequently known as Facebook [66k+ contribution points in what I believe is the official public group].
Do we expect those contributions to carry over into greater respect here? Well, I don’t, but I may still be rather annoyed to be labeled a leech in the greater community.
I am sorry if you felt i called you a leach.
It was not my intension or my thought.
It was meant as a comment to the posts that suggested the deprecated installation types would be supported by the community instead, which is not even possible today.
I might have replied to your post specifically and then I went into a reply in general and the distinction was not very clear in my post. Sorry.
As an experienced Linux person, I have been running Home Assistant Core (i.e. in a venv) on a Raspberry Pi 4 for years. I choose to run it on Ubuntu Server 24.04 LTS, so that I don’t have to upgrade the OS that often. The last two years it has been challenging for HA because of the Python version requirements. Using uv helped a bit, but this deprecation is the final straw: no more venv.
Going forward, I will run HA as a docker image. I already got an N100 Mini PC and tested out HA on it using the official docker image, and it runs well. Feels faster than the Raspberry Pi too.
One of the things that will need to be documented is what changes do you need to do to make the migration work. Backup takes care of most things, but there are still things like shell scripts. Now they have to be in a specific place (under the config directory, e.g. under config/shell), so paths need to be amended.
What else should we migrators be aware of, and need to do?
