Home Assistant Proposes Bringing HACS Into Core

Frenck opened the Marketplace proposal on September 28. It was still a draft when this article was published on September 29.

Status checked October 10: The Core, frontend, and documentation pull requests were merged on October 1. That is not the same as shipping in the October release: the Core 2026.10.0 release tree does not contain the Marketplace component added by the Core pull request. The sections below describe the September proposal, not a migration tested in my house. Do not remove HACS on the assumption that installing 2026.10.0 replaces it. Follow the instructions for the release that actually ships the replacement.

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.

Check the migration guidance for your release

Before changing a working installation, identify the release containing the migration and read its instructions and exceptions. Take a full backup before upgrading. The inventory should include custom repositories and anything managed through HACS that runs without a visible dashboard control.

This article does not report a migration tested in 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.