Is it possible to Supervised HA on Docker ?
How to do it with docker-compose ?
No - the only supported option is this one, and you have to read and follow the requirements exactly.
If you’re using Supervised to allow you to run other software outside of add-ons then you’ll immediately be ignoring the requirements and will have a system that’s unhealthy and unsupported. Things will break.
Thanks for answer.
If I install Core version on Docker, how can I reused all I have done on Supervised ?
Is It possible to backup on Supervised and restore on Core ?
Only supervisor can restore backups. Core can make a backup but it’s really only to help people that want to migrate to an HAOS or Supervised install since core cannot restore them by itself.
It sounds like you already have a Supervised or HAOS setup, why are you changing it?
Currently I use a NUC under Proxmox (and Fail2ban) with:
- 1 VM for PfSense
- 1 VM for Home Assistant OS
- 1 Debian VM for Docker
I wanted to put on Docker things like ESPHome, Graphana, Influx DB, Frigate, …
I thought the easiest way would be to put Home Assistant under Docker too, but I think the Supervised version does not exist under Docker.
Maybe I can keep my VM for Home Assistant OS and put on Docker ESPHome, Graphana, Influx DB, Frigate?
The main difference between supervised and core/container is that core does not include the addons.
However, most addons have a standalone docker equivalent. What addons are you using currently?
Backups also work different. You can backup home assistant container by just backing up the config folder. There’s a lot of ways to do that- you can use another backup program/container like duplicati.
Updates are different as well- you have to manage them yourself (pull new docker image, remove old container, rebuild with new one)
Since you seem comfortable using docker already, it might be worth it. On the other hand, the nuc should have enough processing power to be able to handle the 3 VMs if you just want to go that route.
2 Likes
HA Supervised is a version of a HA installation that runs under Docker in the background. The typical user never even knows it’s the case. But every function of HA Supervised is running in its own Docker container.
If you install the Portainer add-on you can see all of them.
Add-ons are also all running in their own Docker containers. However in HA Supervised the Docker containers (add-ons) are controlled exclusively by the Supervisor (which is also running in it’s own container).
Not that I’m necessarily directing you to Supervised (I don’t use it myself) but I’m pretty sure all of those things can be installed by the Supervisor as add-ons.
If there are apps that aren’t supported by Add-ons then you could move to HA Container and manage everything on your own. It’s not that hard at all if you understand Docker already.
The only things that Supervised gets you are Add-ons - which you don’t need at all if you know Docker - and restorable backups - which again you don’t need since you can just backup your entire config directory and all of the HA configuration will be backed up with it.
You will need to back up your other Docker configs independently tho. Again not a big deal if you know Docker.
3 Likes
That begs the question, why isn’t there a Supervisor Docker Container? That would solve this problem entirely… & it’s essentially already how it works…
We just need a Portainer Supervisor container to run in Real Docker next to all the containers, then it can be the Portainer for all the Home Assistant Add-on Containers. Which is essentially already what it is, it’s just locked inside a cage so those not on Debian cannot use it for some reason
That’s not all that is needed.
there is also a Supervisor service that runs on the host that does some other stuff as well.
Plus all of the other supporting containers that the supervisor creates - which could created by the service instead of the container?
and there could be other requirements that I don’t know of.
I’m not saying it couldn’t be done. But there is no motivation for the devs to do it.
1 Like
Because the Supervisor stack (yes, it’s more than just one container) has a bunch of requirements. The Supervisor is intended for use with Home Assistant OS, but the community really wanted to be able to use it on their own OS.
As a result the developers have done the necessary work to ensure it runs on Debian (Bullseye at this point of time), with very specific requirements met. To expand support would significantly increase their workload, so they’ve asked the community to help… and mostly been ignored.
There is a lot of history on this server if you search for it.
3 Likes
That’s interesting. I didn’t know that the Community refused to help. I’m definitely no programmer, but any work I do to make this a reality I’ll be sure to share so those more skilled only have to clean it up.
I personally don’t get why, if it’s based on Docker in the 1st place, it was made to subvert Docker conventions, it appears to me, from the information I’ve found, to be solely for the purpose of making it not compatible, but I only know what I’ve found, nothing more, so I’m sure that wasn’t the intention, I just can’t see anything else because that’s where the information at hand points.
If you know could you share the parts of the stack? Because if I know that it’s much easier to make it work
The point of the Supervisor is to make it easy for people who don’t know Linux or Docker to run Home Assistant. It’s supposed to be used as part of Home Assistant OS where you never really see Docker. The Supervised installer exists through a quirk of history and was a mistake.
It’s not made to “subvert Docker conventions”, it’s a Docker manager (like Portainer) that tightly integrates with the OS to also allow you to manage the host OS (to a limited degree when not using Home Assistant OS).
You’ll find some of it on the developer site, some in the architecture repo, and the rest in the source. Plus countless discussions here and on Discord.
I think that is greatly overstating things.
The community didn’t “refuse to help”. The statement was “mostly been ignored”.
I think that’s likely because most of the community doesn’t have the technical expertise to write code or maintain the infrastructure for that type of an installation. or any type of installation to be honest. I know I don’t. That’s why we use HA. because it has developers dedicated to maintaining and updating the source.
I’m no coding expert, in fact my only real coding skills are finding errors & modifying pre-existing things to make them work in unique situations. Like back when Mac stole & broke the usage agreements & started selling their closed up version of Unix it was “impossible” for the old OS apps (which ran in a virtual machine OS9) to access things like printers. I’m not a Mac person, but I made it work by figuring out what the problems were, what resources were available, & using those to make it work.
To me if people aren’t willing to put in effort for something they want, but they will ask for it, complain about it, etc, that “Ignoring” when the people asking for it are asked to help, is the same thing as a refusal to help.
From my experience here most of the community are high-minded & act like “oh you don’t know that, you are so beneath me” to anyone asking questions about things. Most usually answer in ways that seem intentionally designed to only be understandable by those who already know. So I assume most are more code knowledgeable than I am… As far as having the expertise to maintain the infrastructure, it sounds like they were asked to help, not do it themselves, those are 2 completely different things. I recently modified a Sigil plugin because I wanted it to do more than it already did. I’m sure my code is sloppy & very inelegant, but I submitted it, then the original creator, or others, will clean it up, maybe continue improving it. I don’t have to maintain it, I just helped, because I wanted it & others might too.
But all that could have been done without changing things. Like the config.yaml is pretty much just a .env file + Run/Compose ENV variables + Docker Build --build-arg list. There’s no reason to make it separate & run differently. & the BUILD_FROM could have been done in the standard docker multi-arch way, but for some reason is done differently, the only thing that really accomplishes is making it so the Dockerfile won’t run on Docker. Integrating with the Host OS could also be done in regular Docker it’s just frowned upon. So why were those changes made? They don’t seem to add anything to it, they only seem to make it “different for the sake of being special” as it were.
All that could have been done without changing how the build goes. I can actually think of ways it’d be even easier while still maintaining the Docker structure. A GUI to build would be one. Or have the build.yaml & config.yaml for entry & have them referenced in a single, uniform way to start the build with arguments rather than alter the way the build works to use the build.yaml file. (Though I do like that it can do that, that alone I’d call an improvement to the Docker build system that cannot use ARG or ENV from a file)
I could, with my limited knowledge, patch together a Dockerfile + Compose to work as an add-on, but doing the opposite seems to require a complete rewrite. So there was enough changed but no necessary reason to do so. Thus “made to subvert Docker conventions”
I’m running ha supervised inside alpine container
1 Like
Thanks, I’ll definitely take a look at that, it should help. It still looks like it’s an extra layer as a container inside a container, hopefully we can get it next to instead. But that’s at least something to work with
I’ve been looking for the same thing. Would love to add Homeassistant Supervised to my TueNas Scale docker containers. VM for now I guess until someone wants this bad enough to make it 
I was able to run ha supervised on Android(with kernel for docker) in chroot alpine linux environment. No proble to run several docker daemons in different mounting namespaces.
Hello @Patrice59, how you ended up with your installation?
I was expecting to do something similar to what you want to do… Have a NUC with only one OS and dockers containers to run things …
Thanks
Then just use a Container install.