5b7a1c2a6c
Matches the earlier Python -> Go rewrites of the other mautrix-* bridges. Related to: - https://github.com/mautrix/telegram/releases/tag/v0.2604.0 - https://mau.fi/blog/2026-04-mautrix-release/ The bridge is now a Go binary with upstream-handled automatic database and config migration on first start, so in-place upgrades on Postgres should Just Work for users on the defaults. The lottieconverter sidecar container is gone (bundled upstream), and the public web-based login endpoint is gone (login happens inside Matrix now). Upstream v0.2604.0 has a known bug in the legacy SQLite migration that can corrupt data. The role detects legacy Python-bridge SQLite databases (via the `telethon_sessions` table signature) and refuses to upgrade, pointing users to switch to Postgres (playbook-managed pgloader migration) or wait for the next upstream release. The guard is isolated in its own `validate_config_sqlite_legacy_migration_bug.yml` so it can be deleted cleanly once upstream fixes the bug. Removed variables (all caught by the deprecation check in `validate_config.yml` with actionable rename/removal hints): the entire `_hostname` / `_path_prefix` / `_scheme` / `_public_endpoint` / `_appservice_public_*` / `_container_labels_public_endpoint_*` / `_container_http_host_bind_port` family (web login endpoint is gone); `_bot_token` (old-style relaybot is gone, use the common bridgev2 relay mode); `_filter_mode` (dropped upstream); `_bridge_login_shared_secret_map*` (use Appservice Double Puppet); `_username_template`, `_alias_template`, `_displayname_template` (templates moved under `network:`, new Go-template syntax, exposed via `_network_displayname_template`); all `_lottieconverter_*` variables; `_appservice_database` (renamed to `_appservice_database_uri`). Added playbook-time validation that catches legacy permission values (`relaybot`, `puppeting`, `full`) in the fully-merged config (so overrides via `matrix_mautrix_telegram_configuration_extension_yaml` are caught too), with a mapping hint in the error message. Other notes: - The legacy sqlite->postgres relocation of `{base_path}/mautrix-telegram.db` to `{data_path}/mautrix-telegram.db` now happens BEFORE the pgloader migration step, so users who flip to Postgres as part of this upgrade get their data imported correctly. - The Ketesa managed-user regex for the telegram namespace is updated to match both regular IDs and the new `channel-<id>` form used by bridgev2. - `matrix_playbook_migration_expected_version` bumped to v2026.04.24.0, with a new breaking-change entry pointing at the CHANGELOG section. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
5.1 KiB
Setting up Mautrix Telegram bridging (optional)
Refer the common guide for configuring mautrix bridges: Setting up a Generic Mautrix Bridge
The playbook can install and configure mautrix-telegram for you.
See the project's documentation to learn what it does and why it might be useful to you.
Prerequisites
Obtain a Telegram API key
To use the bridge, you'd need to obtain an API key from https://my.telegram.org/apps.
Enable Appservice Double Puppet (optional)
If you want to set up Double Puppeting (hint: you most likely do) for this bridge automatically, you need to have enabled Appservice Double Puppet service for this playbook.
See this section on the common guide for configuring mautrix bridges for details about setting up Double Puppeting.
Adjusting the playbook configuration
To enable the bridge, add the following configuration to your inventory/host_vars/matrix.example.com/vars.yml file. Make sure to replace YOUR_TELEGRAM_APP_ID and YOUR_TELEGRAM_API_HASH.
matrix_mautrix_telegram_enabled: true
matrix_mautrix_telegram_api_id: YOUR_TELEGRAM_APP_ID
matrix_mautrix_telegram_api_hash: YOUR_TELEGRAM_API_HASH
Relaying
This bridge supports the common mautrix bridge relay mode. Once enabled, any authenticated user can be turned into a relaybot for a chat by sending !tg set-relay in that chat.
Configure a user as an administrator of the bridge (optional)
You might also want to give permissions to a user to administrate the bot. See this section on the common guide for details about it.
Extending the configuration
There are some additional things you may wish to configure about the bridge.
See this section on the common guide for configuring mautrix bridges for details about variables that you can customize and the bridge's default configuration, including bridge permissions, encryption support, bot's username, etc.
Installing
After configuring the playbook, run it with playbook tags as below:
ansible-playbook -i inventory/hosts setup.yml --tags=setup-all,start
The shortcut commands with the just program are also available: just install-all or just setup-all
just install-all is useful for maintaining your setup quickly (2x-5x faster than just setup-all) when its components remain unchanged. If you adjust your vars.yml to remove other components, you'd need to run just setup-all, or these components will still remain installed. Note these shortcuts run the ensure-matrix-users-created tag too.
Usage
To use the bridge, you need to start a chat with @telegrambot:example.com (where example.com is your base domain, not the matrix. domain).
You can then follow instructions on the bridge's official documentation on Authentication.
After logging in, the bridge will create portal rooms for all of your Telegram groups and invite you to them.
Troubleshooting
As with all other services, you can find the logs in systemd-journald by logging in to the server with SSH and running journalctl -fu matrix-mautrix-telegram.
Increase logging verbosity
The default logging level for this component is warn. If you want to increase the verbosity, add the following configuration to your vars.yml file and re-run the playbook:
# Valid values: fatal, error, warn, info, debug, trace
matrix_mautrix_telegram_logging_level: debug