Skip to main content
One CRCON install manages up to 10 game servers. The shared core the template deploys (Postgres, Redis, maintenance, webhooks) serves all of them; every additional game server adds exactly three services: a backend, a supervisor, and a frontend. All servers share player profiles, blacklists, VIPs, and accounts because they share the database, and the server switcher in the UI discovers siblings through the shared Redis.
Two hard rules, straight from upstream:
  • Never reuse a SERVER_NUMBER across live services. It namespaces every database record.
  • Never reuse an HLL_REDIS_DB. Redis ships with 16 logical databases, so numbers 1-10 are safe.
Use the same number N for both. Server 1 already uses 1.
This guide adds game server 2. For servers 3, 4, 5 and up, repeat with the next number.

​
Step 1: create the three services

In the deployed project, duplicate the existing services (right-click, Duplicate) or create them fresh from the sources below. Create all three before editing variables, because they reference each other’s domains.

​
Step 2: set the variables

Duplicated services inherit server 1’s variables. Everything stays the same except the rows below.

​
Backend2

All the HLL_DB_* references, Redis host and port, logging variables, and PORT stay unchanged.

​
Supervisor2

RCONWEB_API_SECRET stays referenced to server 1’s backend (the shared secret). Database and Redis host references are unchanged.

​
Frontend2

RCONWEB_EXTERNAL_ADDRESS stays ${{RAILWAY_PUBLIC_DOMAIN}} (a self-reference, so it resolves to Frontend2’s own domain).

​
Step 3: deploy and verify

Deploy the three services. No migration step is needed; the shared database is already prepared, and Backend2 waits for readiness on first boot just like server 1 did. Then check:
  1. Log in at Frontend2’s domain (accounts are shared with server 1, but sessions are per-domain; see the note below).
  2. The live game view populates from game server 2.
  3. The server-switcher dropdown in each UI lists the other server.
  4. The Services page on server 2 responds.

​
Notes

Accounts are shared, sessions are not. If you attach custom subdomains of one apex you control (like rcon1.example.com and rcon2.example.com), set SESSION_COOKIE_DOMAIN=.example.com and CSRF_COOKIE_DOMAIN=.example.com on every backend, and add each custom domain to that backend’s DOMAINS list, to get single sign-on across servers. This cannot work on *.up.railway.app domains. The custom domain guide has the full setup.
Each game server adds a supervisor (the heaviest service, around 15 worker processes), a backend, and a frontend. The shared Postgres is already sized for 10 servers.
Delete its three services (and the supervisor’s volume). Historical data stays in Postgres under that server number; don’t reuse the number afterwards unless you know the history is irrelevant.