How to run home assistant supervisor in a docker container

Installation
21

So, as I’ve been looking for a similar thing, let me explain a bit of what I’ve learned in a more Docker-centric way

HA Supervisor is essentially Home Assistant’s Portainer while the Add-ons are each a container within Home Assistant’s own internal Docker. That’s not 100% accurate, but it explains the concept in a way those familiar with Docker can understand.
So installing Home Assistant with Supervisor is akin to installing Docker with Portainer so installing HA Supervisor is like installing Docker then installing Docker & Portainer in a single Container running within Docker then each add-on will be running inside that container, inside the HA Supervisor container, inside the Docker program. Running Docker on Windows in WSL2 already creates problems having a Virtual Environment inside of a Virtual Environment, but adding 3 extra layers is just asking for trouble. I’d have an add-on running in a container on a supervisor container on a docker environment running in a container on a docker environment running on a WSL2 environment on windows… Now sure, that’s the extreme case, but it just emphasized the point.

Now what I’m trying to find is a way to have the Supervisor container ONLY to run next to Home Assistant, similar to how I run Portainer, since I cannot find a way to integrate regular containers into Home Assistant the way those in Supervisor do. I don’t need things to run inside the Home Assistant Docker, just to have a manager that I can use

2 Likes
22

The add-ons aren’t running within the HA Supervisor container; they’re running alongside the Supervisor (and Home Assistant Core) containers.

What exactly are you trying to accomplish here?

1 Like
23

That’s purely a semantic argument as they are running in an isolated docker environment. Whether that environment is part of Supervisor or, from my understanding part of Home Assistant itself, or a completely separate entity doesn’t change anything. From the information I’ve seen it is clear that the addons run in Supervisor are running in a 2-level isolation, so adding another gives 3-levels, however it works on the inside is an Ear-Elephant.
I even said

As for

Running the Dockerfile for a HA Add-on doesn’t give the same things as running the add-on, in many cases the Dockerfile has to be modified just to run. Even when done they don’t integrate into Home Assistant the same way, or at all.

This is a problem I’ve run into on multiple occasions. But right now I’m working on trying to get an iFrame to show a local page not just tell my browser to show a page. I don’t want to have an exposed port or DDNS for certain things that don’t have any good security, like a Cron Manager, but have the potential to do a lot of damage.
In Another Thread it was brought to my attention that this can successfully be done with the use of the Frigate Proxy add-on. It’s intention is to make it so you can access Frigate docker container without running it in the Frigate Add-on. I am attempting to modify the Dockerfile & config.yaml files to replace them with ENV Variables so that they can be used to add a UI of your choice by changing the variables. But without Supervisor there doesn’t seem to be a way to get it into Home Assistant. If, however, I could run Supervisor as a container in Docker, map all the relevant paths it needs to communicate with Home Assistant, then run any Add-ons in a stack with it I believe I should be able to accomplish what I need & potentially more, as I have ignored a lot of things when they say Supervisor is needed or to go to the add-on store, unless it’s HACS.

24

It’s not a semantic argument. You said the add-ons are containers running in a container which is 0% accurate. All of the containers, including the add-ons, are a single “layer” of containers that run alongside each other.

As far as your other point, why not just run HA OS on bare metal or in a VM (or HA Supervised, but that’s really not recommended)?

1 Like
25

I don’t know the particulars, as I don’t have that version, but I know that an add-on passes through 3 points before it gets to the outside world. The stuff running on Home Assistant passes through 2. So however it works they are not parallel. I didn’t run it myself as I have said, I don’t run it myself, so I cannot really tell you more.

I run a Windows server already. I have no desire to run a separate machine to run home assistant. As far as the VM, I think that’s a dumb argument as well, & I don’t want it to be completely separate, nor do I want to waste resources with a VM, I actually don’t run it in docker either, I found a “Portable” version that runs well as a stand-alone app in Windows since Running in WSL2 has problems with networks & working properly especially with detecting devices. My setup has a very low footprint, & works well with all my Docker Containers, something I’ve also heard running HA OS in a separate VM can cause problems with.

I also want to have more control over my containers than HA OS lets you have, & I’m already running Docker, with plenty of containers, & if Supervisor really sits next to the containers, similar to how Portainer works, & just manages the handling of the Add-On Containers & how they integrate into Home Assistant, there’s no reason why it shouldn’t be able to run as a regular Docker Container aside from an invented limitation to emphasize what someone thinks is a better option.

26

An iframe by definition is just a pointer to the browser, it sounds like you’re really looking for a proxy.

27

No, that’s not how it works. I’d love to see a link to where you got that information.

28

Yes, and no at the same time. A proxy in the traditional sense redirects something, so that would require the thing it being redirected to to be accessible. That’s what I need to avoid. if I setup NginX to tell anything that hits it looking for myface.duckdns.org to go to 192.168.1.200 then anything outside coming in has access to it. I can’t have that. Apparently the Frigate Proxy Add-on does what I want, supposedly, & it does utilize NginX to do that, but a little research told me that by doing that it prevents that NginX from doing what it is normally intended to do.

