Enable Users to Self-Host External Assets (like brands.home-assistant.io)

[Gunni]

Describe your core improvement

External resources like brands.home-assistant.io are currently hardcoded, forcing the client-side frontend to fetch assets directly from the internet. This proposal asks for those URLs to be configurable so users can self-host or proxy them via Home Assistant.

Benefits:

• Works offline
• Reduces privacy exposure
• Aligns with Home Assistant’s local-first philosophy

Current limitations

Today the brands URL is hardcoded to brands.home-assistant.io, but that means brand icons do not load if the user is offline.

Technical benefits

Allowing the brands URL (and other external resources) to be configurable would let users self-host these assets or proxy them through Home Assistant. For example, an add-on could serve the brands repository via ingress, or a user could run a simple webserver with the brands repo.

Additional context

Icons pulling from outside local HASS domain #18549

Was closed as intended behavior, this ticket intends to change that. Migrated to discussion: home-assistant/frontend#26274

My Personal Opinion

The Home Assistant web-app should endeavor to never ever use remote resources of any kind.

In literal terms, the users browser should never ever ever EVER load a website in home assistant and get an external path for a resource!.
A content-security-policy with a default-src of self should never be violated!

• Remote APIs, go via HA, unavoidable, but never user-browser to remote api!
• Sources for scripts, images, whatever
  • Ability to either host locally, or if source is too large then proxy it via HA and have HA cache the resources locally for future use
• Map tiles
  • Proxy via HA and have HA cache the resources locally for future use

[Hill-98]

I'm paying attention to this because I'm in China, and brands.home-assistant.io uses Cloudflare, which makes access in China very slow (or even inaccessible).

So this request is reasonable because it can bring a better experience to some users.

[Gunni]

As demonstrated with todays Cloudflare outage, this should be self-hostable so that this resource cannot just vanish...

Also:

Failed to perform the action update/install. Error updating Studio Code Server: 'AddonManager.update' blocked from execution, no host internet connection

While it makes sense to not be able to install things like this, the message is simply incorrect, as the internet is fine, and this service is simply down. Maybe that can get posted as a separate bug though.

[mik-laj]

Updates, including updates for add-ons, are not something this project has any influence over. Updates are published and distributed by their authors independently of HA. In the case of Docker we can still replace the image registry, but I'm not sure if it would be effective, as few people will maintain an image registry for home users.

Additionally, the image for this add-on is hosted on GHCR, and I’m not aware of any public mirrors for the GitHub Container Registry. Unlike Docker Hub, which benefits from multiple public mirrors provided by various cloud vendors, GHCR doesn’t seem to have an equivalent ecosystem. This means that even if someone wanted to swap the registry or set up a fallback, there isn’t an official or community-maintained mirror that could realistically be used for this image.

It’s also worth noting that many integrations rely on external libraries or vendor-specific endpoints to fetch updates or assets, and there’s no uniform standard there either. Some libraries host their updates on GitHub, some on AWS or other CDNs, and others only on the manufacturer’s own servers. Because these mechanisms differ per vendor and per library, there’s no single approach Home Assistant can enforce or mirror locally.

In general, updates can fail just like any other external integration point, and there’s no way to fully guard against that. Outages happen, and this time we simply had one with a global impact.

That said, I do agree it’s worth considering whether assets required for HA itself - and which are under the control of the HA maintainers - could offer an option for mirroring or fallback. But the case for add-on updates doesn’t fully convince me, since those are entirely in the hands of their respective authors.

[Gunni]

I meant the message that my internet was offline was wrong, my internet was working fine, the only thing that wasn't working was cloudflare.

[mik-laj]

We could improve this message, but since it looks more like a very-low-priority bug than a feature request, it’s probably not worth creating a ticket - I doubt anyone will find time to work on it. Global incidents do not happen often and because they are global they are quickly noticed in other way.

[Gunni]

That part was only a side comment in my comment earlier. Not the main point of this post.

Look instead at that, or this guy having problems in China.

[oerix]

I guess on-device caching could be considered as an alternative, If it doesn’t already?

[Gunni]

No, and end user device is not what I am asking, at a minimum, I'd want it to be done by HA so that the entire lan benefits.

[oerix]

Probably should clarify, I'm not disagreeing with you. Just suggesting a fallback option.