# AppDaemon: a sandboxed Python runtime for home automation

> AppDaemon is a Python execution environment for writing automation apps that talk to Home Assistant, to MQTT brokers and to anything else that is event driven. It is loosely coupled, multi-threaded and sandboxed, and it ships a configurable dashboard meant for a tablet screwed to a kitchen wall.

**AppDaemon/appdaemon** — :page_facing_up: Python Apps for Home Automation

- Repository: https://github.com/AppDaemon/appdaemon
- Stars: 971 · Forks: 427
- Language: Python
- License: NOASSERTION
- Published: 2026-10-20 · Updated: 2026-10-20 · Language: en
- Canonical page: https://hysenlabs.com/projects/appdaemon-appdaemon

## What AppDaemon actually is

The description is precise and unusual in a good way.

AppDaemon is a loosely coupled, multi-threaded, sandboxed Python execution environment for writing automation apps for various types of home automation software, including Home Assistant and MQTT. It has a pluggable architecture allowing it to be integrated with practically any event driven application.

Four words in that sentence carry the design. Loosely coupled means the app does not live inside the home automation package, it talks to it. Multi-threaded means the apps run concurrently rather than in sequence. Sandboxed means the apps are contained, which matters when the code running in your house is code you wrote at eleven at night. And pluggable means the interface to the outside world is a set of adapters rather than a fixed protocol.

The pluggable part is the one that extends the life of the project. Home Assistant is the best known integration and the one the package description is built around, but the architecture does not stop there, and the MQTT support means the same app can be driven by a broker rather than by the home automation package. For a house, that is a useful decoupling, because it lets the automation logic outlive any particular integration.

The apps themselves are ordinary Python classes that react to events and call back into the system. The framework is the scheduler, the event bus and the containment.

The licence is a custom file the platform cannot classify, so read the licence file in the root before you redistribute it.

## HADashboard, the part you put on the wall

The second feature in the description is a configurable dashboard suitable for wall mounted tablets, and it is called HADashboard.

The reason it is bundled with the server rather than being a separate project is structural. A home automation server already has the state of the house, the entities, the history and the schedules, and a dashboard that reads that state directly can update in real time without a second integration. The dependency list backs this up with both Socket.IO and SockJS, which are the two transports such a dashboard needs, a channel for pushes and a fallback for clients that cannot use it.

The name is suggestive of the Home Assistant connection without being tied to it, and the intent in the description is specific: a tablet mounted on a wall where it shows the state of the house and can trigger things, without the browser chrome, without the login prompt appearing every time the screen wakes, and without a phone in the way.

That last point is where a wall dashboard earns its keep. A tablet that sleeps and wakes is a browser that loses its session, and a configuration that puts the controls directly on the home screen is what turns a tablet into a control panel rather than a browser.

It is also where the security questions live, and the readme does not discuss them. A wall tablet with a dashboard is a device on the network with a session that never expires, so how it is authenticated and what it can reach is worth deciding rather than inheriting.

## The release cycle, and why it has slowed

There is a section of the readme devoted to release frequency, and it is unusual enough to quote in substance.

AppDaemon has reached a very stable point, works reliably and is fairly feature rich at this point in its development. For that reason, releases have been slow in recent months. The readme is careful to add that this does not mean AppDaemon has been abandoned, and gives the reasons: it is used every day by the core developers and it has an active community chat server, with an invitation to join for tips and tricks, discussions and general home automation questions.

The release history is consistent with that description. Version 4.5.11 came out in June 2025, 4.5.12 in October 2025 and 4.5.13 in January 2026, and the last push to the repository was on 2026-08-09 with the repository not archived. The packaging metadata already carries 4.5.14, so the next release is staged.

So the project is stable and slow rather than stale and abandoned, and the distinction matters for an evaluator. A stable project with a slow release cadence is one where the risk is not that something breaks but that a new platform or a new integration takes a long time to appear.

The contributing section is brief and warm. It says this is an active open source project, always open to people who want to use the code or contribute to it, and points at the developer documentation for the details.

## The dependency list names the protocols it speaks

The runtime dependencies are the most useful description of what the software actually talks to.

For the home automation side there is aiohttp for HTTP, the Jinja2 integration for aiohttp for templated responses, and a Feedparser parser for feeds. For MQTT there is the Paho client, pinned to the 1.x through 2.x line.

For the real time dashboard there is python-socketio for the Socket.IO server and sockjs for the fallback transport.

The rest is the machinery of a server. bcrypt for password hashing, Deepdiff for comparing structures, which is what lets the server notice a changed configuration, and the pid library for process identification. There is pytz and python-dateutil for time, PyYAML and the TOML readers and writers for configuration, requests for outgoing HTTP, uvloop for the event loop where it is available, and pydantic for validation, pinned to the 2.x line.

The uvloop entry carries a platform marker, which is the detail worth noticing.

```toml
    "uvloop>=0.21.0; sys_platform != 'win32'",
```

