MichaIng
Home Assistant Deprecating Core and Supervised installation methods, and 32-bit systems
Well – this is bad news... We have time until Home Assistant 2025.12, and then it's over and out with updates :(
Source: Home Assistant Blog – May 22, 2025
🚫 What’s Being Deprecated?
Installation Methods:
-
Home Assistant Core(Python environment) -
Home Assistant Supervised(Supervisor on own OS)
CPU Architectures:
-
i386(32-bit x86) -
armhf(32-bit ARM, e.g., Raspberry Pi 1) -
armv7(e.g., Raspberry Pi 2)
🗓️ Timeline
| Date | Event |
|---|---|
| 2025.6 | ⚠️ Deprecation warnings start |
| 2025.12 | ❌ No more support, updates, or bug fixes |
✅ Recommended Alternatives
- Home Assistant OS: All-in-one solution with full features and add-ons.
- Home Assistant Container: Docker-based install for more flexibility.
🧐 How to Check If You're Affected
- Go to Settings → System → Repairs → System Information
- Look at:
-
Installation Type (
Core,Supervised) -
CPU Architecture (
i386,armhf,armv7)
-
Installation Type (
🔁 Migration Guide
- Create a backup
- Set up a new instance (Home Assistant OS or Container)
- Restore the backup
- ✅ Migration supports architecture changes (e.g., 32-bit → 64-bit)
💬 Why This Change?
- 📉 Very low usage: Core (2.5%), Supervised (3.3%), 32-bit (<1%)
- 🛠️ High maintenance, not worth the effort
- 🚀 Focus on future-proof, stable systems
❓ FAQ
Can I still use Core or Supervised?
Yes, but it’s no longer supported after Dec 2025.
The information has to be interpreted a little differently. Their own OS and container still uses Home Assistant core, so of course it can be still installed manually, updated etc. What the change actually means is that for a custom HA core installation, there is no support by the HA team anymore, and no documentation for it. This however practically does not change much: HA made it already somewhat difficult with very strict and edge requirements for Python and modules, which lead to:
- A lot of huge by default unnecessary dependencies, which pull a lot of build dependencies on 32-bit ARM and RISC-V, and require constant maintenance for a HA core integration like ours.
- Often breaking HA installation between DietPi updates, as of raised of changed dependencies.
The HA team pretty much ignored any raised topic in this regards, focusing on functional HA OS and HA container, which both come with additional integrations, features and dependencies, not required by/wanted for a minimal HA core implementation. It just makes sense to turn this practical limitation of custom installs into a formal one. For us/me, at this point, it changes literally nothing: Breakage was usually found by user reports, or own random install tests. And fixes were derived from error messages, and the HA core source code.
That 32-bit support is dropped however indeed changes things a bit, as there are still about 15% of such among reported DietPi systems, especially the Raspberry Pi Zero W is still widely used. But on the other hand, those are not powerful enough to run HA nicely, and the installation and updates takes ages, also as a lot of Python modules need to be additionally compiled. I'll try to query our survey database about how many 32-bit DietPi systems have HA installed.
- However, while the HA team does not provide binaries/releases for these architectures anymore, it also does not mean that they will stop function immediately. However, it is then possible that HA implements 64-bit only features or methods at some point, which can then break full functionality on 32-bit, or spinning up HA at all. But we can just keep it enabled until we actually see it breaking with some version. Then we can pin it to an older version for a while, before removing the option for 32-bit entirely.
Thanks for your feedback. I just wanted to post it here for information. We'll see where things go.
Here the 52 reported 32-bit ARM systems with Home Assistant installed:
1x Generic Device
3x Generic Allwinner H3
2x NanoPi NEO Air
1x ASUS Tinker Board
1x Odroid C1
1x Odroid U3
7x Odroid XU3/XU4/MC1/HC1/HC2
1x RPi B
1x RPi B+
1x RPi Zero
6x RPi Zero W
2x RPi Zero 2 W
10x RPi 2 Model B
9x RPi 3 Model B
3x RPi 3 Model B+
3x RPi 4 Model B
At least 17 of them could run a 64-bit image. The Odroid XU4 instances are probably the only ones which are still well supported, generally often used, and cannot run 64-bit.
However, taking into account ~14% dietpi-survey participants, it can be well between 300 and 400 overall. At least worth to keep up 32-bit support for HA out end, until users face actual issues.
would it be possible to provide and official container installation method along with the current python envelope method? There are many good low cost hardware options that can run the extra load. would DietPi be able to run this container option or are there conflicts like NetworkManager, etc.
Of course you can run any container on DietPi with any Docker engine. The official Docker container works just fine. It is the light HA core installation with is now not only practically, but also formally our own maintenance efforts.
Thanks for the info. I'm running DietPi on a NUC with HA core and nothing else. I'ts a dedicated system for HA. I like this method and yes, sometimes things are broken after an update from HA. So I can just continue using the same update procedure within DietPi from version 2025.12?
So I can just continue using the same update procedure within DietPi from version 2025.12?
Yes
For me this is also bad news - I am running homeassistant among many other services on a RaspberryPi3 with just 1GB of RAM. Unforntunatly because written in python, home-assistant is quite memory hungry - and I use the 32-bit armv7 containers to conserve memory despite running 64-bit raspberry pi os as python's inefficiencies seem to be less servere when using a 32-bit data model.
I just did a quick check to get the size of an empty python object:
import sys
class EmptyClass:
pass
empty_object = EmptyClass()
print(sys.getsizeof(empty_object))
python 3.13.7 on armv8: 48 bytes python 3.13.7 on armv7: 24 bytes java 25 default on armv8: 12 bytes java 25 compressed objekct headers on armv8: 8 bytes
So while runtimes like Hotspot for Java have developed many clever tricks to reduce the impact the larger pointers have on their typically very pointer-heavy memory model (compressed object pointers, compressed class pointers, more compact object headers), python seems to be not only even more pointer-heavy but also it seems it didn't to anything to hide the negative consequences when running on 64-bit.
By looking at the numbers above, my guess is HA on armv8 uses at least 25-35% more memory compared to armv7.
my guess is HA on armv8 uses at least 25-35% more memory compared to armv7
Did you compare two actual containers? That you are using containers at all will add like 200 MiB memory consumption for engine and container environment overhead or so? Maybe try a bare metal HA on 64-bit.
IMO 32-bit is dead. The last months, a whole lot of software options either intentionally or unintentionally (pulling 64-bit only dependency updates) lost 32-bit support. Not sure what triggered it, maybe time64 transition of Debian and other distros played their part, but it was a very significant acceleration. We were able to bring back 32-bit support here and there, e.g. on Nextcloud thanks to quite some argumentation efforts the last years, but this new wave is much too large to keep fighting against. Well, for Koel I managed to bring it back some days ago, because nothing explicitly depended on a new 64-bit only version of one dependency, but that was an exception. Means, as an admin, I would rather invest time to deal with 64-bit implications (like higher memory consumption, which I can confirm as significant e.g. for PHP and OPcache), then trying to keep alive 32-bit software support, while my hardware does actually support 64-bit.
However, in case of HA, so far while there is no end user support for 32-bit setups anymore, it still works. It may break any time, but so far Python has been sort of resilient, even for armv6l, making https://piwheels.org/ possible.