I used to use Core - I’ve been using *nix for decades now.
Docker just makes it easy. Pull the new image, recreate the container with it.
I now use Docker for everything - HA, Mosquitto, Zigbee2MQTT, etc, etc, etc. I’m never going back 
Ok, so it will have dependency issues at times, but it should still be the most compatible.
I am not saying that other variants of Linux cant be used.
I run true, stable Debian versions only. Back in the day, I did run on a Pi, but I had too many dependency issues outside of HA, like running ffmpeg properly. Like you, I’ve had to build some packages locally.
1 Like
Just to be sure - maybe stupid question - but by “I now use Docker for everything” you mean you create one Docker image with all those parts included, or you have separate Docker images for each one?
And when doing upgrades (of any component) you just recreate the corresponding Docker image?
Separate containers for each:
CONTAINER ID IMAGE COMMAND CREATED STATUS NAMES
8773318ce712 eclipse-mosquitto:2 "/docker-entrypoint.…" 2 days ago Up 2 days (healthy) mosquitto
5d470fc6da57 lscr.io/linuxserver/piper:latest "/init" 7 days ago Up 7 days piper
965ef3feb6a3 amir20/dozzle:latest "/dozzle" 7 days ago Up 7 days dozzle
0c275eeb805c ghcr.io/home-assistant/home-assistant:stable "/init" 2 weeks ago Up 2 weeks (healthy) homeassistant
68bce9aa0f7f caronc/apprise:latest "/opt/apprise/webapp…" 5 weeks ago Up 5 weeks apprise
f40eeacf35a3 ghcr.io/blakeblackshear/frigate:stable "/init" 5 weeks ago Up 43 hours (healthy) frigate
92d0f429cb7c koenkk/zigbee2mqtt:1.39.0 "docker-entrypoint.s…" 2 months ago Up 2 months (healthy) zigbee2mqtt
1f194cde69ff crazymax/diun:latest "diun serve" 6 months ago Up 6 months diun
bc082c1b5204 ghcr.io/rafhaanshah/container-mon:latest "./app" 9 months ago Up 9 months container-mon
...
At update time it’s just:
docker compose pull homeassistant
docker compose up -d homeassistant
(replacing homeassistant with the container being updated
Container healthchecks allow me to be notified (via container-mon) if a container becomes unhealthy:
homeassistant:
container_name: homeassistant
image: "ghcr.io/home-assistant/home-assistant:stable"
restart: unless-stopped
volumes:
- /data/homeassistant/.homeassistant:/config
- /data/apprise/:/data/apprise
- /usr/share/zoneinfo/Europe/London:/etc/localtime:ro
network_mode: host
# Wait up to 2 mins for shutdown
stop_grace_period: 2m
healthcheck:
test: ["CMD", "curl", "-fs", "-S", "--max-time", "2", "http://localhost:8123/"]
interval: 30s
timeout: 10s
retries: 3
2 Likes
Just for the record, here is the answer to my question about the Python 3.12 installation on Debian (bookworm).
It comes from the 3rd party repo, but have binaries for the most popular platforms, apart from x86-64, also for armv7 or arm64 
.
I build my own, as Debian never keeps up with the version HA needs to run.
Once the venv is built, I just run an update script whenever a new version comes out. Moving between venv versions of python these days is pretty simple, done it so many times.
HA Supervised is only supported to run on Debian, so why would this be different for HA Core? What I mean is: If HA Supervised is literally guaranteed to run on Debian, why wouldn’t HA Core?
Supervised only works on Debian
Core works on any Linux (that has the right library versions)
I know, but that’s not my point.
Callifo claimed that Debian doesn’t keep up, but Debian is good enough for Supervised – and officially supported. Their claim seemed to be without justification.
That’s because you’re not seeing how different those two methods are.
-
Supervised depends on a number of packages, including Docker and systemd. Those packages have to be the relevant version for it to work.
-
Core runs on Python. Your Python install depends on dozens of OS packages, like FFMPEG. All of those have to exist, and be in the right range of versions, and Python must be built against them.
Supervised is managed to run on the documented version of Debian.
Core is not. Core is developed against the relevant versions of packages to make it performant and stable. That means it often is ahead of what Debian (or any OS) ships with. Python 3.13 will be a requirement before most OSs ship it, FFMPEG was bumped before most OSs shipped that new version too, etc etc.
They ship container images that include the required versions. For Core it’s on you to ensure that you manage that.
TL/DR: You’re comparing a mod kit for a Mk6 VW Golf to a kit car where you have to source or make half the parts yourself.
2 Likes
I’m familiar with this – in particular building FFMPEG for this purpose. I run HA Core myself (and not Supervised).
The bit I didn’t know was that Supervised used Docker:
So, with this in mind, I can see how such an installation is better buffered against resolving difficult dependencies, making the need for a specific Debian version for the Core part basically irrelevant, but the Supervised components are tightly tied to it. Each have their set of dependencies, and those aren’t the same.
Thanks!
1 Like
I believe the “dependency creep” is an unfortunate strategy. I can see why it appeases to the devs - breaking dependencies and breaking the system at a whim, but it will backlash in the long term.
Anyway, Debian it is, pulling (or building) external deps should not be a problem on the new hardware. I am however caution about how things turn out. It seems that over the past few years the focus from open and flexible started to shift to closed and locked.
As explained above, it was mainly Python. Current Debian python version = 3.11. Minimum HA python version required = 3.12.
I run Python 3.12 which I compile myself for each new 3.12.x version. When HA moves to 3.13 eventually, I will just build a new 3.13 venv and migrate over.
1 Like