Feedback requested: Deprecating Core, Supervised, i386, armhf & armv7

frenck · April 22, 2025, 6:23pm

Oh hi there community!

We’re always striving to improve Home Assistant, making it simpler, more robust, and easier to maintain, for you, us, and newcomers. As part of this ongoing effort, we’re proposing a few important changes regarding the officially supported installation methods and architectures.

To keep everything transparent and to gather your valuable feedback, I’m starting this discussion here before we officially finalize these proposals.

What’s the plan?

We’re proposing to stop supporting two installation methods officially:

Home Assistant Core (running directly in a Python environment)
Home Assistant Supervised (running the full stack on your own operating system)

Additionally, we’re planning to discontinue official support for two older architectures:

i386 (32-bit x86)
armhf (32-bit ARM hard float)
armv7 (32-bit ARM)

Meaning going forward, we will only officially support Home Assistant Container and Home Assistant OS installations (which includes VM installations) on the amd64 (64-bit x86) and aarch64 (64-bit ARM) architectures.

Does this mean you can’t run these anymore?

Well for the i386, armhf, armv7 architectures, yes, those architectures become unsuable with Home Assistant, regardless of any installation method available today.

As for the Core & Supervised installation methods: No! You can absolutely keep running Home Assistant this way if you really prefer (although going forward we don’t recommend it).

Both Core and Supervised methods are still actively used when developing Home Assistant and will continue to be possible. We just won’t officially document or provide support for them as recommended methods for production setups. If you know what you’re doing and want to maintain these setups yourself or with community support, that’s perfectly fine.

Why these changes?

Core & Supervised installation methods

Complexity & maintenance: These methods have become increasingly complex and difficult for users to maintain, resulting in frequent support issues.
Low usage: Core (2.57%) and Supervised (3.3%) installations represent only a small fraction of our user base. Maintaining official support diverts resources from the methods most users prefer (OS & Container).
Better alternatives: Most users running Core or Supervised installations can achieve a better, simpler, and more reliable experience by switching to Home Assistant OS or Container installations. Running software and services in containers has become a widely popular and well-supported method across the industry.
Improved first-time user experience: The Core or Supervised installation methods are not the best methods for users to get started, and often reflect badly on our project and community. Focusing our support and instructions on OS & Container makes it possible to streamline the whole initial experience much better.

i386, armhf, armv7 architectures

Very low usage: The i386 and armhf architectures represent less than 0.5% of installations each, armv7 is 0.95% of installations, consuming disproportionate resources in terms of maintenance and builds.
Industry shift: The software and hardware industries have largely moved to 64-bit systems (amd64 and aarch64), and major Linux distributions are dropping support for these older architectures.
Maintenance overhead: It’s increasingly challenging to build and support dependencies and integrations for these architectures.

What will happen if we proceed?

We’ll announce an official 6-month deprecation period.
Users of affected installations will see a repair raised in their instance suggesting they migrate to a supported method or architecture.
We will officially deprecate all integrations that are exclusively designed for–and only able to run on–a Core type installation.
We’ll remove references from official end-user documentation for Core and Supervised methods.
After the deprecation period:
- We will remove all previously deprecated integrations that are exclusively designed for–and only able to run on–a Core type installation.
- For the deprecated architectures (i386, armhf, armv7), we will stop releasing new updates, and existing installations will freeze on their last supported version.

I’m not sure which installation method or architecture I’m running

If you are unsure what exact installation method you are running:

Goto to: Settings > System > Repairs
Next, in the top right, select the three-dotted menu and select System information.

Or use this My Home Assistant button to navigate to it directly:

It will show you a pop-up that contains the used installation method:

The Installation type field will tell you exactly which one it is. If you are running Home Assistant OS, or Container, you are fine. This deprecation proposal doesn’t apply to you.

In this same window, you can find the architecture as well:

The CPU architecture field will tell you exactly which architecture you are using. If you are seeing aarch64 or x86_64 here, you are fine. This deprecation proposal doesn’t apply to you.

I’m affected by this, how do I migrate?

Home Assistant backup & restore features are your friend in this regard. A Home Assistant backup from one system, can be stored on another, even if the source & target systems are a different architecture or installation method. To leverage this, use the Settings → Backups features from the Home Assistant UI.

Before you think about migrating–you can of course–always choose to stick with what you have. Just because it becomes unsupported by the Home Assistant project, it doesn’t mean you can’t keep running it like you do today. That choice is up to you.

If you are currently running Home Assistant Core, the closest installation type would be Home Assistant Container in, for example Docker. But, if you can dedicate your device to run Home Assistant as an appliance, we recommend migrating to Home Assistant Operating System.

If you are currently running Home Assistant Supervised, we recommend migrating to Home Assistant Operating System. Both installation methods support the same things, including add-ons.

Note: In both paths above, if you prefer to have more control on the OS level, you can also choose to run Home Assistant Operating System in a virtual machine–using Proxmox for example.

Frequently asked questions

