The official self-host compose never starts the pairing sidecar, so mobile pairing 404s
Author: meeveemCreated Sep 18, 2026Updated Sep 18, 2026
Severity: high — affects every self-hoster.
deploy/compose/compose.yml defines only relay, postgres, redis, minio
and minio-init. deploy/compose/Caddyfile routes everything to relay:3000.
The relay advertises NIP-43 in its NIP-11, so Desktop derives the legacy
pairing path <relay>/pair (desktop/src-tauri/src/commands/pairing.rs,
resolve_pairing_relay_url) — but nothing serves it.
Reproduction:
curl -s -o /dev/null -w '%{http_code}\n' --http1.1 \
-H 'Connection: Upgrade' -H 'Upgrade: websocket' \
-H 'Sec-WebSocket-Version: 13' -H 'Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==' \
https://<relay>/pair # 404Desktop shows WebSocket connection failed: HTTP error: 404 Not Found and the
QR flow times out.
The binary is already in the image (/usr/local/bin/buzz-pair-relay), so the
fix is a service plus a Caddy route. Two notes for whoever writes it:
- The image sets
ENTRYPOINT=["/usr/local/bin/buzz-relay"], so the service must overrideentrypoint, notcommand— otherwise the relay binary runs again and crash-loops on the missing relay private key. - The sidecar accepts any path (
crates/buzz-pair-relay/src/lib.rs), so a plain/pair*reverse proxy works.
Source: block/buzz