So the fast event loop is used everywhere except Windows, and the package still runs there on the standard loop. That is the kind of conditional dependency that tells you the project supports Windows properly rather than nominally.

The user-facing interface is Python, and the configuration format follows the same split, with YAML and TOML both supported for configuration files.

## A wide Python range, and a container build that knows it

The packaging declares a wide interpreter range and then classifies itself for the whole span.

```toml
requires-python = ">=3.10,<3.15"
```

The classifiers list Python 3.10, 3.11, 3.12, 3.13 and 3.14 individually, and the development status is marked as production and stable, with a typing classifier, which is a claim that the package ships type information.

A range that wide is a deliberate choice and it has consequences. It means the package is installable on a five year old distribution and on a current one, which matters for home automation, where the machine running the server is often a small box with a conservative operating system. It also means the conditional dependency and the platform markers in the dependency list are load-bearing, because there is no single supported platform to optimise for.

The container build shows the same thinking. The base image is a Python release on a specific Alpine version, and the comment at the top of the Dockerfile warns that the Python major and minor version has to match the one Alpine provides in its package repository, or the Alpine packages will not work, with a test procedure given in the comment for checking it from inside the container.

The build itself uses uv with the lock file enforced, bytecode compilation enabled and the project environment pointed at the system location. There is a specific workaround for a Rust build problem in the orsjson package, which is a dependency of Deepdiff, and the image installs git and Rust on ARM architectures to build the native dependencies, along with Cython and a build toolchain for uvloop. The multi-stage build ends in a scratch base with only the binary and the certificate store.

## Documentation, history and the developer entry point

The documentation arrangement is what a mature project looks like, and it is worth knowing where to look before you start.

The readme points at the project documentation for installation and usage, hosted on Read the Docs, and the contributing section points at a separate developer page for people working on the code. The repository itself carries a docs directory, a configuration directory with the shipped example configuration, a scripts directory and a tests directory.

The changelog lives in the repository as a history file in reStructuredText, and the project URLs in the packaging metadata point at it directly, which means you can check what changed between versions without leaving the package metadata.

The project also has a contributor licence agreement file, a code of conduct, a pre-commit configuration, a ruff configuration for linting and a lock file, so the toolchain is pinned in the repository rather than left to the contributor's machine.

Two closing observations for anyone evaluating it.

The first is that the documentation is the product for a project like this. The code is a runtime, but the thing you actually need to know is how to write an app, how to register a plugin for a device you own, and how the scheduler decides what runs when. The readme explicitly defers all of that to the documentation site, which is the correct division of labour and also a reason to spend an hour there before deciding.

The second is the integration surface. If your home automation package is Home Assistant and you are happy to write apps that talk to it, AppDaemon is a well established way to do it. If your setup is something else, the pluggable architecture is the reason it is still worth considering, and the first thing to check is whether someone has already written the adapter, because that is the piece of work that would otherwise fall to you.

## Conclusion

AppDaemon suits a home automation enthusiast who wants to write their automations as Python rather than as a pile of YAML in a configuration file, and who is comfortable with an event driven model and a long lived daemon on the home network. It is a poor fit if you want a self-contained appliance, since it is a server you run and configure, and a poor fit if you need a supported release every month, because the release cadence has slowed deliberately. Before you start, read the project documentation for the installation route that matches your setup, and check the supported Python range, because the package targets a wide span of interpreters and that range is where the compatibility surprises will be.

## FAQ

### What is AppDaemon?

A loosely coupled, multi-threaded, sandboxed Python execution environment for writing home automation apps, with a pluggable architecture so it can be integrated with practically any event driven application. It ships HADashboard, a configurable dashboard intended for wall mounted tablets.

### How often are new AppDaemon versions released?

Slowly, and the readme says so directly. The project has reached a very stable point, works reliably and is fairly feature rich, so releases have been slow in recent months, with 4.5.11 in June 2025, 4.5.12 in October 2025 and 4.5.13 in January 2026. The readme stresses this does not mean the project is abandoned.

### Which Python versions does AppDaemon support?

The package requires Python 3.10 or newer and below 3.15, with classifiers for 3.10 through 3.14. The uvloop dependency is marked as not applicable on Windows, so the server runs on the standard event loop there.

### What protocols does AppDaemon use to talk to my home automation system?

It speaks HTTP through aiohttp with Jinja2 templating, MQTT through the Paho client, and it exposes real time channels with python-socketio and sockjs for the dashboard. It also parses feeds, and uses bcrypt for hashing and pydantic for validation.

## Sources

- [AppDaemon/appdaemon on GitHub](https://github.com/AppDaemon/appdaemon)
- [Issues](https://github.com/AppDaemon/appdaemon/issues)
- [README](https://github.com/AppDaemon/appdaemon/blob/dev/README.md)
- [Releases](https://github.com/AppDaemon/appdaemon/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/appdaemon-appdaemon