Slavi PantaleevandClaude Opus 5
6bdcddb79a
baibot is the first bot rather than a bridge, and the shape differs from the appservices: it is a plain Matrix client that logs in with a password, sets up its profile and then syncs. It publishes no port, so nothing can be probed over HTTP; what it says about itself in the journal is the only window into whether the role's configuration reached the process. What the scenario proves: - The unit is active with no automatic restarts, AND baibot got past startup into its sync loop. The second half is what carries the scenario. baibot never exits when startup goes wrong - it retries the failing step forever with a growing delay - so the unit sits there `active` with `NRestarts` at 0 while the bot is permanently half-started. Pointing `user.avatar` at a file that is not there reproduces exactly that: the unit assertion still passes, the sync assertion does not. - The display name the bot announces it wants is the role's `user.name`, which is neither the role's default nor what the stub reports the account already has. - The rendered `logging` string took effect per target: baibot's own records appear at DEBUG (the role ships `info`) while everything underneath stays at the `warn` catch-all. The second half is the control, and raising the catch-all turns 2 DEBUG records into 161. - The rendered config carries the scenario's homeserver, identity, command prefix, admin patterns and user patterns, and uses password authentication exclusively, with the access-token keys rendered as nulls. - The statically-defined agent survived the provider templating - the per-provider template rendered to YAML, parsed, merged and nested into the list - key by key. - The container runs as the uid/gid the playbook supplies (1234, not the 1000 the base image already has), on the image version defaults/main.yml pins, and could write its session into the data path. No AI provider is contacted and none is needed. baibot calls a provider only when a message asks an agent to do something, so a static agent with a placeholder key and a base URL that resolves nowhere still has to survive the bot's startup parsing - which is the part worth testing. The shared stub grew what a syncing Matrix client needs and an appservice did not: /sync (with a `next_batch`, and holding the call open for the timeout the client asked for, or the bot spins the stub in a hot loop), the media config and upload endpoints a bot setting its own avatar insists on, /keys/upload with its key counts, and filter creation. Without the media config in particular, baibot never gets past profile setup. The shared stub task gained a STUB_VERBOSE knob. The stub already advertised the environment variable but there was no way to set it from a scenario, and for a component with no port of its own its request log is the only place to see what the component is actually asking for. Note: molecule-shared/homeserver-stub.py also carries a loosened /login match from another scenario being written in this same tree at the same time; it was already in the working copy and is not mine. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01SEH3vxYSQ5SV4N5z61eyGT
Matrix (An open network for secure, decentralized communication) server setup using Ansible and Docker
🎯 Purpose
This Ansible playbook is meant to help you run your own Matrix homeserver, along with the various services related to that.
That is, it lets you join the Matrix network using your own user ID like @alice:example.com, all hosted on your own server (see prerequisites).
We run all supported services in Docker containers (see the container images we use), which lets us have a predictable and up-to-date setup, across multiple supported distros (see prerequisites) and architectures (x86/amd64 being recommended).
Installation (upgrades) and some maintenance tasks are automated using Ansible (see our Ansible guide).
☁ Self-hosting or Managed / SaaS
This Ansible playbook tries to make self-hosting and maintaining a Matrix server fairly easy (see Getting started). Still, running any service smoothly requires knowledge, time and effort.
If you like the FOSS spirit of this Ansible playbook, but prefer to put the responsibility on someone else, you can also get a managed Matrix server from etke.cc (both hosting and on-premises) - a service built on top of this Ansible playbook but with additional components and services which all help you run a Matrix server with ease. Be advised that etke.cc operates on a subscription-based approach and there is no "just set up my server once and be done with it" option.
🚀 Getting started
We have detailed documentation in the docs/ directory - see the Table of Contents in the documentation README.
While the list of supported services and documentation is very extensive, you don't need to read through everything. We recommend:
-
Starting with the basics. You can always add/remove or tweak services later on.
-
Following our installation guide. There are two guides available for beginners and advanced users:
-
⚡ Quick start (for beginners): this is recommended for those who do not have an existing Matrix server and want to start quickly with "opinionated defaults".
-
Full installation guide (for advanced users): if you need to import an existing Matrix server's data into the new server or want to learn more while setting up the server, follow this guide by starting with the Prerequisites documentation page.
-
If you experience an issue on configuring the playbook, setting up your server, maintaining services on it, etc., please take a look at our FAQ. If you cannot find an answer to your question, feel free to ask for help and support.
✔ Supported services
Using this playbook, you can get the following list of services configured on your server. Basically, this playbook aims to get you up-and-running with all the necessities around Matrix, without you having to do anything else.
Notes:
-
The list below is exhaustive. It includes optional or even some advanced components that you will most likely not need. Sticking with the defaults (which install a subset of the above components) is the best choice, especially for a new installation. You can always re-run the playbook later to add or remove components.
-
Deprecated or unmaintained services are not listed. You can find documentations for them here.
Homeserver
The homeserver is the backbone of your Matrix system. Choose one from the following list.
| Name | Default? | Description | Documentation |
|---|---|---|---|
| Synapse | ✅ | Storing your data and managing your presence in the Matrix network | Link |
| Conduit | ❌ | Storing your data and managing your presence in the Matrix network. Conduit is a lightweight open-source server implementation of the Matrix Specification with a focus on easy setup and low system requirements | Link |
| continuwuity | ❌ | Storing your data and managing your presence in the Matrix network. | Link |
| Tuwunel | ❌ | Storing your data and managing your presence in the Matrix network. Tuwunel is the official successor to conduwuit. | Link |
| Dendrite | ❌ | Storing your data and managing your presence in the Matrix network. Dendrite is a second-generation Matrix homeserver written in Go, an alternative to Synapse. | Link |
Clients
Web clients for Matrix that you can host on your own domains.
| Name | Default? | Description | Documentation |
|---|---|---|---|
| Element Web | ✅ | Default Matrix web client, configured to connect to your own Synapse server | Link |
| Hydrogen | ❌ | Lightweight Matrix client with legacy and mobile browser support | Link |
| Cinny | ❌ | Simple, elegant and secure web client | Link |
| Sable | ❌ | Simple, elegant and secure web client | Link |
| SchildiChat Web | ❌ | Based on Element Web, with a more traditional instant messaging experience | Link |
| FluffyChat Web | ❌ | The cutest messenger in Matrix | Link |
| Commet | ❌ | Matrix web client | Link |
Server Components
Services that run on the server to make the various parts of your installation work.
| Name | Default? | Description | Documentation |
|---|---|---|---|
| PostgreSQL | ✅ | Database for Synapse. Using an external PostgreSQL server is also possible. | Link |
| Traefik | ✅ | Web server, listening on ports 80, 443 and 8448 - standing in front of all the other services. Using your own webserver is also possible. | Link |
| Let's Encrypt | ✅ | Free SSL certificate, which secures the connection to all components | Link |
| Exim | ✅ | Mail server, through which all Matrix services send outgoing email (can be configured to relay through another SMTP server) | Link |
| coturn | ❌ | STUN/TURN server for WebRTC audio/video calls | Link |
| ddclient | ❌ | Dynamic DNS | Link |
| Matrix RTC stack | ❌ | Supporting components (LiveKit Server and LiveKit JWT Service) for in-app audio/video calls for Matrix clients | Link |
Authentication
Extend and modify how users are authenticated on your homeserver.
| Name | Default? | Description | Documentation |
|---|---|---|---|
| matrix-synapse-rest-auth (advanced) | ❌ | REST authentication password provider module | Link |
| matrix-synapse-shared-secret-auth (advanced) | ❌ | Password provider module | Link |
| matrix-synapse-ldap3 (advanced) | ❌ | LDAP Auth password provider module | Link |
| Matrix User Verification Service | ❌ | Service to verify details of a user based on an Open ID token | Link |
| synapse-simple-antispam (advanced) | ❌ | Spam checker module | Link |
File Storage
Use alternative file storage to the default media_store folder.
| Name | Default? | Description | Documentation |
|---|---|---|---|
| Goofys | ❌ | Amazon S3 (or other S3-compatible object store) storage for Synapse's content repository (media_store) files |
Link |
| synapse-s3-storage-provider | ❌ | Amazon S3 (or other S3-compatible object store) storage for Synapse's content repository (media_store) files |
Link |
| matrix-media-repo | ❌ | Highly customizable multi-domain media repository for Matrix. Intended for medium to large deployments, this media repo de-duplicates media while being fully compliant with the specification. | Link |
Bridges
Bridges can be used to connect your Matrix installation with third-party communication networks.
Bots
Bots provide various additional functionality to your installation.
| Name | Default? | Description | Documentation |
|---|---|---|---|
| baibot | ❌ | Bot that exposes the power of AI / Large Language Models to you | Link |
| matrix-reminder-bot | ❌ | Bot for scheduling one-off & recurring reminders and alarms | Link |
| maubot | ❌ | Plugin-based Matrix bot system | Link |
| Honoroit | ❌ | Helpdesk bot | Link |
| Mjolnir | ❌ | Moderation tool for Matrix | Link |
| Draupnir | ❌ | Moderation tool for Matrix (Fork of Mjolnir) | Link (for appservice mode) |
| Meowlnir | ❌ | Moderation tool for Matrix, running in appservice mode | Link |
| Buscarron | ❌ | Web forms (HTTP POST) to Matrix | Link |
Administration
Services that help you in administrating and monitoring your Matrix installation.
| Name | Default? | Description | Documentation |
|---|---|---|---|
| matrix-alertmanager-receiver | ❌ | Prometheus' Alertmanager client | Link |
| Matrix Authentication Service | ❌ | OAuth 2.0 and OpenID Provider server | Link |
| Ketesa | ❌ | Fully-featured web UI for administrating your Matrix homeserver — users, rooms, media, sessions, and more | Link |
| Metrics and Graphs | ❌ | Consists of the Prometheus time-series database server, the Prometheus node-exporter host metrics exporter, and the Grafana web UI, with prometheus-nginxlog-exporter being available too | Link (for prometheus-nginxlog-exporter) |
| Borg | ❌ | Backups | Link |
| rageshake | ❌ | Bug report server | Link |
| synapse-usage-exporter | ❌ | Export the usage statistics of a Synapse homeserver to be scraped by Prometheus. | Link |
Misc
Various services that don't fit any other categories.
| Name | Default? | Description | Documentation |
|---|---|---|---|
| synapse_auto_compressor | ❌ | Cli tool that automatically compresses state_groups database table in background |
Link |
| Matrix Corporal (advanced) | ❌ | Reconciliator and gateway for a managed Matrix server | Link |
| Matrix.to | ❌ | Simple URL redirection service for the Matrix ecosystem | Link |
| Etherpad | ❌ | Open source collaborative text editor | Link |
| Jitsi | ❌ | Open source video-conferencing platform | Link |
| Cactus Comments | ❌ | Federated comment system built on Matrix | Link |
| Pantalaimon | ❌ | E2EE aware proxy daemon | Link |
| Sygnal | ❌ | Push gateway | Link |
| ntfy | ❌ | Push notifications server | Link |
| Element Call | ❌ | A native Matrix video conferencing application | Link |
🆕 Changes
This playbook evolves over time, sometimes with backward-incompatible changes.
When updating the playbook, refer to the changelog to catch up with what's new.
🆘 Support
-
Matrix room: #matrix-docker-ansible-deploy:devture.com
-
IRC channel:
#matrix-docker-ansible-deployon the Libera Chat IRC network (irc.libera.chat:6697) -
GitHub issues: spantaleev/matrix-docker-ansible-deploy/issues
🌐 Translation
See the i18n/README.md file for more information about translation.
Translations are still work in progress.
🤝 Related
You may also be interested in mash-playbook - another Ansible playbook for self-hosting non-Matrix services (see its List of supported services).
mash-playbook also makes use of Traefik as its reverse-proxy, so with minor interoperability adjustments, you can make matrix-docker-ansible-deploy and mash-playbook co-exist and host Matrix and non-Matrix services on the same server.