Home Assistant addons: the official repository behind the apps store

Why the repository is still called addons after the rename

The README heading now reads Home Assistant Apps: The official repository, and the first sentence of the body explains why the URL still says otherwise. Apps, formerly known as add-ons, are described as a way to extend the functionality around a Home Assistant setup, and the parenthetical is doing real work. Anyone arriving from a search result, an older forum post or a tutorial written two years ago will see the word add-on in the repository name and the word app everywhere in the prose.

The practical difference is small, but it does touch the interface. Add-on entries appear in the Home Assistant frontend under a store section, and the installation and configuration flow runs through that frontend on systems that have Home Assistant installed. The homepage recorded for the project is the hassio page on home-assistant.io, which is where the per-app documentation lives.

The rest of the identity is conventional. The language is Shell, the license is Apache-2.0, the default branch is master, the repository is not archived, and the last push was on 2026-09-27. Repository topics cover automation, docker, home, iot and hacktoberfest, and there is an AI_POLICY.md at the root alongside a LICENSE file.

Two kinds of app, and why the distinction matters

The README draws a line that is more useful than the app list itself. Some apps consist of an application that Home Assistant can integrate with, and the two examples given are an MQTT broker and a database server. Others allow access to your Home Assistant configuration, with Samba and the browser-based File Editor named as the examples.

That distinction is the security boundary worth thinking about before installing anything. A broker or a database is a service on your network that something connects to. Samba and the File Editor are a way to reach the configuration directory that defines your whole home automation. Both are listed in the same store with the same install button, so the README's grouping is doing the risk separation that the interface does not.

A third category exists in practice without being called out as such: the hardware and radio apps. CEC Scanner, deCONZ, Z-Wave JS and the Silicon Labs entries in the tree all exist to talk to a USB radio stick. Those carry a different kind of risk again, since they touch the machine's USB bus and often need elevated privileges. The README does not spell out that third grouping, which is one of the places it stops and the developer documentation begins.

What the fifteen documented apps actually cover

The README lists fifteen apps with a one line description each, and the descriptions are specific enough to be worth reading as a capability list.

The networking and certificate group is the densest. Mosquitto broker is an Open Source MQTT broker, MariaDB is a MariaDB database for Home Assistant, Duck DNS automatically updates your Duck DNS IP address with integrated HTTPS support via Let's Encrypt, and there is a separate Let's Encrypt app for managing and creating certificates. NGINX Home Assistant SSL proxy sets up an SSL proxy with NGINX and redirects traffic from port 80 to 443, and Dnsmasq is a simple DNS server. Configuration access comes from Samba share, described as sharing your configuration over the network using Windows file sharing, and the File editor, a simple browser-based file editor for Home Assistant.

The two that stand out for workflow rather than infrastructure are Git pull, which loads and updates configuration files for Home Assistant from a Git repository, and SSH server, which allows logging in remotely using SSH or using the web terminal with Ingress. Git pull is the one that changes how you run the platform, since it turns the configuration directory into a working copy you can push and pull.

The hardware group covers CEC Scanner for discovering HDMI CEC devices and their addresses, deCONZ for a Zigbee network through ConBee or RaspBee hardware by dresden elektronik, and Z-Wave JS for reaching a Z-Wave network via a USB controller. RPC Shutdown is narrower: it shuts down Windows machines remotely, which is the only app here aimed at a host other than the one running Home Assistant.

The tree lists ten apps the README does not

The repository root contains twenty-five app directories. The README documents fifteen. The gap is not a mistake in the file listing, it is a documentation lag, and the names of the missing directories tell you where Home Assistant is heading.

The undocumented set is assist_microphone, matter_server, openwakeword, piper, speech_to_phrase and whisper on one side, and matter_server, openthread_border_router, silabs-multiprotocol and silabs_flasher on the other. vlc is the tenth.

Read together, that is a voice pipeline and a radio pipeline. The speech cluster covers open wake word detection, several speech-to-text engines including Whisper and Piper for text to speech, a phrase-level matcher and a microphone feed for voice assistant use. The radio cluster adds Matter, which is the smart home protocol Home Assistant has been moving toward, an OpenThread border router for Thread devices, and two Silicon Labs tools, one for the multiprotocol radio and one for flashing firmware onto it.

So the honest summary is that this repository now covers voice and Matter, while the README still mostly describes it as a collection of broker, database and file access apps. Anyone assessing which add-ons exist should read the directory listing rather than the README list.

How installing works and where the documentation takes over

There is no shell command in the README, and that is by design rather than an omission. Apps are installed and configured through the Home Assistant frontend, on systems that have Home Assistant installed. Configuration options, ports, storage mappings and ingress settings are all entered there, so the terminal is not part of the normal path.

For anyone building an app rather than installing one, the README is explicit about where to look: it points to the developer documentation for add-ons at developers.home-assistant.io/docs/add-ons/ and says this repository can be a great source of inspiration. The repository tree supports that claim with the tooling you would expect. A `.hadolint.yaml` at the root implies Dockerfile linting is enforced, `.devcontainer/` and `.vscode/` directories suggest a defined development environment, and `.github/` holds the contribution workflow.

One gap is worth naming for anyone tracking versions. This repository has no GitHub releases, which is consistent with how the project works. An app is versioned in its own directory, and what a given system can install depends on the Home Assistant version and the store repository it is configured against. There is no single changelog at the repository level to read for what changed across the set.

Where the official set stops

Two boundaries are visible from outside the repository.

The first is that this is the official set, not all of them. Home Assistant supports community add-on repositories, and the frontend can be pointed at them, which means a large part of what people install in practice comes from elsewhere. The value of this repository is that it is maintained alongside the core platform, so an app here is likely to match the version of Home Assistant you are running. The tradeoff is a narrow catalog. If you need a specific database engine, a particular reverse proxy setup or a niche protocol stack, you will be looking outside this list.

The second is that the apps do not configure your installation for you. A broker needs credentials, MariaDB needs a database and a user, the NGINX proxy needs to know which ports and certificates to serve, and the radio apps need to be told where the USB device is. The README describes what each app is for and stops there. Per-app documentation and the developer docs carry the rest, and for a first-time install that is where the actual work is described.

Licensing is the simplest axis. Apache-2.0 across the repository is one of the more permissive and more protective choices available, with an explicit patent grant, which makes these container definitions straightforward to read, learn from and adapt for an internal deployment.

Editorial conclusion

This repository is the answer to a narrow and common problem: running a supporting service for Home Assistant without hand-writing a container definition, a compose file and a restart policy for each one. Mosquitto, MariaDB, the Let's Encrypt companion and the Z-Wave and deCONZ drivers are the cases where it clearly pays for itself. What it does not do is decide your architecture: an app still needs ports, credentials and storage configured, and the README leaves every one of those to the per-app documentation and the developer docs. The repository has no GitHub releases, so the authoritative version information for any individual app lives on its own page under `https://www.home-assistant.io/hassio/` rather than in this history.

Frequently asked questions

Official sources

1. home-assistant/addons on GitHub
2. Issues
3. License: Apache-2.0
4. Project website
5. README