If Home Assistant Core is used for development, and part of the developer docs, why not just offer it to end-users?
Good question! Technically, you are right–however, it is not just about code or technical viability. It is also about helping and supporting people with their issue, problems and questions, in for example forums and chat. And besides this all, it is kinda a footgun for the less technical people, which reflects bad on the project (and adds to the support load again).
If you really want, you can still run it this way.
If Home Assistant Core/Supervised are no longer supported, I cannot use them anymore?
Well you can, it is community-supported at the point. There are many users running Home Assistant in all kinds of unofficial ways. This change just means we are removing it from our end-user documentation and will no longer recommend using these installation methods from an official stand point.
Will the developer documentation on these things remain?
Yes, those will remain. The developer documentation for running Home Assistant’s Core Python application direct in a Python virtual environment will remain to exists. This is how we develop. This proposal is about removing end-user documentation and support.
Why not make these installation methods community-supported?
That is exactly what this means. We are no longer officially supporting this from the Home Assistant project end; which includes no longer accepting related issues and no longer providing end-user documentation. The community is welcome to pick these up and continue develop and document them elsewhere. So–while we might no longer support these installation methods–that doesn’t mean you can’t keep it running yourself with help from the community.
Can I reproduce any of the installations you offer myself?
Yes, of course! All our pipelines are open source and transparent, you can always recreate any of our pipelines and release artefacts; either automated or manual.
Is this the first step towards making Home Assistant closed source/proprietary/commercial?
No, that is impossible, Home Assistant will always remain open source. Home Assistant is owned by the Open Home Foundation, as Swiss foundation that is audited and governed, and–by law–bound by its mission. This means it will always be open source and cannot be bought or sold.

How can you help?

We’d love your input on this proposal. Your feedback helps us make sure we’re moving in the right direction and haven’t missed anything critical.

Feel free to share your thoughts, concerns, or suggestions below—let’s keep the discussion constructive and helpful.

If you’re interested in the technical details and discussions behind these proposals, you can read more here:

…/Frenck

lordwizzard · April 22, 2025, 6:30pm

Will there be away to convert? (Clear steps to convert?) I ask because I run a HA Yellow which uses Core and Supervised

frenck · April 22, 2025, 6:31pm

I think you are confused about what you are running. One is either running the Core, Supervised, Container, or Operating System method, not a combination of them.

In case of the Home Assistant Yellow, you are (most likely) running the Home Assistant Operating System method, which is not affected by this message.

…/Frenck

lordwizzard · April 22, 2025, 6:41pm

Well I’m confused then:

frenck · April 22, 2025, 6:41pm

If you are unsure what exact installation method you are running:

Got to: Settings > System > Repairs
Next, in the top right, select the three-dotted menu and select System information.

Or use this My Home Assistant button to navigate to it directly:

It will show you a pop-up that contains the used installation method:

lordwizzard · April 22, 2025, 6:43pm

OK

Here is what that says:

Version	core-2025.4.3
Installation type	Home Assistant OS
Development	false
Supervisor	true
Docker	true
User	root
Virtual environment	false
Python version	3.13.2
Operating system family	Linux
Operating system version	6.6.74-haos-raspi
CPU architecture	aarch64
Timezone	America/New_York
Configuration directory	/config

lordwizzard · April 22, 2025, 6:45pm

So I guess that I’m good to go then!

Will await the new developments for HA platform

Thank you very much @frenck

This will help the community figure out what they have!!!

frenck · April 22, 2025, 6:46pm

I’ve updated the OP to include instructions on where to find the installation method and architecture information of your current installation.

cogneato · April 22, 2025, 6:47pm

My feedback would be that, exactly for the reason first shared here, the installation type should be added to the About page before going forward with it.

ShadowFist · April 22, 2025, 6:53pm

I think a migration plan for people who are currently running Core/Supervised would be good info to add to the OP.

The sooner you give people clear ways of migrating (even if it’s just saying “restore your backup” or “copy your config folder”), the better.
It’ll avoid pushback from people who genuinely don’t know how to proceed.

frenck · April 22, 2025, 6:57pm

This is not the announcement; I’m sharing part of the plans we had early here with the community.

That said, we have solutions for that in place for quite some time already: Backups.
Create one, restore it elsewhere: Done

Will take that feedback into consideration with the teams when we decide to move forward with this

Additionally, we will inform affected users on their instance by raising a repair issue on their systems to inform them as well.

ShadowFist · April 22, 2025, 7:00pm

As long as the future announcements & repair issue specifically mention that backups are universal and can be used cross-install, then that’s good enough.

I genuinely had no idea they were universally compatible. Could have sworn one of the install methods still required you to copy over the config folder when migrating to a different OS install.

frenck · April 22, 2025, 7:02pm

Nope, they are universal and architecture independent. So, it is really that easy

knebb · April 22, 2025, 7:34pm

Hi,

I am a really experienced Linux-SysAdmin with decades of experience.

Therefore I initially (obviously) installed HA as supervised version.

But i realized very quickly it is not the preferred version to have HA stable.
Luckily the backup and restore of HA does not take care of the version it runs on, so I migrated smoothless to HAOS as a VM.

Since then I never had any issues with HA any longer.

The very nice backup feature can store to external shares and is really reliable.

So from my point - I still perfer (somehow) the supervised version - but I guess it’ll be more for developers and not for a stable, supportable setup.

So I will agree to discard the support for supervised version and step forward…

Greetings

/KNEBB

NathanCu · April 22, 2025, 7:50pm

So net change.

No more 32 bit (cool, expected)

You can core in VENV if you’re a Linux badass but you’re not supported.
You can run supervised if you like banging your head on things but you’re not supported.

Clarification that you should do HAOS or container for the masses.

Im in.

Hell255 · April 22, 2025, 7:50pm

Hi @frenck, Hi everyone, I’m right now using Home Assistant Supervised on x86_64.

The supervised installation enables me to run Home Assistant on my Synology NAS in a docker container. Would be unhappy to leave this setup, as it has perfectly worked for the past years.

Or – is there a way to migrate this to another kind of supported HA setup?

Mikefila · April 22, 2025, 7:53pm

Maybe add migration instructions for those running 32 bit versions on 64 bit hardware. With the change to node red and esphome, there have been a handful of ppl unknowingly running the 32bit version.