Hoppscotch self-hosted: which features require a backend in production behind a reverse proxy?

Context

Running Hoppscotch locally with docker-compose masks backend dependency because the UI and optional backend share localhost, so CORS preflight and cookie handling succeed without explicit configuration. In production behind a reverse proxy (for example, Nginx or Traefik), the same UI build fails to reach environment, collection, and auth endpoints when the backend base URL is not set, and WebSocket or Server-Sent Events connections drop if Upgrade and Connection headers are not forwarded.

Unresolved decision

The project has not clearly documented which capabilities—environment sync, pre-request scripts, OAuth flows, real-time collaboration—strictly require a self-hosted backend versus functioning in a fully static deployment. Behavior varies across releases, and the web, desktop, and self-hosted web variants follow different networking paths.

Goal

Determine the minimal backend requirement for a production self-hosted deployment behind a reverse proxy so that teams can decide whether to provision the backend service or run a static-only build.

Which Hoppscotch features are confirmed to work without a backend in a reverse-proxied production deployment? Does the documentation or source code define a clear feature matrix for static versus backend-dependent modes? What verification steps can confirm that a given release behaves as expected for a chosen deployment model?