Part of adopting a uniform naming policy for bridge variables,
where the variable prefix matches the role directory name.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

Part of adopting a uniform naming policy for bridge variables,
where the variable prefix matches the role directory name.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

Part of adopting a uniform naming policy for bridge variables,
where the variable prefix matches the role directory name.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

Part of adopting a uniform naming policy for bridge variables,
where the variable prefix matches the role directory name.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

Part of adopting a uniform naming policy for bridge variables,
where the variable prefix matches the role directory name.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

Part of adopting a uniform naming policy for bridge variables,
where the variable prefix matches the role directory name.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

Part of adopting a uniform naming policy for bridge variables,
where the variable prefix matches the role directory name.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

Part of adopting a uniform naming policy for bridge variables,
where the variable prefix matches the role directory name.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

Part of adopting a uniform naming policy for bridge variables,
where the variable prefix matches the role directory name.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

Part of adopting a uniform naming policy for bridge variables,
where the variable prefix matches the role directory name.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

Part of adopting a uniform naming policy for bridge variables,
where the variable prefix matches the role directory name.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

Part of adopting a uniform naming policy for bridge variables,
where the variable prefix matches the role directory name.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

Part of adopting a uniform naming policy for bridge variables,
where the variable prefix matches the role directory name.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

Part of adopting a uniform naming policy for bridge variables,
where the variable prefix matches the role directory name.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

Part of adopting a uniform naming policy for bridge variables,
where the variable prefix matches the role directory name.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

Part of adopting a uniform naming policy for bridge variables,
where the variable prefix matches the role directory name.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

Part of adopting a uniform naming policy for bridge variables,
where the variable prefix matches the role directory name.

The companion appservice variables defined by this role are folded
under the role prefix as well: matrix_mautrix_androidsms_* becomes
matrix_bridge_mautrix_wsproxy_androidsms_* and matrix_mautrix_imessage_*
becomes matrix_bridge_mautrix_wsproxy_imessage_*.

matrix_mautrix_signal_wsproxy_syncproxy_connection_string becomes
matrix_bridge_mautrix_wsproxy_syncproxy_connection_string, aligning it
with the sibling matrix_bridge_mautrix_wsproxy_syncproxy_* variables.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

With workers enabled, every Synapse process (the main one and each
worker) maintains its own database connection pool of up to
matrix_synapse_database_cp_max (default: 10) connections. The previous
fixed limit of 500 left little headroom on setups running many workers,
where exhausting it manifests as degraded performance and, reportedly,
E2EE misbehavior.

Size the limit as a 200-connection baseline (for everything else that
talks to Postgres) plus cp_max connections per Synapse process, never
going below the previous value of 500. The stock worker presets stay at
500; setups that raise worker counts (or cp_max) get a limit that grows
accordingly. The new matrix_synapse_workers_total_count variable
reflects what the matrix_synapse_workers_*_count variables ask for; it
does not reflect a manually populated
matrix_synapse_workers_enabled_list, and such setups should override
postgres_max_connections themselves.

Fixes #4442

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

Signed-off-by: Kristoffer <kristoffer@weitby.eu>

The bridge could only be installed by self-building its source code,
and its upstream repository (on src.miscworks.net) has become
unreachable (the Internet Archive last saw it alive in May 2026),
making installation impossible. The bridge was also based on the
long-unmaintained node-kakao library and carried a warning that using
it may get KakaoTalk accounts banned.

The playbook catches leftover matrix_appservice_kakaotalk_* variables
and points users to the manual uninstallation instructions.

Related to #5068

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

Matrix Authentication Service supports CAPTCHA protection (ReCaptcha
v2, Cloudflare Turnstile, hCaptcha) for certain operations like
self-service password registration, but configuring it required going
through matrix_authentication_service_configuration_extension_yaml.
Expose it via dedicated variables
(matrix_authentication_service_config_captcha_service, _site_key and
_secret_key), validate the service value and key presence, and document
the setup in the captcha documentation page, which so far only covered
Synapse and Dendrite.

Related to #5344

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

Enabling matrix_hookshot_encryption_enabled configures the bridge side
correctly (registration flags, Valkey cache), but hookshot's encryption
also needs the homeserver to support and enable MSC2409 and MSC3202,
which are typically experimental features disabled by default. Nothing
documented that, so the resulting setup silently did not work.

Reference the MSCs in the variable's comment, and show the exact Synapse
settings in the hookshot documentation page. The playbook deliberately
does not auto-enable them: they are experimental homeserver-wide
features, and flipping them from a bridge toggle would be surprising.

Fixes #3861

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

