As you may know, the Supervised installation method has been deprecated.
So, I built haos-one : a single Docker container that runs Home Assistant OS with Add-ons.
No dedicated hardware or VM needed.
For ex-Supervised users who want full-featured Home Assistant running next to other services.
Try it:
docker run -ti --privileged -p 8123:8123 \
-v ./data:/mnt/data \
qweritos/haos-one
Works on x86/ARM hosts, supports rootless containers
Feedback welcome.
Glad if you find it useful!
Hi everyone,
I wanted to share my challenges for anyone considering migrating their Supervised installation to the new haos-one Docker container, specifically if you are running on Linux (Ubuntu/Debian) and connected via Wi-Fi.
I spent the last few hours trying to get this working and hit a major roadblock that leaves you stuck between ācrashing your networkā or ābreaking your devices.ā
The Problem:
network_mode: host. On my Linux machine, doing this caused the container to hijack my hostās network interfaces. It literally renamed my virtual interfaces to eth0, killing my SSH connection and taking the host offline. I had to restart to recover.Summary:
If you are on Ethernet, you might be fine (or maybe Macvlan works for you). But if you are on Wi-Fi, be very careful. haos-one seems to try to manage the underlying network hardware in a way that conflicts with the host OS, and there is currently no easy workaround to get local device control (Govee/Matter) working without risking your host connection.
Just a heads-up before you start your migration!
Check your router. Some routers apply restrictions routing between WiFi and Ethernet.
@John27 , Yes, you can move your existing data (devices, addons, state history, etc.).
Basically, you can back-up&restore via internal hass mechanism.
Check the Migration section in README.md:
@parautenbach, Itās known issue that in-haos NetworkManager can mess up your host network, but it cannot just be disabled - hass will complain about āno internet connectionā and may cause other problems.
@Laurynas, itās possible to overcome with network_mode: host and by setting correct static IP address in homeassistant network settings page & reboot, so in-haos nm settings be aligned with host settings.
Iām working on this issue now, there will be stub service - drop-in dummy replacement for NetorkManager.
Can we use it on synology?!
I havenāt tried yet, need to verify this.
If you could apreciate it!
Would love to put in my NAS hehe
Very interested in trying this as currently running Supervised on a PC running Debian along with Portainer and a bunch of other stuff.
Iām assuming this is okay to run on the same box and just stop all the containers of the other install?
Also, Iām not entirely sure if I should run the docker compose using -p 8123:8123 or --network host
Currently running 2025.2.3 so guessing first thing is to update that. It just works for me so I rarely update.
@whatisk yes, you can spin up another instance next to existing one, just avoid any possible collisions - use different ports, volumes, etc.
After migration (see Migration section in readme) you can switch primary instance to a new one and shut down old.
You can run it with just -p 8123:8123, but if you need to have functional network autodiscovery features or to passthrough hostās bluetooth adapter - use --network=host.
And yeah, its better to upgrade beforehand, and confirm that everythingās work well on your effective instalaltion.
@thamathar I checked (in VM), and turns out its not possible for a really weird reason: even latest DSM 7.3 still runs the ancient Linux 4.4 kernel, which is around 10 years old (why the heck?!) - and as a consequence it lacks of many required features.
So, seems like the only option for HAOS on synology is to use VM (VMM app?) and official disk image.
Thanks!
But a VM on it at the moment will be impossible since I just have 4GB memory in the NAS
Thanks. Was a little confused around the difference as pretty sure on current install I just used ā-pā.
I seem to have sorted network dropping issues with the Proxmox server Iāve been setting up so will look into this more. I thought PM was freezing and needed a reboot at random times but ended up being an obscure known issue with the particular network adaptor in the NUC.
Hopefully, itās not related to issues described by @Laurynas in
Before, there was issue when container network takes possession of hostās network, making server unreachable - but it was fixed while ago, and if it still relevant for you - update image with git pull qweritos/haos-one:latest before run it.
Is this still an issue? I was having trouble with the bridge network and switched to host network which immediately blew up my ethernet / networkmanager.
Iām in the process of upgrading to a new server so it wasnāt too terrible, but kind of frustrating.
The supervisor wouldnāt start and/or connect to the internet with bridge network mode.
Any solution?
Run it with env var USE_DUMMY_NETWORKMANAGER=1 like so:
docker run --name haos -ti --privileged -p 8123:8123 -e USE_DUMMY_NETWORKMANAGER=1 qweritos/haos-one
(Iāll make it enabled by default after some testing - yet iām not 100% confident about this decision)
it will enable spin-up of fake networkmanager to satisfy hass demands. (for now, it will show Unsupported software warning - safe to ignore: its because fake NM running in container unrecognized by hass; iāll fix it later just to suppress this waring).
And @eevans, I would really appreciate it if you let me know whether this help and it doesnāt cause any other issues.