HACS is built in now — and my hand-installs were invisible

If you update Home Assistant to 2026.11, something happens that asks you nothing: HACS becomes part of the core. You do not have to install it, you cannot decline it, and if you never wanted it, you now have it anyway.

My update went through on 6 November at 21:32. The marketplace config entry was simply there afterwards:

marketplace/info ->
  version:     2026.11.0
  categories:  integration, theme, plugin, template
  stage:       running

According to the release notes the HACS installer ends with exactly this version. Anyone who had HACS gets migrated. Anyone who had none — as in my Kapfenberg instance — gets it as a bonus.

Here is what actually changes. Including the thing that nearly cost me a false bug report.

Three homes, three different stances

The update hits my three instances differently, because I handled them differently:

Location	Practice so far
Kapfenberg	HACS deliberately avoided. Anything not built in was downloaded as a release archive from GitHub and unpacked by hand.
Merano	HACS in use for three integrations — cameras, Meross devices, Xiaomi.
Vienna	HACS for exactly one integration, a speed test.

For months the Kapfenberg documentation carried the line “HACS is not needed for anything so far”. I had even turned down a HACS dependency once because it was only about a font size — a permanent dependency for a font size is a bad trade.

That decision is now moot. Not wrong in hindsight, just settled.

What breaks immediately

Templates pointing at HACS. If you use integration_entities('hacs'), it becomes integration_entities('marketplace'). Neither appears anywhere in my setup, but if you have an overview card listing installed extensions, look there first.

Documented paths to add-ons. 2026.11 renamed add-ons to “apps”. The panel is app now, not hassio. Every guide on the internet quoting a path of the form /hassio/addon/<name>/config has been running into a 404 since — and there are many.

The part that surprised me

Hand-installed means invisible.

The Marketplace index holds 6,194 projects. Before my first download, not a single entry in that entire list reported “installed” — although seven folders sat under custom_components/ and were running perfectly.

The Marketplace only knows what it put there itself. Anything you copied in by hand does not exist for it.

In practice that means the download is not an update but a fresh install over the existing copy. It went through cleanly here — config entry and stored token untouched:

manifest version:  1.2.1      config_flow: true
config entry:      loaded     source: user
installed:         yes        version: v1.2.1
cameras: 10        image-age sensors: 8, none without a value

But anyone looking for the first time and reading “not installed” while the integration is visibly running is right to hesitate.

The real gain is not the new version number but that updates now arrive by themselves. For three months I pulled updates to this one integration in by hand. That stops.

The false trail, and how it came out

Now the part I nearly reported to a project.

Before the download the index said config_flow: false, while the installed manifest of the same integration reported config_flow: true. That looked like a genuine finding: if the index says false, the interface might offer no “add” button after the download at all. The report was already drafted.

Then the control check across the whole index:

	Entries	of those config_flow: true
Integrations, not installed	4,981	0
Integrations, installed	1	1

Zero out of 4,981. The field is simply empty while nothing is installed — it is filled from the local manifest, not from the index. Not a finding, just the normal state.

A single comparison value would have been enough to see that beforehand. It is the same lesson as in my camera hunt: one observation is not a pattern. Before you report something, look at what normal looks like.

What the Marketplace cannot do

It lists integrations only, not add-ons. If you run a companion add-on, you keep maintaining that by hand through the add-on source. Here the integration sits at 1.2.1 while its add-on stays at 1.2.0 — and that is correct, because according to the release notes only the integration changed.

That is a point that causes confusion: two things with the same name and the same version number, but only one of them is now supplied automatically.

What I would advise

1. Search your templates for 'hacs'. It is the only change that quietly returns wrong values instead of raising an error.
2. Do not expect to find your hand-installs. Manually installed integrations read as “not installed”. Downloading over them worked here, but take a backup first.
3. Check guides for /hassio/ paths before following them. Add-ons are apps now.
4. Be pleased about the right part. The version number is not the win — one fewer thing to pull in by hand is.

So what?

For a long time I argued in Kapfenberg why I did not want HACS: an additional permanent dependency for things I can unpack by hand once. That stance is settled now, without my having decided anything.

That is neither good nor bad, but it is worth noting: a deliberate abstention held for months was lifted by a routine update. Anyone wanting to keep their installation lean no longer decides that at this point.

My practical verdict: the migration broke nothing here and takes recurring manual work off my hands. But it shows that “I install nothing I do not need” is not a strategy in the long run — it is an interim state.