Element Web redesigned its welcome page into a built-in component
(element-hq/element-web#33211, first released in spring 2026) and no
longer falls back to loading welcome.html. The custom page the playbook
installed had therefore silently stopped having any effect, and it was a
fork of an upstream file that upstream has deleted (its button icon
assets are already missing from current Element Web builds).

Remove the welcome.html shipping and the variables that only applied to
it (matrix_client_element_welcome_headline, _welcome_text,
_welcome_logo_link, _page_template_welcome_path), rejecting them in
validate_config.yml with pointers to the alternatives. Logo and
background customization keep working through Element Web's branding
options, which the new welcome page still honors. A fully custom page
can be self-hosted and wired via embedded_pages.welcome_url.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

The configuration template only rendered a datastore when its for_kinds
list was non-empty, even though the inline documentation (matching
upstream's) describes forKinds: [] as the way to make a datastore
readonly. That made the documented migration scenario impossible: moving
media between the file and s3 datastores while keeping the old one
readable.

Introduce matrix_media_repo_datastore_file_enabled and
matrix_media_repo_datastore_s3_enabled, which default to the previous
kinds-based behavior. A readonly datastore is now expressed by enabling
the datastore explicitly while assigning it no kinds.

Fixes #4303

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

synapse-usage-exporter is self-built by default (no upstream image is
published), so every user enabling it runs the git clone/update task. A
docker-src checkout whose files are owned by a different user (e.g. left
behind by an earlier clone) made that task fail: either with a
permission error, or with git's dubious-ownership protection, which
ignores the repository's own configuration and surfaces as a confusing
"'origin' does not appear to be a git repository" error.

Ensure the checkout's ownership recursively before updating it, and mark
the path as a safe.directory for the git invocation itself (via
GIT_CONFIG_* environment variables), so the ownership check cannot
misfire regardless of which user git effectively runs as.

Fixes #5065

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

The user-namespace regexes in the mautrix-meta-messenger and
mautrix-meta-instagram registration templates interpolated
the bridge username prefix without regex-escaping it, unlike the
neighboring homeserver domain and appservice username values. The
default prefixes are regex-safe, but a customized prefix containing
regex metacharacters would produce a wrong (too broad or invalid)
appservice user namespace.

Related to the registration regex discussion in #5096.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

The playbook-shipped welcome.html hardcoded #2e2f32 for the headline and
welcome text, which is nearly invisible on the dark background Element
renders when the dark theme is active. Element Web's default
use_system_theme behavior keys the theme off the system color scheme, so
switch the text to Element's dark-theme text color (#ebeef2) under a
prefers-color-scheme: dark media query.

Fixes #4838

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

matrix_appservice_discord_container_image_self_build only switched the
image registry prefix to localhost/, but the role never had any build
tasks, so enabling it always ended in an image pull failure. Remove the
variable and reject it in validate_config.yml with a hint that the
prebuilt image is amd64-only and that mautrix-discord is the better
option on other architectures.

Fixes #2379

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

The upstream Synapse Grafana dashboard uses `{{job}}-{{index}}` in its
legends to tell workers apart, but the worker scrape configs only set
instance, worker_id, job and app labels. Without an index label, the
dashboard legends collapsed and workers could not be distinguished.

Derive the index label from the worker id (its per-type index is the
first number in the id, e.g. federation-sender-1, stream-writer-2-events),
matching the index label already set on the main process target.

Fixes #2158
Fixes #2159

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

Element Desktop (Electron) loads the location-sharing map style from a
`vector://vector` origin, so fetching map_style.json from the Element
domain is a cross-origin request. Without an Access-Control-Allow-Origin
header, the request is blocked and maps fail to load with "This homeserver
is not configured correctly to display maps".

Add a dedicated Traefik router for map_style.json that attaches an
Access-Control-Allow-Origin header (configurable via
matrix_client_element_location_sharing_map_style_access_control_allow_origin,
defaulting to `*`). It is only defined when location sharing is enabled.

Fixes #2291

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

Attaches a com.centurylinklabs.watchtower.enable=false label to the
matrix-matrixto container by default, telling Watchtower (if in use)
to skip it. The image is built locally from source, so Watchtower
cannot update it and merely produces 'digest retrieval failed' errors
on every run.

A dedicated variable is used (instead of pre-filling
matrix_matrixto_container_labels_additional_labels) so that people
overriding the additional-labels variable do not lose the label.

Fixes #4820

Based on the report and initial patch in
https://github.com/spantaleev/matrix-docker-ansible-deploy/pull/4821 by @der-domi

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>

The sygnal container images (since v0.16.0) hardcode a HEALTHCHECK which
relies on curl, but the image does not include curl, so the healthcheck
can never pass. See https://github.com/element-hq/sygnal/issues/326

This unblocks upgrading sygnal past v0.15.1.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

This is a major upgrade which performs a one-way database migration
and removes LDAP support upstream.

The continuwuity.toml.j2 template is re-synced with the v26.6.1 example
config. Notably, registration_token is now only rendered when non-empty,
because v26+ refuses to start when it is set to an empty string.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

Signed-off-by: Suguru Hirahara <did🔑z6MkvVZk1A3KBApWJXv2Ju4H14ErDfRGxh8zxdXSZ4vACDg5>

Signed-off-by: Suguru Hirahara <did🔑z6MkvVZk1A3KBApWJXv2Ju4H14ErDfRGxh8zxdXSZ4vACDg5>

- Updated `welcome_background_url` to upstream default *lake.jpg* for the official Matrix Client Element.
- Provoked by: [Convert welcome.html to React component](4b4289e211)