The companion role was tightly coupled to Synapse through shared tags, worker routing, and lifecycle ordering. Keeping them separate added coordination overhead without practical benefits, especially for parallelized execution.
This merges the role into matrix-synapse while keeping companion logic organized under dedicated reverse_proxy_companion task/template subdirectories.
Compatibility is preserved:
- matrix_synapse_reverse_proxy_companion_* variable names remain unchanged
- install/setup companion-specific tags remain available
Cross-role/global wiring is now in group_vars (matrix-synapse section), while role defaults provide sensible standalone defaults and self-wiring for Synapse-owned values.
Only queue matrix-goofys.service for restart when Synapse is enabled. Goofys is installed from the Synapse role, so non-Synapse homeserver configurations should not try to restart this unit. This mirrors the fix for issue https://github.com/spantaleev/matrix-docker-ansible-deploy/issues/4959.
Only queue matrix-synapse-s3-storage-provider-migrate.timer for restart when Synapse is actually enabled. This prevents setup/install failures when a Synapse-only extension flag is set while using another homeserver implementation, as reported in https://github.com/spantaleev/matrix-docker-ansible-deploy/issues/4959.
When using an external nginx (e.g. on a separate host) to reverse-proxy
the LiveKit JWT Service at a path prefix, the nginx location block MUST
include a trailing slash.
Without it: `location ^~ /livekit-jwt-service` + `proxy_pass .../;`
replaces `/livekit-jwt-service` with `/`, producing `//get_token`
(double slash). Go's net/http issues a 301 redirect to normalize the
path. Element Call follows the redirect to the wrong URL, fails to get a
JWT token, and the call establishes at the Matrix signaling level but
without any audio or video.
With trailing slash: `location ^~ /livekit-jwt-service/` replaces the
prefix correctly, producing `/get_token` with a single slash.
The same trailing-slash rule applies to the livekit-server location
block to avoid path issues for any sub-paths.
The built-in Traefik setup is unaffected (uses stripprefix middleware).
https://claude.ai/code/session_01SbRgWsRDKpTZ2TTbWDhtEB
- Revert setup.yml to use galaxy/livekit_server (avoids loading all
uninstalled galaxy roles when running with --tags)
- Add livekit.yml: minimal standalone playbook that only includes
galaxy/systemd_docker_base and custom/livekit_server, so livekit
setup can run independently without requiring all other galaxy roles
Usage:
ansible-playbook -i inventory/hosts livekit.yml \
--tags=setup-livekit-server,start-group-services
https://claude.ai/code/session_01SbRgWsRDKpTZ2TTbWDhtEB
The upstream galaxy/livekit_server role never publishes port 7880 (HTTP
signaling) to the host — it assumes a Traefik container on the same Docker
network. This breaks setups where nginx runs on a separate host and proxies
to the Matrix server over LAN.
Changes:
- Fork galaxy/livekit_server → roles/custom/livekit_server/ so the patch
survives `make roles` (which wipes roles/galaxy/)
- Add livekit_server_container_http_host_bind_port variable (defaults to "")
in defaults/main.yml; when set, publishes the HTTP port via -p flag
- Add {% if livekit_server_container_http_host_bind_port %} block in the
systemd service template to conditionally map the port
- Guard network-creation tasks with `and livekit_server_container_network != 'host'`
to prevent 403 errors when network: host is configured
- Update setup.yml: galaxy/livekit_server → custom/livekit_server
Usage in vars.yml:
livekit_server_container_http_host_bind_port: '192.168.90.83:7880'
https://claude.ai/code/session_01SbRgWsRDKpTZ2TTbWDhtEB
The startup issue came from a timing dependency around coturn TLS certs:
- `matrix-coturn.service` depends on
`matrix-traefik-certs-dumper-wait-for-domain@<matrix-fqdn>.service`
- That waiter succeeds only after Traefik has obtained and dumped a cert for
the Matrix hostname (typically driven by homeserver labels/routes becoming
active)
- If coturn is started too early, it can block/fail waiting for cert files
that are not yet present
Historically, coturn priority was mode-dependent:
- `one-by-one`: coturn at 1500 (delayed after homeserver)
- other modes: coturn at 900 (before homeserver)
This could still trigger undesirable startup ordering and confusing behavior
in non-`one-by-one` modes, especially during initial bootstrap/restart flows
where cert availability lags service startup.
This change makes ordering explicit and consistent:
1. Introduce `matrix_homeserver_systemd_service_manager_priority` (default 1000)
in `roles/custom/matrix-base/defaults/main.yml`.
2. Use that variable for the homeserver service entry in
`group_vars/matrix_servers`.
3. Set coturn priority relative to homeserver priority in all modes:
`matrix_homeserver_systemd_service_manager_priority + 500`.
4. Update inline documentation comments in `group_vars/matrix_servers` to
match the new behavior and rationale.
Result:
- Homeserver/coturn ordering is deterministic and mode-agnostic.
- Coturn is intentionally started later than the homeserver by default,
reducing first-start certificate wait/fail races.
- Priority intent is now centralized and configurable via a dedicated
homeserver priority variable.
- Coturn may still be stated earlier, because the homeserver typically
has a `Wants` "dependency" on it, but that's alright
Users reported that /.well-known/matrix/* stopped being served after the image bump to static-web-server v2.41.0.
Regression introduced by commit 32aeaca28b in PR #4951: https://github.com/spantaleev/matrix-docker-ansible-deploy/pull/4951
Root cause: upstream changed hidden-file handling defaults, so paths under /.well-known were treated as hidden and no longer served by default.
Fix by explicitly configuring SERVER_IGNORE_HIDDEN_FILES=false in the matrix-static-files role and rendering it as a JSON boolean in the env template, making behavior stable across upstream default changes.