The ceiling you're hitting through the public domain is not a per-replica connection cap. Our edge applies a concurrency limit per domain on each edge node, shared across all replicas behind it, and it is checked when a new connection is admitted. Once a WebSocket upgrade completes, the open connection no longer counts against that limit, so established connections can stay open indefinitely, which is why the private network shows no such ceiling.

Load tests run from one region push most of their upgrades through the same edge nodes and reach that limit much sooner than geographically distributed players would. To get a representative result, run generators across multiple regions and source IPs that match where your players actually are. We don't raise this limit solely for synthetic load testing.

Adding replicas is the right way to scale the game server itself. Pro allows up to 42 replicas per service, but more replicas do not multiply the edge's per-domain limit.

The 10,000 requests per connection limit does not apply to WebSocket messages. Messages on an upgraded WebSocket connection are not counted as requests.

Thanks for the explanation.

For context: our game will launch on Steam, and we expect at least 100,000 concurrent players. That's why we're validating connection capacity now.

Following your suggestion, we reran the test with generators spread across four regions (us-west, us-east, eu-west, southeast-asia), one replica each, all connecting to the public domain. We got the same result as the single-region test.

• With 2 world replicas, connections stopped at 5,953 and 6,042 per replica (about 12,000 total), and every new upgrade after that failed with 502 Bad Gateway.
• The ceiling was the same as the single-region test, and it doubled exactly when we went from 1 replica (about 6,000) to 2.
• Upgrades were arriving at only about 20 per second, and established connections stayed stable.

So in practice this looks like a limit of about 6,000 concurrent connections per replica.

Could you check what is actually limiting it on your side, and whether real player traffic would hit the same limit?

With 100,000+ concurrent players, we'd like to know the right setup (replica count, domains, or a raised limit) before launch.

Thanks!

We checked our documentation and it does not cover this yet, so the Railway community is the best place to get a real answer: people who have already worked this out on their own projects and can tell you what actually worked.

So we'd like to open your thread as a community bounty. Railway pays a bounty to the community member who answers it, and threads like this usually get picked up quickly.

Opening it makes this entire thread public, including everything already posted. Nothing becomes public until you decide. Use the buttons below.

• Open to the community - Before you click, take a moment to edit or remove anything you'd rather not share. The thread becomes publicly visible right away.
• Keep it private and close the thread - Nothing becomes public and the thread closes.

Did you try using the TCP proxy feature of railway?

One useful test: once you hit ~6k, close 100 sockets and try opening 100 more. If those succeed and it stops again, that points to a concurrent connection/resource ceiling rather than an upgrade-rate limit.

Also try opening more private-network connections to that same replica while public upgrades are failing. If those still work, that gives Railway a much clearer repro pointing at the public path.

TCP proxy is worth testing too, but watch out: for wss:// you’ll need to handle TLS yourself.

Just thought of the most psychotic way to solve this: deploy many proxy services to accept the connections and funnel them to your service over private networking, obviously dont do this. But as a last resort...