#7721·buzz

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:

bash
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        # 404

Desktop 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 override entrypoint, not command — 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.