Deploy and Host Roster

Roster is Superset, multiplayer: channels and threads for a team, where the threads run agents on real repos. This template deploys the whole thing — the web app, its database, and the realtime transport — as three connected services.

About Hosting Roster

Roster is a Next.js application backed by Postgres, with Centrifugo carrying messages in realtime. The web service builds from the repository's Dockerfile and applies its own database migrations on boot, so a fresh Postgres volume becomes a working schema during the first deploy with nothing to run by hand. The services reach each other over Railway's private network; only the web app and Centrifugo take public domains. Sign-in is by magic link, which is why the only configuration this template asks for is how mail goes out.

Why Deploy Roster on Railway?

Roster is three services that have to agree with each other. The browser needs Centrifugo's public URL while the server uses its private one, and both sides have to share the same API key and HMAC secret. Railway expresses those as references rather than copied strings, so the template generates each secret once and points both services at the same value — there is nothing to keep in sync by hand, and nothing to paste twice.

The app's public URL is compiled into the browser bundle at build time rather than read at runtime. Railway passes service variables into the build, so the domain it assigns is baked into the bundle on the first deploy without being known in advance.

Common Use Cases

Giving a team a private place to talk where threads can run coding agents against real repositories
Self-hosting chat on infrastructure you control, with the database and message history staying in your own project
Running an internal instance for a team already working in Superset

Dependencies for Roster Hosting

Postgres, included in this template
Centrifugo, included in this template
A Resend account, only if you want magic links delivered as email

Deployment Dependencies

Resend — optional. EMAIL_FROM accepts Roster , and entering a single space for RESEND_API_KEY leaves email off: magic links are printed in the web service's deploy logs instead, which is enough to sign in and look around.

Implementation Details

Two values are asked for, both email: EMAIL_FROM and RESEND_API_KEY. They are asked for because a template carries its source project's values, and this deployment's answers are a real sending domain and a real API key.

Everything else resolves by itself. Some of the resulting expressions look odd in the dashboard — PGPORT is ${{ secret(1, "5") }}432 rather than 5432 — because Railway carries a value into a template only when it is stored as an expression. A single-character charset makes secret deterministic, which is what turns an expression back into a fixed string.