# opsdroid: a Python chat-ops framework that runs your skills across chat services

> opsdroid is an open source chat-ops bot framework written in Python. It takes events from chat services and other sources and runs your Python functions against them, with connectors, parsers and databases selected through packaging extras. The README links to external docs rather than documenting installation itself, so the packaging configuration is where you learn what is actually available.

**opsdroid/opsdroid** — 🤖 An open source chat-ops bot framework

- Repository: https://github.com/opsdroid/opsdroid
- Website: https://opsdroid.dev
- Stars: 868 · Forks: 431
- Language: Python
- License: Apache-2.0
- Published: 2026-10-20 · Updated: 2026-10-20 · Language: en
- Canonical page: https://hysenlabs.com/projects/opsdroid-opsdroid

## What opsdroid is actually for

Chat-ops means running operational tasks from a chat room. Someone types a command in a channel, something parses it, and a piece of code does the work and reports back. The idea is not new, and plenty of teams implement it directly against one platform's API.

opsdroid is a framework for that pattern. The README describes it as an open source chatbot framework written in Python, designed to be extendable, scalable and simple, and says it is designed to take events from chat services and other sources and execute Python functions, called skills, based on their contents.

The framing of those skills is deliberately open. The README says they can be anything, from simple conversational responses to running complex tasks. The claim it makes for the project is that of a glue library bringing natural language APIs, chat services and third-party APIs together.

That framing explains the shape of the project better than any feature list would. opsdroid is not trying to be a product with a fixed feature set; it is trying to be the layer that a team writes their own tasks against, so the same skill works whether the request arrives in Slack, in Matrix or from a source that is not a chat service at all.

The audience is DevOps and platform engineers who have already decided that chat is their interface to infrastructure, and who would rather write their automation once than once per chat platform.

## Connectors, parsers and skills as the extension points

The project topics list the surfaces opsdroid is meant to cover: Slack, Matrix, Telegram, Microsoft Teams, Messenger, GitHub, Gitter and Webex Teams, alongside chatops, nlu and asyncio.

The names of those platforms tell you what the connectors are for, but the repository layout is what explains the extension model. The package lives in the opsdroid directory, tests sit in tests/, documentation in docs/, and the packaging configuration in setup.py and setup.cfg drives what can be installed. The extras in setup.py are grouped by category: all_connectors collects every extra whose name starts with connector, all_databases collects the ones starting with database, and all_parsers collects the ones starting with parser.

That grouping is the design in miniature. A connector receives events from one platform, a parser turns an incoming message into something a skill can act on, and a skill is the Python function that does the work. A database extra covers where state is kept. The all extra is the union of everything except the ones listed in not_all.

The framework also documents where it stops. The not_all list contains test and docs, plus connector_matrix_e2e, with a comment explaining that end-to-end encryption has to be opted into because of difficult compile time dependencies. That is a sensible boundary for a Matrix deployment with encryption enabled, and it is also a hint about the cost of the Matrix connector compared with the others.

## The packaging extras tell you what you can install

The README does not contain an installation command. It points at the documentation site for a quick start, and the PyPI badge shows the published version. To find out what the project actually ships, read setup.py, which reads the extras from setup.cfg and then adds the grouped ones.

```python
extras = read_configuration("setup.cfg")["options"]["extras_require"]
common_extras = ["connector_matrix", "connector_slack", "database_sqlite"]
not_all = (
    "test",
    "docs",
    # We want people to have to opt-into e2ee at the moment because of
    # difficult compile time dependancies.
    "connector_matrix_e2e",
)
```

So a minimal deployment can take the common set, which is the Matrix connector, the Slack connector and the SQLite database. A broader one can take all_connectors, all_databases or all_parsers, and all covers everything else at once.

Two details are worth noticing. The extras come from setup.cfg rather than being hard coded, so the authoritative list of connector, parser and database extras lives in that file. And the all group is deliberately not everything, since test and docs are excluded along with the encryption connector.

The practical consequence: when you read the docs and see a capability, check the matching extra in setup.cfg before you assume a plain install brings it in.

## The Dockerfile builds wheels before it installs anything

The repository ships a Dockerfile, and it is worth reading as a deployment recipe rather than as boilerplate. It is a two stage build on an Alpine base image.

```dockerfile
ARG BASE_IMAGE="python:3.13-alpine"
# only touch the line above after reading docs/maintaining/supported-python-versions.md

FROM $BASE_IMAGE AS builder
LABEL maintainer="Jacob Tomlinson <jacob@tomlinson.email>"

WORKDIR /usr/src/app

ARG EXTRAS=[all,connector_matrix_e2e]
ENV DEPS_DIR=/usr/src/app/deps
```

The builder stage installs the toolchain and the native libraries the connectors need, including olm for Matrix, zeromq and the build essentials, then downloads the dependencies as wheels into a dependency directory. The runtime stage copies only the built wheels and installs them without an index.

That last step is the point of the two stage layout. The runtime image does not need a compiler, because nothing is compiled there.

```dockerfile
    && pip install --no-cache-dir --no-index -f ${DEPS_DIR} \
    $(find ${DEPS_DIR} -type f -name opsdroid-*-any.whl)${EXTRAS} \
    && rm -rf /tmp/* /var/tmp/* ${DEPS_DIR}/* \
    && adduser -u 1001 -D opsdroid
```

