How to stop supervisor auto-update?

I’m assuming that any changes I made as you suggested would be overwritten when I actually install a supervisor update. As such I’ll need to redo the changes after the update. Is this correct?

At least you tried.

The whole “if you let people have control of their own system they will break it and then ask for help” is starting get tedious.

So you have to completely forego all of the (claimed) benefits of a supervised version of HA just because you want to have the option to decide when you update the supervisor. :roll_eyes:

Even Microsoft and Apple aren’t that dictatorial. At least they ask you first and/or give you a bit of a warning before they do an update.

Maybe you should throw that out on Discord as an alternative option to the “silent middle of the night update that might break things” issue.


Thank you for your feedback.

I totally agree with you.

I’m done with this topic for now, at least on that channel with those people (nothing wrong but I have hit a wall there for now). But if someone else has a different channel to other people it would be nice if they could get that information to them.

I don’t understand how block these file, and what means “block”?

Don’t worry about it then.

Finally, the ability to disable auto-updates was added in Supervisor 2022.08.4


Where is this documented? How do I find the interface that allows m to do this? The automatic updates have made it incredibly difficult to simply keep the functionality that I spent so much time building, working as is. If it’s not broken, I don’t want it fixed.


You know what’s amazing? There are multiple “flavors” of Home Assistant that don’t even have Supervisor, but you can’t stop updating it on the flavor that does - even though nothing but add-ons seem to require it - and you can disable all those other updates, so literally nothing needs a supervisor update.

But the response you’ll get all the time is: you have to update supervisor because then something else can break, blah blah… No, it won’t because if you’re turning off updates, nothing is going to change.

Don’t get me wrong, Home Assistant is great, but it’s a hobby solution for tinkerers. It is not suitable for commercial deployment or to deploy in an un-managed setting.

There is no interface. The option is only available in the cli

ha supervisor options --auto-update=false

Yes you can

1 Like

the command completed successfully on my system. I’d like to ensure all updates are done manually as well. I’ll have to wait to see if supervisor stops updating - I have a supported configuration at this moment.
Thanks @CentralCommand

I’m talking via the UI. You know, an official/easy toggle. Read all the “sky is falling” messages about this in so many threads.

Changes of this nature - that change the way the system is intended to work - are extremely unlikely to be added to the UI. The understanding is that if you know what you are doing you can change it but for people who don’t know it needs to be relatively inaccessible. Like a child proof bottle.


There are people running factories on Home Assistant and no commercial solution should be unmanaged.

I’m sure there are. There are also a million and one bespoke solutions that relatively speaking are a nightmare. However, the thought of deploying Home Assistant in its current state to customers leaves me very concerned. Not all due to HA’s own code/structure, but also because it’s so open and other things that connect to it have their own update schedules. Everything combined creates a daunting set of variables with many failure points. In that respect, a factory installation may be infinitely more simple than the average home.

But a distinct HA “issue” is the release cycle. Just this month, there has been four (4) core updates in the past three days. If these changes are important enough to warrant a core update three days in a row, then the 2022.12 release should have been post-poned to wait for them. This kind of schedule and unpredictability is not something someone supporting multiple installs commercially can gamble on.

I’m facing an issue in my own setup I can’t get a hold of right now, because in the span of 1 week there have dropped updates and changes to multiple technologies all of which can create the issues I’m seeing:

Eero router firmware self-updated.
HomePods and iOS 16.2 update with new homekit architecture
I signed out of and deactivated my sole iPhone for two days and now logged into a temporary iPad

I lost Siri on the Homepods, lost control of everything added via Home Assistant via Apple Home. Reset everything, built Home up again from scratch. Now anything added from Home Assistant is still “no response” and I can’t even add an Ecobee directly (without HA). Siri and the Homepods are otherwise working fine on their own, so there’s that positive :slight_smile:

Dot point updates are bug-fix releases. They are a response to the major release. If you want less of them, join the beta testing team. It is a small group that can’t cover all possible integration combinations.

I was a senior test engineer many moons ago, and also a software project manager, and not likely to step back to those any time soon.

Daily updates are a sign of lack of planning and strategy, not simply test coverage. I can’t influence how that happens at HA, so I can only control how I deploy it (to others).

1 Like

Writing that does not make it true.

True or not from your perspective doesn’t mean that’s not how it’s perceived by customers. This didn’t fly at the $4B company I did this work for previously - not for the company and not for its clients. And it doesn’t fly for my clients today. I simply can’t use HA for them with this kind of update/maintenance process and schedule.

Take that for what you will.

That’s just it. It’s not a matter of perspective. It’s a fact.

Well yeah, in standard point release driven deployment I would agree with you. Something like that would never fly at the software company I work for either. We’d literally get slapped by our customers if we did that (possibly by their legal departments).

But HA is a CD release cycle, so in that context it technically makes sense. Look at HA as being in constant beta basically. Which is not uncommon for a quickly evolving open source project. But it comes with a lot of problems for people looking for stable deployments of course. I always thought that HA needs a stable release channel on top of the current rolling one.