HACS 2.0: Join the alpha testing adventure!

Calling all brave souls! We need your help to test the upcoming version 2.0 of HACS. Be among the first to experience the exciting new features and improvements, and help us make this release the best it can be!


Before you dive into the testing, make sure you meet the following requirements:

  • You are currently using HACS version 1.34.0.
  • You are running Home Assistant OS or Supervised.
  • You are running Home Assistant 2024.4.1 or newer.

How to join the alpha test

  1. Backup your configuration: Ensure you have a backup of your Home Assistant configuration.
  2. Add custom repository: Add the following custom add-on repository: https://github.com/hacs/addons.
  3. Install HACS: Get add-on: Install the “HACS: Get” add-on.
  4. Switch to development channel: Change the hidden “channel” setting to “development” under the add-on configuration tab.
  5. Start the add-on: Start the add-on and watch the logs; when it tells you to restart Home Assistant, do so.
  6. Start using it!: When Home Assistant starts up again, you can start using the alpha versions of HACS.
  7. Explore the new documentation: Browse the draft for the upcoming documentation at https://www.hacs.dev/.

Whenever you need to update HACS during this alpha, just start the add-on again and restart Home Assistant after it states it in its log.

Important caveats

  • No backwards compatibility: These alpha versions of HACS are NOT backwards compatible. If you need to revert to version 1.34.0, you must restore from a backup of your Home Assistant configuration directory.
  • Limited to OS/Supervised: While the alpha can be replicated on core/container, the add-on simplifies the process, so we are limiting this testing phase to OS/Supervised users for now.

Reporting issues

We value your feedback! Report any issues through the following channels:

  • GitHub: Report issues on GitHub
  • Discord: Use the “use” channel and the “tester” tag on Discord
  • Forum post: Share your feedback in this designated forum post.

What to look out for

HACS 2.0 brings a multitude of changes and improvements. Here’s what you can expect:

  • New frontend: Experience a brand new frontend based on the data tables in Home Assistant! Check it out.
  • Template management: Utilize the new template type to enhance your Jinja templates.
  • Update entities: Track updates for all your downloaded repositories with new update entities.
  • Repair issues: Receive repair issue notifications when something needs attention, like pending restarts.
  • Remote data handling: Enjoy drastically reduced API usage with the new remote dataset handling.
  • Renaming of things: Things HACS can manage have been renamed from “category” to “type”. Learn more.
  • Dashboard: UI elements, previously referred to as “Lovelace”, are now called “dashboard”.
  • Faster downloads: Downloading large repositories, like those providing icons, will be significantly faster.

Features being removed

As with any major version change, some features will be deprecated:

  • YAML configuration: YAML configuration of HACS itself has been removed.
  • README.md template rendering: Template rendering of the README.md file for repositories has been removed, the README.md files themselves will still be rendered as before.
  • info.md usage: The use of the info.md file has been discontinued.
  • Netdaemon type: The repository type “netdaemon” has been removed.
  • Version/beta selector: The version/beta selectors have been removed, and from now you have to use the service.
  • /hacsfiles/ endpoint: The endpoint for themes has been removed, for dashboard this is still in use.
  • Custom events: Custom hacs/* events have been removed.

Join us in making HACS 2.0 the best version yet! Your feedback is invaluable and will help shape the future of HACS. Thank you for being a part of our community and happy testing!


This seems like a step backward in usability. Was there a reason for it?


The main goals of this release has 2 parts:

  • Use less API calls.
  • Make it more maintainable by reusing core HA features instead of duplicating logic.

Removing that checks both those items, having this in there means that an additional API call would have been done regardless if you needed it or not.

This (to my knowledge) was mostly used to “roll back” something to a previous version, which it actually does not do as it only do the repository content, and not the data produced by it which in some cases is not compatible, leaving restoring a backup as the best option to do that.

However, the update.install service call takes a version argument, so you can still do that if you really wanted to.

Ok thanks for the explanation.

I use it mostly to help 3rd party developers by testing their beta versions when HA core updates breaks something for them. This is not an uncommon occurrence.

1 Like

I see! You can still do that with the same version argument.
You can even do dev branches if their repository supports it (so it has even more flexibility in that regard, since they do not have to do a pre-release).

For pre-releases to show in the update entity directly, I hope to have something before this release is published.

Yeah I realise that, it just not as easy as using a switch to include beta versions and a drop-down to select the available version. Call me lazy.


I agree, I use beta all the time for the integrations I develop. Then I can easily validate the latest version on my prod instance before I move to full release. Yes you can still do it using the service, but not as simple as just clicking upgrade.