Two more choices stand out. The extras list is a build argument, so an image can be built with all connectors and the encrypted Matrix support, or with a narrower set. And the runtime container adds a dedicated unprivileged user with uid 1001, so the bot does not run as root.

The comment on the first line is a maintenance instruction rather than a warning about the image: changing the base image version is only appropriate after reading the supported Python versions note in the documentation.

## Documentation, playground and community channels

A chat bot framework lives or dies on its documentation, and opsdroid points at several places to look.

The primary one is the documentation site at docs.opsdroid.dev, with a quick start page linked directly from the README banner and a separate documentation area linked next to it. There is also a playground at playground.opsdroid.dev, which the README lists among its top links, and a project blog.

For questions, the README points at a Matrix room hosted on the matrix.org server, and for contributions it links to the contributing guide in the documentation and a code of conduct file in the repository root. The project is funded through Open Collective as both a backer and a sponsor project, so the README carries the standard badge blocks for both roles.

The repository itself carries the tooling you would expect from a Python project of this size: a tox.ini for test environments, a conftest.py at the root, coverage configuration in .coveragerc and codecov.yml, a pre-commit configuration, requirements_dev.txt and requirements_readthedocs.txt for the documentation build, and versioneer.py for version stamping.

That list is a fair signal of how the project is run, though it says nothing about the quality of any individual skill you write with it.

## Release history and the maintenance picture

The maintenance facts here are worth stating plainly rather than reading as a verdict.

The last push to the repository was on 2026-05-05. The release tags tell a slower story: v0.31.0 was published on 2025-04-30, and both v0.30.0 and v0.29.1 carry the date 2024-04-25. So the most recent published release is a patch level above a release that is over a year old, while commits have continued to land on the main branch since.

That gap has two practical consequences. First, the project is still on a 0.x version, where the version number carries no promise of a stable interface, so pinning a version in a deployment is a decision to make deliberately. Second, if you need a specific connector behaviour, the branch may differ from the last tag, and the release notes for that tag are the place to check what changed.

The licence is Apache 2.0, which covers use, modification and distribution with the usual notice and patent conditions. Whether that licence fits your organisation is a question for your own legal review rather than one to answer from the repository.

The framework runs on Python, with the Dockerfile building on Python 3.13 on Alpine, and the documentation keeps a supported Python versions page that the Dockerfile comment points to. If your infrastructure is on an older Python, that page is the file to read first.

## Where opsdroid is the wrong choice

The clearest case against opsdroid is a bot for one platform. Writing a small handler against the Slack or Telegram API directly is less to install, less to debug and easier to retire, and none of the framework's glue value applies when there is only one glue point.

The second case is a team that wants to own its own chat stack rather than standardise on one. opsdroid deliberately spreads across platforms, and its extras system, connectors, parsers and adapters are the cost of that breadth. A framework with a single connector and no abstraction layer is a smaller thing to learn.

There are limits inside the project too. The README does not document installation, configuration or the skill API, so the entire learning path sits in an external documentation site, which is a risk if that site changes or lags. Encryption support for Matrix is opt-in because of compile time dependencies, so a hardened Matrix deployment needs more work than the default image suggests.

The comparison that actually decides it is between opsdroid and writing the glue yourself for several platforms. If you are on three chat services and intend to stay there, the framework earns its place because the connector, parser and skill split removes the repeated work. If you are on one service with a small team and a short task list, the abstraction costs more than it saves.

## Conclusion

opsdroid fits teams that already run several chat platforms and want one set of Python skills to work across them, with Slack, Matrix, Telegram, Teams, Messenger, GitHub, Gitter and Webex named as connectors in the project topics, and it suits container deployments given the two stage Dockerfile that builds wheels and installs them as an unprivileged user. It is the wrong choice for a single bot on a single platform, where a vendor SDK or a small webhook handler is less machinery, and it is a poor fit if you need a release cadence faster than the one the tags show. Verify first which connectors and parsers your deployment needs, then read setup.cfg for the extras that pull them in, and confirm the Python version your base image targets against the supported versions note referenced in the Dockerfile before you build.

## FAQ

### Which chat platforms does opsdroid support?

The project topics name Slack, Matrix, Telegram, Microsoft Teams, Messenger, GitHub, Gitter and Webex Teams as the connectors the framework covers.

### How do I install opsdroid with only the connectors I need?

The packaging configuration in setup.py defines groups such as common, all_connectors, all_databases and all_parsers, with the connector and database extras listed in setup.cfg. The README itself points to the documentation quick start.

### Does opsdroid support end-to-end encrypted Matrix chats?

Yes, but it must be opted into. The setup.py file lists connector_matrix_e2e in not_all with a comment about difficult compile time dependencies, and the Dockerfile builds with the extras argument set to all and connector_matrix_e2e.

### What licence is opsdroid released under?

The repository lists the Apache 2.0 licence, and the LICENSE file at the root of the repository holds the full text.

## Sources

- [License: Apache-2.0](https://github.com/opsdroid/opsdroid/blob/main/LICENSE)
- [opsdroid/opsdroid on GitHub](https://github.com/opsdroid/opsdroid)
- [Project website](https://opsdroid.dev)
- [README](https://github.com/opsdroid/opsdroid/blob/main/README.md)
- [Releases](https://github.com/opsdroid/opsdroid/releases)

---

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