`BUZZ_RELAY_URL` is silently ignored; relay binds the community to `localhost:3000` and 404s every request

[morven-ai]

Self-hosting a relay, I set BUZZ_RELAY_URL (matching the BUZZ_* prefix of every other variable in deploy/compose/compose.yml) and the relay started cleanly — logs showed Postgres connected, Database migrations complete, Deployment community ensured, healthcheck green.

But every request to / returned 404, including the WebSocket upgrade. Clients could not connect at all.

The variable the relay actually reads is RELAY_URL. BUZZ_RELAY_URL is accepted into the process environment and silently ignored, so relay_url stays at its default ws://localhost:3000. The deployment community is then created bound to host localhost:3000, and since the relay resolves the tenant from the Host header, no real request ever matches.

The only signal is the 404 body:

relay: no community is configured for this host

That message is deliberately generic so an unauthenticated caller cannot probe which hosts are mapped, which is the right call for the security property — but it also means an operator who mistyped one variable has nothing to go on. The startup log line Config loaded ... relay_url=ws://localhost:3000 is the only place the truth appears, and it is easy to miss among the healthy-looking lines around it.

I lost several hours to this and only found it by reading router.rs.

Suggestions, roughly in order of value

1. Warn at startup when BUZZ_RELAY_URL is present in the environment but RELAY_URL is not. It is a near-certain operator mistake given every neighbouring variable is BUZZ_-prefixed.
2. Accept BUZZ_RELAY_URL as an alias.
3. Make the startup log line for relay_url prominent (or warn when it is still the default while BUZZ_BIND_ADDR is a non-loopback address).

Happy to send a PR for (1) if that is the direction you would take.

Environment: relay ghcr.io/block/buzz:main, self-hosted via deploy/compose, single tenant behind a TLS reverse proxy.