Hosted production
How the live Selection Room deployment at selectionroom.org works.
Selection Room runs in production at www.selectionroom.org. This page is a public summary of that deployment; operator runbooks live in the GitHub hosting docs.
Topology
| Concern | Production |
|---|---|
| Web UI | Vercel (Next.js, repo root web/) |
| Run artifacts | Supabase Storage, mirroring the local data/output/api/ layout |
| Run and job metadata | Supabase Postgres |
| Python engine jobs | Trigger.dev background worker |
| Sign-in | Supabase Auth with GitHub |
The JSON artifact contract is identical in local and hosted mode: the same files the engine writes to disk locally are uploaded to Storage and served through the same API paths. Pages cannot tell the difference.
Browsing
Browsing is fully open. The site serves a seeded catalog of official runs; anyone can switch runs, read rankings, open team resumes, and use the Validation dashboard with no account.
Launching runs
Signed-in GitHub users can launch live analysis and Scenario Lab runs:
- The API validates the session and quotas, records a queued job, and enqueues a background task.
- The Python worker runs the pipeline, uploads artifacts to Storage, and updates the catalog.
- The browser polls job status and opens the finished run.
Per-user and global daily quotas keep the shared worker available; one hosted job runs at a time. A scheduled weekly official run keeps the default catalog current during the season without anyone launching by hand.
Local mode still works
The open-source local workflow is unchanged: the web app reads exports directly from disk, and run generation uses a local subprocess instead of the hosted worker. Design doctrine that holds in both modes:
- JSON payload shape stays the web contract
- Python remains the analytics source of truth
- The local OSS workflow must keep working
Note
This page intentionally omits environment variables, project references, and deployment steps. Operators should use the hosting docs on GitHub.