*.up.railway.app domain. Pointing your own domain (say
rcon.example.com) at it takes one change in Railway and two variable
edits so Django trusts the new hostname.
Step 1: add the domain in Railway
1
Add a custom domain to the frontend
In your Railway project, open the frontend service, go to
Settings, Networking, and click Custom Domain. Enter your
domain (for example
rcon.example.com) and pick target port
80.2
Create the DNS record
Railway shows you a CNAME target. At your DNS provider, create a
CNAME record pointing your domain at that target. TLS is automatic;
Railway issues a certificate once it sees the DNS record, usually
within minutes.
Using Cloudflare? Both proxied (orange cloud) and DNS-only
records work, but with the proxy enabled set Cloudflare’s
SSL/TLS mode to Full for the domain, or you’ll get redirect
loops.
Step 2: tell CRCON about the domain
Django rejects requests for hostnames it doesn’t know, so the login will 400 until the backend trusts the new domain. On the backend service’s variables:
Then on the frontend service, set
RCONWEB_EXTERNAL_ADDRESS to the
same domain (it defaults to a reference to the generated Railway
domain).
Redeploy the backend, frontend, and supervisor (the supervisor
references the backend’s value and picks it up on redeploy). Log in at
your new domain.
Public scoreboard on its own domain
The public stats site is just port 81 on the same frontend. Repeat step 1 with a second custom domain (saystats.example.com) targeting
port 81. Nothing else needs changing; the scoreboard doesn’t do logins.
Single sign-on across multiple servers
Running several game servers, each with its own frontend? Give them subdomains of one apex (rcon1.example.com,
rcon2.example.com), then set on every backend:
Add each subdomain to its own backend’s
DOMAINS, and one login works
across all of them. This is impossible on *.up.railway.app domains,
which is the main reason to bother with custom domains at all.