Tbf, systemd also makes it relatively easy to sandbox processes. But it’s opt-in, while for containers it’s opt-out.

Props for spelling “spelling” wrong in the title .

My point however was that people who want that kind of convenience (or rather who don’t want to fiddle around manually), why would they want to run HASS in a container in the first place? Either you are tinkerer, then it doesn’t matter or you are not, in which case you probably don’t arrive at the point of running HASS on anything other than a preinstalled distro in the first place.

Now I am intrigued to develop one that is called YOLO.

But just in case: no, I don’t monitor my server. If I notice something not working, I ssh into the machine and check what’s up. I don’t want to deal with another zoo of services for the monitoring part.

IIRC it had better performance than Prometheus. We also ditched Elasticsearch in favor of ClickHouse to keep up with log ingestion.

My own server? YOLO

At work? Grafana, KOBS, Victoria Metrics, Jaeger, OpsGenie, …

When I host multiple services, I need to back them up as well. I simply mount all data volumes of all containers into a unified location that gets backed up by kopia every hour.

Since the volume is directly on disk, I also didn’t have any problems editing configuration files.

The things I see listed as addons on the website are dedicated services anyway, that have images of their own you can easily spin up as containers.

I think if someone is advanced enough to want to run HASS on their own together with other stuff, they prefer to have more control anyway.

What kind of addons? I have HACS and it works fine.

Strip prefix won’t work if the frontend expects to find paths at absolute locations. You would need to patch the html, css and js on the fly, which is somewhere between ugly and (almost) impossible.

I would also suggest to simply use custom (sub) domains. Especially in your intranet you can have whatever domains you want.