Home Assistant Proposes Bringing HACS Into Core

Home Assistant is proposing to bring HACS into the product itself. For anyone maintaining a collection of community integrations and dashboard cards, that could remove a separate installation step and put more of the house’s software updates in one place.

Frenck opened the Marketplace proposal on September 28. As of September 29, it is still a draft. There is no released migration to run today.

I like the direction. Community software fills gaps that matter in a working home, and making it easier to discover and maintain is a reasonable improvement. The transition deserves a closer look before anyone starts deleting their existing HACS installation.

Existing installations would move with it

The proposed conversion carries over HACS configuration, downloaded-repository records, entities, devices, dashboard resources, and custom repositories. HACS itself would be removed. Downloads would receive update entities alongside other Home Assistant updates. Catalog access would work without a GitHub account; custom repositories would still require a GitHub connection.

AppDaemon apps and Python scripts would no longer be managed by the replacement. The proposal calls for a repair notification identifying affected items. Losing management of a download is different from a claim that AppDaemon or Home Assistant’s Python-script feature is being removed.

That exception is where I would start an inventory. A dashboard card is visible every time someone opens a tablet. A script that handles one occasional task can be much easier to forget. Before a migration, I want to know who supplies each component, which version is installed, and how I would update it afterward.

The interface is being brought into Home Assistant too

The frontend proposal places the Marketplace under Settings and ports the HACS interface onto Home Assistant’s current frontend components. Browsing, filtering, choosing a version, and removing downloads remain part of the design. Existing HACS repository links are intended to open the new panel.

Version selection is worth keeping. When a new card or integration behaves differently, being able to identify and return to a known version makes troubleshooting much more manageable. A single update screen is convenient, but installing everything at once can still make it difficult to identify which change caused a problem.

I would keep updates small enough to verify. Check the card in the browser that normally displays it. Exercise an automation that depends on the integration. Confirm that its entities still report sensible values. A successful download only proves that the files arrived.

A built-in catalog still needs clear ownership

The accompanying documentation proposal explicitly includes warnings about community content and coverage of downloads that replace built-in integrations. The frontend also proposes confirmation before that replacement.

That distinction needs to remain visible. A download appearing inside Settings can look like an endorsement of every component behind the button. Readers should still be able to find its maintainer, release notes, and issue tracker without wondering whether a bug belongs to Home Assistant or the downloaded project.

Replacing a built-in integration is a particularly consequential choice. It can be a useful way to obtain a fix or support a device sooner. It also changes which implementation handles that device. If behavior changes after the next update, that is information the person troubleshooting the house needs.

For my Home Assistant setup, I would welcome a more consistent place to manage these dependencies. I would still judge each integration by its maintenance and behavior with the hardware. Putting the installer in core cannot settle those questions for every community project.

There is nothing to migrate yet

The next thing to watch is the final migration guidance and the release that contains it. I would leave a working installation alone until those exist, then take a full backup before upgrading. The inventory should include custom repositories and anything managed through HACS that runs without a visible dashboard control.

I have not run this draft on my house. The promising part is straightforward: fewer setup steps and a clearer place to maintain community software. Whether the transition delivers that will depend on how well it preserves existing installations, explains exceptions, and helps people recover when a component needs attention.