What I need is for it to redirect, or proxy, to an address that if I was in the local environment would be correct, but is not accessible outside of the Local Network

29

Addons like the frigate addon use ingress UI. What that usually means is the UI of the service is accessible to logged in HA users as part of the HA UI.

Im going to borrow a screenshot since I was just talking to someone about this addon in another thread. It looks like this:

You can see how there’s a frigate nav option in HA and it opens within HA. You’d also notice if you tried it that you were never prompted for authentication when you opened frigate (or you shouldn’t have been, I don’t use frigate so I can’t confirm it does this part correctly). That’s because HA addons using ingress are supposed to be accessible to any logged in HA user. They don’t have their own separate auth since the HA user has already been authenticated so theres no need.

However I should note that HA doesn’t care whether your on LAN or not. If you are logged in to HA then you can get to frigate via the side nav, internal or external url. If that’s not what you want then addons won’t work for you, that’s not customizable.

When you have a supervised or HAOS install it makes a docker network called hassio. Home Assistant (or core in this context), supervisor and each addon all run as containers in this one network (except addons that use host network obviously). Not really sure where your points are coming from but that’s how it works. All individual containers in one docker network.

This comparison to portainer is bad. That’s just one part of what supervisor does.

Supervisor is intended to be used in an appliance install. In addition to installing new containers it also expects a particular file structure on the host system make into volumes, particular services to be installed it can interface with over dbus to do things like add and remove apparmor profiles, change network settings, start, stop and update host services, shutdown and reboot the machine, listen for new hardware and inform other containers about them, etc. This in addition to the stuff you’d expect portainer to do (start, stop and remove containers, create/remove networks, create, pull and remove images, etc).

It’s not an independent container at all. If you try and run it in any random docker setup it’s going to fail. It is deeply dependent on the host being configured and running in a particular way.

2 Likes
30

Have you considered a VPN for remote access instead?

1 Like
31

Thank you very much for your reply. It’s the 1st one to actually provide any real information.

Yes, that’s exactly what I DO want. That’s the problem with iFrames, they do not do that. I 1st thought iFrames would, but then I learned they essentially are useless since they rely entirely on your browser to do everything, they just put it in a frame. They also go back to the start whenever the tab is switched or refreshed, which is even more useless.

See, that’s where the conversations get really annoying. Home Assistant people will say “You don’t need Supervisor if you are in Docker because everything the add-ons do can be done in a Standalone Container” while at the same time saying that Supervisor does more than just managing containers. I point out the UI integration aspect that the containers definitely do NOT do & everyone just ignores that & changes the topic for a bit then comes back saying the same thing again.
I know It does stuff that Portainer doesn’t & Portainer does stuff that it doesn’t, but Portainer is a Docker Manager & UI. Supervisor is a Docker Manager & UI, but it does things differently, has different requirements for the Dockerfile, etc. That’s exactly why it’s needed alongside Portainer, because they aren’t the same.

I mean Portainer does that too. It’s used to install docker containers. It just does so using the Docker arguments while supervisor has it’s own arguments

This can easily be accomplished with Bind Mounts

I’m not sure exactly what that is, but if all the containers are in the same stack I think that should be able to be handled, all the things it accesses are Part of Supervisor’s container or Home Assistant’s, so on the same Docker-network, which happens on a stack by default, that isn’t a problem. If it needs something else that could be another stack if nothing else, so this is definitely possible, even if I don’t know what exactly is being referred to.

These are all things that can be done with Portainer, & can easily be possible within a properly structured Docker-Compose. As for updates Watchtower does a good job of doing updates, so there’s no reason Supervisor couldn’t handle those tasks for it’s stacks as well.

Now this would be something that couldn’t be done, but wouldn’t need to be either. I guess technically it could be, but there’s no reason for it, Portainer & Watchtower both have the ability to start & stop containers, & as far as the containers are concerned that IS a restart of the computer.

If you mean detect hardware on the network, the same way Home Assistant does, then that’s definitely something that it can do, as for informing other containers if they are in the same stack that’s as easy as it possibly could be, all ports are open within a stack so they can talk as much as they need to.

I mean the main thing is that it will fail in the Docker Build stage because of the stupid BUILD_FROM argument all Add-ons seem to use. As far as the system needing to be configued in a certain way, that’s pretty much all Docker Containers. That’s why you set those arguments in ENV variables & Bind Mounts.

I actually have a VPN setup. But it is more likely to fail, & if it’s down I have to be there physically to fix it. I actually have 2, 1 set in my router as well as 1 set in a container, but each also have their limitations. the biggest being that they take over my internet, so 1 I have no internet while it’s being used, & the other I do, but that internet is going into my home, then to me through the VPN. With the 2 setup I rarely have it so I can’t get in, but it’s very inconvenient, & the whole point of Home Assistant, of Smart Homes in general, it to make things more convenient

32

:roll_eyes: Really?

33

It has dependencies outside of docker entirely. The supervisor container requires access to dbus on the host. Which means it can communicate directly with services running on the host by sending them commands and receiving messages. It accesses and depends on things which are not in any container at all.

1 Like
34

