Architecture

COMMS runs as an isolated stack — its own Next.js app, its own Postgres database, its own deployment lifecycle. It integrates with the existing LdDrako broadcast engine via a small, versioned Broadcast Public API v1.

Browser
  ├─ HTTPS → comms.lddrako.com (Next.js BFF)
  │           ├─ own Postgres (auth + audit)
  │           ├─ Discord REST (guild membership)
  │           └─ Broadcast Public API v1 (JWT-auth, loopback)
  └─ WSS  → AudioRelay (proxied to broadcast service :8460)

Why isolated

• Independent failure domain — if the dashboard is down, the bots keep working; if the broadcast engine is down, the marketing site stays up.
• Independent auth — the dashboard speaks Discord OAuth; the broadcast engine doesn't need to know about Firebase or any other identity layer.
• Independent release cadence.

Why a shared engine

Re-implementing the bot pool, the matrix coordinator, and the audio relay would mean rebuilding the entire reason the broadcast service exists. Instead the dashboard treats the broadcast engine as an external service with a typed REST contract.