ContextHome Assistant currently has 4 supported installation types:
The focus for this proposal (as the title already gave away) is the third one: Home Assistant Supervised. BackgroundThe Home Assistant Supervised installation method was introduced as a way to provide almost the full Home Assistant experience on custom hardware while still benefiting from the Supervisor, which manages updates, add-ons, and advanced system features. At the time of its introduction, Home Assistant OS was still in its early stages, with limited hardware support and features. Supervised provided a way for users to run Home Assistant with full functionality on a Debian-based OS of their choice, making it a popular option. However, the landscape has changed. Home Assistant OS has expanded its hardware support, added more features, and is significantly easier to maintain. Meanwhile, Supervised has proven to be difficult to support, fragile, and prone to breakages due to its dependency on the underlying OS. At the time of writing this proposal (11 February 2025), Home Assistant Supervised accounts for just 3.3% of active installations. Since this method is extremely complex and less used, maintaining official support is not justifiable.
Ref: https://analytics.home-assistant.io/ ProposalThe proposal is to drop Home Assistant Supervised as an officially supported installation method. This means:
What this means in practice
ReasoningThere are several strong reasons to drop this method as an officially supported installation: 1. Complexity & user experience!
2. (End-user) Maintenance burden
3. Low adoption rate
4. Negative perception & support overhead
5. Better alternatives existMost Supervised users have better alternatives:
ConsequencesThe consequence is that we will remove an advanced installation methods as a possibility from our end-user documentation and no longer advertise or recommend using this as a way to run Home Assistant on a production instance.
|
Replies: 18 comments 17 replies
This comment has been hidden.
This comment has been hidden.
This comment has been hidden.
This comment has been hidden.
|
Although I am not using this installation type and usually recommend users to use Home Assistant OS based solutions I know that this is still an option that used by many users, mainly if hardware needs a special driver that is not supported by Home Assistant OS. |
|
Few years back I had few of those in 'obscure' ways because of largely the same reasons you indicate, given more maturity in the other install options in hindsight I would have most probably re-adjusted the approach if I still were to have those around. While I was on the potential hurting side of the decision back than, I would consider it a nudge in the right direction nowadays. |
|
This one has fewer of the downsides that I mentioned in #1197 (comment) The significant issues are caused by poor device support at the OS level and the burden of keeping the OS up to date, which I see more issues coming in from users who struggle running HAOS on Windows in a VM than I do from supervised; however, that's a bit of selection bias on my part because I see all the Bluetooth hardware issues. I find myself neutral on this topic and could go either way. |
Maintaining a general purpose OS is hard, and as new hardware comes out which requires new drivers and firmware you play always catch-up. Debian has a huge developer base and a tradition to work on general purpose x86 hardware. This makes it a go-to distribution for lots of users. So far, when a system was too obscure to be supported by HAOS, there was always the Supervised option which was rather close from a feature perspective. The question is where will people move to when Supervised is no longer officially supported. One of the main reason people don't like HAOS is because they don't have control over the underlying OS, and/or would like to use it for other purpose too. Virtualization is probably the best option, but not everyone might want to accept the overhead etc. And there are the pass-through issues which comes with it 😢 So this naturally will also push people towards container installations. Which actually may add more support, as maintaining a container installation is significantly more complex than a Supervised. So from that perspective, I do like to have Supervised as an option. I do have some more thoughts, which I'll share in a separate post. |
|
Agree, there are some nice things to say about Supervised. In the end, this is how we develop Home Assistant as well. However, from a support perspective, it is quite problematic (as in, end-user support in our community). This proposal is thus not about making it impossible to run it this way, it is about removing end-user recommendation, documentation & support. |
|
Since I currently oversee the Supervisor and HAOS development, I'd like to share some of my thoughts on this topic. I do use a Supervised installation via VS Code Remote-SSH plug-in for Supervisor development. We currently have two main methods developing Supervisor: devcontainer and Remote-SSH development. The devcontainer approach has quite some downsides since it is not a full operating system: There is no udev, there is no systemd init system. With that, lots of feature can't really be tested in that mode. Using the Remote-SSH development mode works on HAOS, but that comes with downsides too: The read-only file system prevents additional tools to be installed easily or newer packages installed. Supervised is really a nice test bed for Supervisor development. So I do have personal incentives to have this installation method available. That being said, to run it as production system has downsides: The Debian packages we provide for Supervised are not perfect, and quite invasive. New Supervised users often struggle to accept how much dependencies we have, and how much control Supervisor takes over the OS. Supervisor was designed to have full control over the OS, and the Supervised installation type contradicts this design philosophy. The update of essential system components like Docker leads to side effects and surprises every now and then. This does not provide the user experience we'd like to provider users. So far, the Supervised installation was already largely community supported. The active devs on Supervisor use HAOS installation type, and we tried to implement more and more features which were missing from Supervised to make the HAOS setup usable for more and more users. So for all practical purpose, this architecture proposal is more about making official what is already the case 🙈 With that in mind, promoting this installation method as an official/equal alternative to the other methods (the way we do it today) does seem wrong. So I do agree with the direction of this architecture proposal. However, I'd like to propose an alternative instead of labeling it unsupported: Community supported. We could still do pretty much all the consequences 1 through 5, just in some cases it would mean that documentation maybe could live somewhere else (e.g. Community Forum) and we would label it in the repository as community support instead. We'd need one or two community members willing to do that (@ikifar2012 maybe you can share your opinion on this proposal). |
|
Anything that's not officially supported becomes automatically community supported (and that can end up with a community of 0…). When we adopted the official installation methods, we moved a lot of guides to https://community.home-assistant.io/c/community-guides/51 . A similar thing can happen this time. We would archive |
|
Is there a middle ground where support is dropped (maybe forum only?), the method is discouraged ("advanced" installation), but the documentation is retained and maintained? I've run ever installation method during my Home Assistant journey, and I preferred supervised over container. If I was in a situation again where I didn't have Home Assistant hardware or my proxmox server, it's how I would want to run Home Assistant. |
|
We never destroy anything. We freeze our development work, and no longer test it all before every release. We will no longer accept issues related to supervised installation. Community guides can move to https://community.home-assistant.io/c/community-guides/51 and as long as there is someone willing to maintain it, it can continue to work. This topic is just about us not doing the work and promoting its existence. |
BackgroundI have been using supervised for a long time and currently use it on my main Home Assistant instance. My Home Assistant journey started with a python venv then hassbian, I moved to a server running ESXi which for a while was running a python venv then finally I ended up where I am today with Home Assistant Supervised. For a while I did consider moving off of supervised to HAOS but at the time I didn't feel like resizing a VM disk image (yes, I'm lazy) and compatibility with ESXi guest additions wasn't there (but that was years ago and I haven't messed with it since). Use cases/reasons I have found for people sticking with supervisedOne very useful use case I have found is using the supervised installer on cloud based hosting platforms like linode, I find it super simple to just spin up a temp linode instance when I need to test say for example an addon I am developing One big one in the beginning was the fear from a lot of people that they didn’t like HA OS having control over everything but at the end of the day the supervisor still controls a lot in the supervised installation Another reason I keep seeing for people choosing supervised is when they want the addon ecosystem that supervised provides but don’t have hardware that is compatible Lastly, some do seem to find the installation of HA OS to be a bit cumbersome and while I’m not sure how much of that portion of the userbase may end up on the supervised installer I do think its something we should improve upon Common issues I seeMost issues I have seen relating to the supervised installer usually have to do with installing on an unsupported distro or issues with networking/dns (some of which I believe may be related to the changes the installer makes to systemd-resolved but haven’t been able to reliably recreate and that's a whole other discussion) In conclusionWith every change that is made to the installer/updates to the Debian itself I feel its inevitable that someone’s setup will be affected thus this is an install method I strongly believe only those with an understanding for Linux consider. I do think it still helps fill a small gap in the install base and I personally use it myself, but I do not recommend it to anyone new, and much like everyone else here part of me does fear that no matter how many warnings we put on it, a beginner may see it, not fully grasp how to maintain their system and then end up filing an issue or even worse steering away from home assistant completely thus I totally understand the reasoning for wanting to remove official support for it. However, I do think it should stay around as some sort of “community supported” installation method as mentioned by @agners and others as it is truly impossible to fully support every single piece of hardware that Debian does and for those that truly understand and have the time to troubleshoot and maintain a Debian install, it works but of course should not be recommended to the vast majority of users Sorry for the ramble, I hope it summarises my thoughts. Thank you again for allowing me to a maintainer on supervised and hopefully I can help out in the future on OS |
|
I am in favor of dropping this installation method. |
|
Hi there! I am not a maintainer but I've been running home assistant for over 5 years and have gotten countless people into the ecosystem by showing off my automations. For those of us running lean and cost effective "cloud" setups on proxmox (for example), supervised is about the only acceptable solution that doesn't waste resources or add another "manager" to my stack. Hassos on LXC, last I knew just wasn't an option. I've spent countless hours trying to get things running on my stack, where I run countless other programs and none of them fight me like HA does and even then I don't get a clean UX. There's always some giant warning that I am in-compliant despite every effort being made on my part. Do we really think that's going to get better when the team is not supporting it? One of the peculiarities of my setup is that my config is network hosted. Will I even be able to connect my config? Or do it programmatically if I blow the box away and reinstall it? Or would you prefer I set everything back up through your GUI after every reinstallation? Or do you not consider users that have to (or want to) have fresh installs and what that experience might be like? I can remember a time when this installation method was unsupported for a few months and it was not fun. I pretty much force disabled updates and just ran an old version until the project came to its senses. Dropping this change may benefit your average user who doesn't look at or think about their resources used and probably even helps those with full-blown k8 setups but you're hurting your enthusiast crew that wants to be able to run this anywhere they can run debian. For what it's worth, for a user like me, I don't even like the monitoring or hand-holding updates. More often than not they break my system for features I don't care about. What if we tossed around the idea of providing a installation method that can get a user up and running and forgo some of your control over the OS? Wouldn't that make things easier to support? Maybe I'm missing some easy installation method that works for my setup over the past couple years, if anyone knows of docs/information I would be grateful. Thanks for maintaining this software over the years! |
|
The container installation method doesn't force updates or require any control of the host OS. The main things Supervised or the OS get you is addons, and addons require Home Assistant to exert some control over the host OS so it can set up containers and such for the addons. The container method really feels like what you want. |
|
I fundamentally need to be able to automate the entire installation process for HA. This includes setting up a connection to a network share that connects my configuration files first. How might you suggest I set this up with HAOS? |
|
As a community moderator, the predominant reason I see for people picking Supervised is so they can install other software on the device (which makes it unsupported), and the secondary reason is because they want to install it on an unsupported OS. As it's a method listed in the documentation they pick it and just hack away at it to try and get it working, and are then surprised when told that they shouldn't have picked this method (because they're almost never familiar with Linux administration). Removing this method from the documentation would certainly make it less likely for people to choose it, and much easier to explain to these users that they've picked a lame horse to install as their smart home solution (but with a bit of TLC they can move to a better install method that works for their needs). |
|
I've been using supervised since I started with HA, I've had a couple of times where I broke things, I just needed to refer back to my initial notes and I was back in business. Otherwise clean and very reliable. Dropping it will require a fully rebuild and rethink of my setup. A couple of things I feel are missing that I get from Debian is:
Now if those first two can be added into HAOS, and especially the first one, that would be a huge benefit to everyone using HAOS on bare metal installs. I believe I can get the first two using proxmox but then have another layer to work with and keep up to date. If some of the Devs are also using this to help with core developments, then isn't this going to break all of those people?? So perhaps it should remain but with larger not recommended for beginners, support will be limited, etc. |
|
I’ve been using the Supervised installation since it was first introduced, and frankly, I’m really not on board with this deprecation proposal. For users like me — who aren’t relying on the community to figure out how to plug in a Zigbee stick or why their MQTT broker isn’t working — Supervised is the perfect middle ground. I’ve got powerful hardware already running 24/7, and I want to use it for more than just Home Assistant. Supervised gives me that flexibility, while still letting me take advantage of the add-on ecosystem — which, let’s be honest, is a huge part of what makes Home Assistant so appealing. Could I replicate everything manually with Core? Sure. But why go out of my way to make it harder when the add-ons do the job so well? Deprecating Supervised isn’t just removing a convenience — it’s removing an entire use case. It forces users like me toward dedicated hardware just to run HAOS, and that’s not just a financial burden — it’s environmentally irresponsible. I’ve already got a stable, secure, and powerful setup. Why should I be pushed into buying a Pi or NUC to run what is, at the end of the day, a smart home hub? And the “support burden” argument? I’m not buying it. Most of the support traffic I see comes from HAOS users running on basic Raspberry Pi setups. In contrast, Supervised users are often the ones with the experience — the ones answering the questions, not asking them. The idea that removing Supervised will reduce support needs just doesn’t line up with the reality I see in the community. The people using Supervised installs aren’t typically the ones posting “HELP MY LIGHTS WON’T TURN ON.” What worries me even more is the bigger trend this represents. Over the past few years, Home Assistant has been shifting away from flexibility and configurability, and toward a more locked-down, GUI-centric model. I get the goal of making it more accessible — that’s great. But it shouldn’t come at the expense of the power users who helped grow this platform into what it is. First it's Supervised — what’s next? YAML? Don’t need to version control your config anymore, just trust the GUI and the backup system, right? Supervised is the sweet spot for people who want to run Home Assistant as part of a broader Linux environment, while still benefiting from the simplicity and polish of the HA ecosystem. Removing it would be a huge step backward — not just for advanced users, but for the platform as a whole. |
|
Running HAOS in a VM (for example using Proxmox, but there are certainly other options that don't require replacing your whole OS, like virt-manager and virsh) is such a dramatically more maintainable way of accomplishing that though, both for you and the developers. When I was looking at the various options for HA installation, my response to reading about Supervised and how it works was a big hell no. The idea of running software that makes such massive assumptions about what the host OS is and how it is configured (and can make changes to that configuration!) horrifies me. |
Note that this is already unsupported
https://github.com/home-assistant/architecture/blob/master/adr/0014-home-assistant-supervised.md |
|
Yep, exactly. The very concept of Supervised is horrifying, and provides few benefits compared to HAOS if you're actually using it safely. I had forgotten that the docs went that far though. That actually makes me feel a bit better about it, because with how it works, you kind of need that level of restriction to have any reason to expect stability. |
|
Add one more voice to support this. When I first started HA years ago, I went with Supervised under the assumption that it would provide a more customizable and flexible installation option. While it does do that in some scenarios, the opposite proved to be true in my case. About a year ago (?) I made the switch to HAOS and I haven't looked back. Supervised was significantly more prone to breaking. It was significantly more work to keep updated. It provided only a small advantage over HAOS which I haven't missed. For people like me who read that Supervised is officially supported and potentially offered more flexibility, that pushed me down a path I really didn't want in the end. As HA gains a larger following, I think moving new users to HAOS is absolutely the right choice. |
|
The argument that the Supervised installation method is difficult is not valid. Following the tutorial step by step, the installation is actually quite simple. Since users choose this installation method, it means they have some knowledge of Linux. Therefore, it might be better to simply not recommend it or provide less support. People who know Linux generally have strong self-learning and problem-solving abilities. One reason for using Supervised is that it offers more flexibility compared to HAOS and can be installed on more hardware. Since it's open-source, it should remain open to some extent. I still hope to keep this method available, even if it means offering less support. Alternatively, it could just be released and the problem-solving left to the community. |
|
What hardware does Supervised support that HAOS doesn't? HAOS has pretty broad hardware support, including (pretty much?) any arm64 device with UEFI and mainline kernel support. |
I don't think people run supervised for hardware support, they run it to control the operating system. So I also disagree with that point in OPs post. |
|
There's another similar discussion that is proposing to drop official support for Core as well |
|
Running Frigate NVR or other GPU/NPU dependant addons directly in HOAS would be excellent, but without gpu drivers (AMD Mesa in my case) built into HOAS, HA Supervised has appeared to be the most straightforward solution (or have I missed something?). AI based addons should only increase the need for gpu support. |
|
I have been running a supervised Home Assistant installation on Debian for several years with minimal effort. Contrary to some claims, it hasn’t demanded an inordinate amount of time or expertise to maintain. Why Debian? Because it delivers rock-solid stability across diverse hardware platforms. I’ve also tested HAOS on various Raspberry Pis and Intel NUCs, and Debian consistently outperformed in reliability and uptime. By contrast, HAOS deployments unfortunatly often became unresponsive under random conditions, forcing me to rebuild the entire system from scratch. Since moving to Debian with supervised installation, those interruptions have vanished. Even when Homeassistant failed to start, I could still log into Debian directly and resolve the issue - an important safeguard that justified my initial migration. With the upcoming deprecation of supervised installations, I’ve evaluated the alternatives:
However, virtualization has its own downside: it uses more system resources than a container‑native setup, reducing overall efficiency. Balancing convenience against resource utilization, the supervised installation on Debian has so far offered the best of both worlds. Removing this option will force users to choose between significantly higher maintenance (containers) or higher overhead (virtual machines). I feel one of Home Assistant’s greatest strengths has been its flexibility compared to other similar platforms. It would be a great pity to see it moving toward a more proprietary approach. As a final thought, consider the numbers: 3.3% of the user base may sound small, but that still represents around 15,000 users—many of whom likely started using Homeassistant earlier than most of the userbase. Importantly, these advanced users are also the most privacy‑minded and are therefore more likely to find and disable anonymous reporting, meaning the actual number may be even higher than reported. Losing this cohort could diminish the very community that drove Home Assistant’s early innovation and flexibility. |
|
After collecting community feedback and thoroughly weighing the long-term maintenance benefits against the impact on affected users, the core team has approved this proposal. The aim is that starting with Home Assistant 2025.6, we will begin a six-month deprecation period. We understand this change may be disruptive for some, and it was not taken lightly. However, this step is necessary to ensure Home Assistant can continue to evolve and remain maintainable for the future. Thank you to everyone who participated in the discussion. Your input was essential in guiding this decision. |
|
So basically you are just ignoring 66.000 installations of HA ( 3.3% of 2 million). Probably the users who were there from the start. Wow, just wow….. Time to move on, since the is the start of the end… what’s next….. integrations only used by a few, will not be supported any longer? |
|
That or you could just continue to use it as you did ... just read a couple of the comments and suggestions. The intention is to leave it out to 'grow' the number of installations and potential uptake for less experienced users; hence the open ended way of continued use as per |
|
It won't be stable. Devs are going to continuously break it in ways that will require code changes to fix. This project has already tried this path and it did not work. When code changes are required and the only reason to have them is for supervised, how will those changes get reviewed? HA just got a whole lot less portable. Probably won't be long until they lock all our open source contributions behind a hardware paywall. Nabu Casa is starting to look like your average tech company at this point. Promise customers the world, move the goal post and lock the gate turning your parners into cash cows. Itd be different if you didn't require the community to get to where you are. Maybe I'm wrong and time will tell. |
I would argue Supervised is by far the least portable version of HA, since it assumes a specific version and configuration of Debian. The container version is far, far easier to run in arbitrary environments, and it's even easy to run HAOS in a VM on any hardware with any host OS. |
After collecting community feedback and thoroughly weighing the long-term maintenance benefits against the impact on affected users, the core team has approved this proposal.
The aim is that starting with Home Assistant 2025.6, we will begin a six-month deprecation period.
We understand this change may be disruptive for some, and it was not taken lightly. However, this step is necessary to ensure Home Assistant can continue to evolve and remain maintainable for the future.
Thank you to everyone who participated in the discussion. Your input was essential in guiding this decision.