📣 Home Assistant Core will be deprecated starting August 2025 – please migrate

[MickLesk]

📣 Home Assistant Core will be deprecated starting August 2025 – please migrate

As of Home Assistant 2025.6 (expected June 2025), the official 6-month deprecation period for the Home Assistant Core installation method (Python/venv) begins. After August 2025, Core will no longer receive updates or official support.

We strongly recommend migrating to one of the supported installation methods:

• ✅ Home Assistant OS (recommended for most users)
• 🐳 Home Assistant Container (for advanced users familiar with Docker)

---

🗂️ Migration is now easier than ever:
Since Home Assistant 2025.1, backups can be restored across all installation types, including from Core to OS or Container.

🔗 Migration guide and backup system info

---

Please plan your migration ahead of time to avoid running an unsupported setup.
This notice will also be integrated directly into the affected install scripts.

— community-scripts maintainers

References:
Community-Scripts: #4489 & #4487
Official Response: home-assistant/architecture#1197 (comment)

[dmshimself]

Thanks for that. I used your podman home assistant script to create a new HA instance restoring a previous backup on the way and everything came good very easily.

[k5madsen]

I just discovered this posting ... I will need migration advice. I currently have Home Assistant v 2024.5.5. I can't update because my installation is Home Assistant Core built on an LXC container using Debian 12 (NOT Ubuntu). Will I be able to migrate using my backup?

[jennilicious]

It's very easy to use the built-in Home Assistant backup feature (version 2025.01 onwards), and re-upload your backup file after spinning up the new container. I migrated from core to container (Docker) and it took 5-10 minutes.

[MickLesk]

But he has an very old Install on Debian 12. So you cannot upgrade to newer because Python3 Issues.

[k5madsen]

Mark me down as an unhappy camper. I missed the chance to update, guess I'm spoiled by other apps & systems that prompt for updates. I don't have too many customizations, but I have to remember what I've done. I've just put in a fair amount of time organizing my dashboards.

[jennilicious]

@k5madsen You can still update. It's just not as automated and does a requires some of manual work, but not as bad as you think.

Turn off your HA LXC, and change its IP address. Then turn it on again and start a second HA Core LXC by running bash -c "$(curl -fsSL https://raw.githubusercontent.com/community-scripts/ProxmoxVE/main/ct/homeassistant-core.sh)" your Proxmox VE Shell (Use the advanced function to input the original IP LXC address).

Turn on your original HA LXC and run this helpful script mentioned by MickLesk to copy HA data to the new second LXC running Ubuntu. I used this to migrate from Debian to Ubuntu a few months back and it works.

From there, you can now use the internal HA backup tool to get a backup tar file. You can spin up a third HA Docker Container LXC and re-upload that backup tar file and you should now be up to date on Docker going forward. You can delete the first and second containers once everything is okay.

[k5madsen]

Thank you @jennilicious ! I had to search around a bit for the copy script, but it appears to have worked and I now have an LXC container with HA v2025.5.3.

I'm going to let that settle a little while before I make the next conversion.

Kent

[Patrick010]

I'm running HA Supervised for years now without any issues. Makes it hugely more flexible than the official HAOS.
Maybe a script for this? Can be daunting to install for beginners.

https://community.home-assistant.io/t/installing-home-assistant-supervised-using-debian-12/200253

[tremor021]

Its getting harder and harder to maintain the installation methods mentioned in the link @MickLesk showed you, they are only making most rational decision to deprecate those install types, so they can focus on maintaining the methods that are easier and produce less bugs.
All this makes sense, they don't really aim on making decisions for you. We also often abandon scripts that have proved to be a nightmare to us and to the end users.
This also benefits you as a end user, because they will have more focus on less problematic product, hence improving the support and troubleshooting if something really goes wrong.
It's a good move, just use the docker variant and you should be fine for foreseeable future

[Patrick010]

But I hate Docker 🤣

[MickLesk]

And what speaks against the OS? The only thing I would sometimes criticize is the ram consumption, but I have a weekly cron to reboot the vm. Been a beta user for 2.5 or 3 years, never had any (serious) bugs or failures per se

[tremor021]

Yea, RAM usage is obvious difference, but if the app is doing all that it should without a problem, then its worth it IMO

[Patrick010]

I don’t use it because for me it complicates things. I don’t need a container inside a container that just makes passing through devices like USB sticks, Coral or GPUs way harder than it needs to be. I also don’t need another abstraction layer sitting between me and my apps.

I don’t need a network inside my network either. Docker loves creating its own bridges, NATs, and virtual switches for no reason, and then I’m wasting time figuring out why containers can’t talk to my other services or why I have 5 interfaces doing who knows what.

I don’t want to deal with volume mounts and UID/GID mismatches just to get files into a container.
I like my services running as proper systemd units. With Docker, that whole process supervision gets bypassed unless I patch it together myself. Logging turns into another mess too. Some logs go to docker logs, others into random volumes, nothing shows in journalctl.

I can snapshot a VM cleanly and know it works. With Docker, now I have to worry about what’s in the container, what’s in the volume, what state it’s in. Backup reliability goes out the window.

Security-wise, it adds more stuff that can go wrong. Now I have to trust the container image, the daemon, the configs, and the permissions for the volumes and runtime. All for what? To run a single process?

Docker’s resource limits are just redundant. The VM already isolates CPU, RAM, IO, and devices. No need for nested sandboxing that adds more overhead.

And honestly, when something breaks, it’s a maze. Could be the VM, could be the container, could be Docker’s network, could be the volume mount, could be the image.

It’s also more stuff to maintain. Now I’ve got to rebuild images, keep track of image versions, worry about upstream breakages, maybe write Dockerfiles for things that I could’ve just installed with apt or pip.

Docker’s “portability” doesn’t help here either. I’m not running 10 OSes. I’ve got a VM running exactly the environment I want. No need for Docker pretending to solve a problem I don’t have.

Unless you’re running a cluster or need real container orchestration, it’s just complexity for the sake of it. I’m running apps, not rebuilding Google.

[gcortes]

I'm running the Core version and plan to move to the OS version. In the instructions for Home Assistant OS, it says:

The disk must have a minimum size of 32GB and its size cannot be changed during the creation of the VM.

Is this a question that's asked when the script is ran or is it something I need to do before hand? Could it be reference to disk space attached to the PVE? I have close to 4TB available.

There is a place to enter a config file location. What is for? Is it required?

It also says it's not updatable. Is it the case that updates are handled within the image itself and therefore unnecessary?

Is there additional documentation on the install process?

[MickLesk]

Default Install - dont ask you, you can later add more Space into VM

Config File (If you mean thus) is in this case not needed.

Copy Scriptbash, Execute in Proxmox Host, and follow the 2 or 3 steps for storage & done

[gcortes]

Thanks. I got it up and running from a backup restore from the old Core instance.

An FYI for others, I had to do an advanced setup to specify the network on which my IoT devices run. I also set the IP address to the be the same as the old system. The address is used by other instances, such as Nodered and InfluxDB.