I will note that this is fair. I’ve actually stopped saying this without a caveat for the UI bit because of that. I’m personally not a big fan of ingress. I mean it’s a very cool feature and it works well for people but I don’t like the embedded UI and I would prefer the UI of addons only be accessible within my LAN since all are admin only anyway.

That being said the ingress UI is the only thing quite difficult to replicate in a docker setup. It can be done but it would take a lot of effort. You’d basically need to build a kind of supervisor light in between to check that the HA user was authenticated and then proxy the request to the application. And set up external/proxy auth within that application which isn’t always easy.

All other aspects of addons are fairly easy to replicate in a docker setup. Yes it is nice that addons configure integrations for you but configuring them yourself is always possible. And most integrations have pretty good doc. Backup is nice but also users heavily invested in personal docker setups generally have backup mechanisms in place. And besides those aspects they really are just docker containers.

1 Like
35

That was about the Frigate Proxy thing, not about the how it’s different from Portainer. I was making that argument to explain for those who know Docker in a way that would make sense. Because that idea was attempted in this thread, but never in a way that was clear from that mindset.

In the Discord I was asking about how the Add-ons handle ENV variables, something completely related to Add-ons & Add-on development, but I mentioned that the reason I was asking is because I was trying to get the Frigate Proxy to run as a standalone container & I was met with

We develop add-ons: if you want to make a normal docker image instead, you should ask on the docker forums or another discord server.

Every Addon seems to have a BUILD_FROM or a BUILD_ARCH argument that it calls from the system in the Dockerfile, but the system doesn’t have that argument. obviously when Run in supervisor it gets it from somewhere, but nobody would tell me where because I mentioned Docker outside Portainer. eventually someone pointed me to The Add-On Developer Docs but I found the tutorial references the same thing, but doesn’t explain how it’s used or where it comes from.
In other forums people keep either telling me why I’m stupid for wanting to do it outside of Supervisor, telling me that I can “Just use a Regular Docker Container”

there is no reason too
you can just use normal docker images already out there
there is nothing those can’t do already

but when I ask where I can find one that does that they just say “Dockerhub” like a Pretentious AssHat
If you say so confidently & authoritatively that it exists you must have seen one, but you won’t say where or even give a hint, just say it’s one of the houses somewhere in America…

But I can’t find any that do what I need. I’ve looked quite extensively, otherwise I’d be using them, which I’m much more familiar with, instead of trying to make an Add-on function. The reason I came looking for help was because I can’t find any other option.

36

What are you looking for?

Is it just something to replicate the ingress function, or are you looking for something else?

37

lol. That’s entirely the reason I like it. If I’m at home I don’t need it. So I don’t understand what the point of it is otherwise. Well I guess the authorization, but I personally don’t mind having to authenticate myself, I just don’t want it to be on an exposed port or DDNS.

Exactly.

Which is what brought me to this Forum, I essentially made that same conclusion.
Would it be easier if the User wasn’t authenticated & had to manually sign in? I’m all for that. That would actually be even better because it would require 2 levels of authentication for something that could potentially damage the system, 1 from Home Assistant, one from the low security one on the app.

External proxy?.. That’s what I’m trying to avoid. The whole point was to make it so that there is no external access except from through Home Assistant

Yeah, all those fuctions I don’t want Home Assistant handling anyway

38

I think so. I’m not sure what exactly the ingress function is, but that sounds right. from my understanding it’s a proxy that displays a page inside Home Assistant regardless of whether that page can be seen outside of it. That’s what I’m looking for, & what the addons that cannot be replicated with simple Docker Containers do NOT do

39

Yes - it’s a proxy service built into the Supervisor.

You’ve got three choices:

  1. Switch to using HAOS
  2. Use a VPN for remote access (you said you had reliability problems - that’s down to how you implemented it)
  3. Implement your own version of Ingress (the code is public after all)
1 Like
40

An explanation of each of those args is found here. They come from the builder. Every repo in the HA ecosystem that makes docker images uses that GitHub action to make them. It reads in the build.yaml file in the repo and makes an image per supported arch accordingly. Doc for the build.yaml file can be found here. Here’s the list of supported arches from that same doc:

A list of supported architectures: armhf, armv7, aarch64, amd64, i386.

Basically figure out the arch you’re running on. Set that value to BUILD_ARCH. For BUILD_FROM look at the build.yaml and copy the value out of its build_from field that matches the arch. If build_from is unspecified, it defaults to the image from here that matches the arch. There are also other things that can be in build.yaml you’ll need to handle yourself.

For addons you also need to look at it’s config.yaml or config.json as well. Supervisor reads this file and uses it to construct the docker run command. Doc for everything that can be in this file is here.

Supervisor’s build.yaml is here. But setting the args from this isn’t close to enough. The supervised installer is what you would have to look at. Literally everything being done in there is setting up required dependencies for supervisor. None of that is recommendations or suggestions, it’s all supervisor’s required dependencies. This is what I’m trying to tell you, supervisor is not a normal docker container. If you copied and pasted some run command it wouldnt work on 99% of deployments. Supervisor is deeply tied into the host and has dependencies outside of docker entirely that it will fail without.

1 Like