The HACS Ecosystem: How to Assess Whether a Custom Integration Is Safe
The HACS Ecosystem: How to Assess Whether a Custom Integration Is Safe
A HACS integration that part of your dashboard from Module 15 depended on stops working after a Home Assistant update, and its author hasn't responded on GitHub in a year. This lesson covers how to assess risk before installing a custom integration, and what safety rules to apply across the whole HACS ecosystem used throughout this course.
Budget around 50 minutes. This course has used HACS repeatedly: Mushroom Cards and ApexCharts from Module 15, Fully Kiosk from Module 14, Music Assistant from Module 22. This lesson covers managing that risk deliberately.
Custom Integrations Aren't Officially Approved by the Home Assistant Team
HACS (Home Assistant Community Store) gives you a convenient interface for installing integrations, dashboard cards, and themes created by the community, but none of them go through official review by the Home Assistant team, unlike integrations built directly into Core. You install them at your own risk, and that risk is worth assessing deliberately before clicking Install.
What to Check Before Installing Any Custom Integration
The date of the last commit in the repository: a project untouched for over a year is a warning sign, especially given how fast Home Assistant Core changes
The number of stars and active users: more popular projects usually have more people reporting and fixing problems
Open issues and their age: dozens of unresolved, old bug reports suggest weak project maintenance
How critical this integration is to your system: the more essential the function (controlling a gate, say), the more carefully you should approach a custom solution with no official support
A Rule From This Course: Backup Before Every New HACS Install
Backup before the install, not after the problem
Before installing a new integration or card from HACS, run a fresh backup following this module's Lesson 2. Custom code, unlike official integrations, doesn't go through the same level of testing before publication, so the odds of unexpected behavior are higher.
Which Integrations From This Course Are HACS, and Which Are Official
| Category | Examples from this course |
|---|---|
| Official Core integrations | ZHA, ESPHome, HDMI-CEC, LG webOS, Samsung Tizen, Ecowitt, the recorder |
| HACS: dashboard cards | Mushroom Cards, Button Card, ApexCharts Card, Auto Entities, Card Mod, Bubble Card (Module 15) |
| HACS: integrations | Music Assistant (though largely integrated officially now), Fully Kiosk (some features), QuickBars |
| Outside HACS, separate add-ons | Frigate, Mosquitto, Irrigation Unlimited (partly a HACS integration, partly an add-on) |
Being aware of this distinction helps you gauge which parts of your system have full support from the Home Assistant team, and which depend on maintenance from individual community developers.
How HACS Installs Actually Work, and Where Integrations Come From
HACS installs as an add-on, then pulls the repositories you point it at from GitHub and places their code in the custom_components directory (for integrations) or www/community (for dashboard cards). Unlike integrations built into Core, HACS code isn't part of the main Home Assistant repository and doesn't go through the same code review process at every Core update.
HACS itself requires a one-time registration through a GitHub account during initial setup, which surprises some users: it's a mechanism protecting against abuse of GitHub's API rate limit, which HACS relies on heavily to check for updates across every installed repository.
| HACS category | Example from this course |
|---|---|
| Integrations | custom hardware and cloud integrations, some Music Assistant functionality, for example |
| Frontend (dashboard cards) | Mushroom Cards, ApexCharts Card, Bubble Card from Module 15 |
| Themes | dashboard color themes, cosmetic, lower risk |
| Python scripts / AppDaemon | automation logic extensions beyond Home Assistant's standard engine |
Telling a HACS-Installed Integration Apart From an Official One
Under Settings, Devices and services, every integration shows its name and, when you hover or open its details, information about where it comes from. HACS integrations usually have their own link to a GitHub repository in the documentation, unlike official integrations, which point to the home-assistant.io domain. If you're unsure, the custom_components directory in your configuration files contains exclusively non-Core integrations.
An Alternative: Verified Add-Ons (Home Assistant Community Add-ons)
Beyond HACS itself, there's also the Home Assistant Community Add-ons repository, covering add-ons (not integrations) that usually have a higher level of maintenance and a longer track record than the average HACS repository, though still community-built, not the official team. The distinction between an add-on (running as a separate container) and a HACS integration (code running inside Home Assistant itself) matters for risk assessment: an add-on failure usually doesn't directly affect Home Assistant's own stability, while a bug in a custom integration can.
Safely Removing a HACS Integration Once It Stops Being Maintained
1. Run a backup before removing it, exactly as you would before installing it.
2. Remove the integration under Settings, Devices and services, not just from the HACS list.
3. Remove the repository itself from the HACS list, so it doesn't keep trying to update in the background.
4. Check automations and dashboards using this integration's entities and update them, or remove the dead references.
5. Consider a replacement: the same functionality often ends up in official Core over time, as partly happened with Music Assistant.
Cumulative Risk: More Custom Integrations Means a More Fragile Web of Dependencies
A single custom integration is a manageable risk, but an install built following this entire course (Modules 9 through 22) can end up with a dozen or several dozen HACS-sourced pieces at once: dashboard cards from Module 15, multimedia integrations from Module 22, outdoor extensions from Module 21. Every subsequent Core update carries a small, but nonzero, risk of a conflict with any one of them. It's worth reviewing the full list of installed HACS elements every so often and deliberately asking yourself whether each one is still needed and actively maintained.
How to Test This Lesson
1. Review the list of integrations and cards installed through HACS in your system.
2. For each one, check the date of the last commit in its GitHub repository.
3. Identify which ones are critical to how your system runs, and which are cosmetic.
Common Mistakes
Installing a custom integration without checking project maintenance: the risk of support suddenly stopping after a Home Assistant Core change
Building a critical safety function on a custom integration alone: no plan B if the integration stops working
Installing without a prior backup: no easy way back to the state before the problematic integration
Practical Task
☐ Review your currently installed HACS integrations for activity and maintenance.
☐ Set the rule: always back up before installing a new HACS integration, no exceptions.
☐ Consider whether any critical function relies solely on an unmaintained custom integration.
Key Takeaways
Custom integrations from HACS aren't officially approved by the Home Assistant team.
Before installing, check the last commit date, popularity, and open issues.
A backup before installing is a rule, not an option, for every new HACS integration.
What's Next
Next lesson: Mini Project: Your Home Assistant Maintenance Plan. We tie all nine previous lessons into one concrete schedule.
