So… I decided to give HAOS a try on Proxmox. Install went fine, but unable to restore my backup do to this error “Backup was made on supervisor version 2025.06.0, can’t restore on 2025.05.5. Must update supervisor first.” When I do “ha supervisor update” I get the error "No supervisor Update available - 25.05.5.
Not liking this so far. I hope the powers to be reconsider supporting Supervised Installs…
BTW any suggestion on how to fix this error ?
Looks like you used the beta channel because the stable versions don’t line up.
Just join the beta again.
ha supervisor options --channel beta might also work.
Yeah, I did. Re-joining the beta channel didn’t work.
Take a full backup then try this
ha supervisor options --channel beta
ha refresh-updates
ha supervisor update
That said I don’t think you should use anything but stable on a HAOS instance you care about.
The internet is full of people with Raspis that cause similar problems that can’t be fixed with HAOS. In my case the problems were caused by the wifi module and could be solved during to boot process (see https://forums.raspberrypi.com/viewtopic.php?t=367466#p2282518 for details).
But was not possible to fix that with HAOS, because it has such strong limitations on settings you can change when the system is starting without getting overwritten on every reboot.
With supervised I could also deactivate some other unnecessary things. E.g. I don’t need bluetooth at all.
I for sure will switch to a VM now. Running HAOS directly on the Raspi is too unstable.
And I can see the bias that led to this decision not continuing HA supervised. They only looked at the tracking data, but many people with linux admin skills don’t give the tracking permission…
…and it has been posted six gazillion times in this and previous deprecation threads/discussions that 100% of the unskilled HAOS installers also aren’t providing tracking data because the feature is OPT-IN and disabled by default… 
If you read the discussion thread linked in the bottom of the first post, then you will see that the analytics stats were only used as a light influence on the decision.
The heavy influence was put on the support cases and the time consumption for these two installation methods.
Support cases have the user state their installation method, so those numbers are not biased, but still showed that the time used on those two installation method far outweighed the HAOS and Docker installation method.
Hey - it just occured to me, although this might be too much of a paradigm shift to elegantly do - just as HACS has community supported integrations - can the HA Supervised be moved (or maybe the better work is branched) to a community managed version which would show up in HACS or somewhere similar? That would take the load off of the admins (Nabu Casa developers rather) and occassionally the source code from Nabu Casa could be used by the community to update the “HA Supervised Community Edition” - ? THE BEST OF BOTH WORLDS? 
HA is open source, so it is just doing a fork in GitHub and start the work.
HA will continue to be open source, so new versions and bug fixes will also be available in the future.
I plan to create a separate GitHub organization and there are multiple supervised users willing to step up and support.
That likely won’t happen until closer to the removal.
I made some debian packaging sometime ago. I may help. Do no hesitate to ping me
So you are already unsupported. What do you think will change?
The response from @nickrout led me to read your post.
What brand is your NAS?
…and NAS model (since non-Plus Synology models cannot run virtual machines)???
Thank you! I should have been more specific as the model DOES matters depending on the vendor.
It’s in GitHub.
I can’t help myself after reading 30 days of this.
A hardcore expert should know that if the change notice to users generates the same questions from many users repeatedly, the change notice failed to save said experts the time required to re-explain. They should also know how to adapt to the users understanding on the fly, instead of wasting more time.
The only thing worse than blaming users for not understanding something that clearly wasnt clear enough for the users… is trying to silence other users trying to help everyone understand.
@aredon thank you for digging and persisting. You have no doubt helped others besides myself get clarity. Please do not move on from this thread as requested, your summaries are much needed. That’s clear to everyone but the hardcore.
It’s posts like these that solicits posts like Petro’s.
What do you still need clarity on? What still needs explaining? I’m not saying people should move on. I’m genuinely trying to understand what’s still unclear – unless you’re trying to garner more support against deprecation, in which case you haven’t provided any counter arguments.
I don’t think Mike is suggesting that he needs more clarity on something.
Rather pointing out that summaries in the comment section are still needed because the original blog text is unclear.
I gave this exact feedback in an earlier comment. And also in the original feedback forum post right before they closed the comments there and announced deprecation was decided without further feedback wanted.
Those pushing back against those complaining need to realize the new-comers first notification is the system repair notification, followed by reading the blog, followed by commenting (likely without reading earlier comments).
The original post could be updated to be more clear and it isn’t really productive to fight against people commenting for the first time exclaiming they should have participated sooner. It’s also not productive to call into question one’s experiences like they’re not relevant or “don’t understand.”
I think this is resolvable by updating the original blog post. If the forum admin is interested in more direct feedback that is actionable, I am happy to re-link the feedback I’ve previously given toward this end.