On 7 October 2026, a game studio under NDA ran a load test on Edgegap ahead of its mobile free-to-play launch. The goal was to confirm that the client’s launch architecture, Edgegap included, could handle a deployment rate higher than the 40 per second we limit every client to.

This is a behind-the-scenes look at how we set that test up with the studio, what it reached, and what it meant for everyone else on the platform at the same time.

Testing the Whole Launch Architecture, Together

The studio wanted to see its entire stack under launch-day pressure before going live: matchmaking, game server deployments and its own backend, all at once. We worked with their team hand in hand to plan the test, prepare capacity and run it.

Every server in the test ran the studio's own game server build, the same binary they ship to players. Each instance was sized as it will be in production: a quarter of a vCPU (0.25 vCPU) and 512 MB of memory, typical for a lightweight mobile session.

The players were simulated, since a pre-launch test happens before real players exist. Those simulated players were matched through Edgegap's enterprise matchmaker, and every match triggered a real game server deployment through the same production API every Edgegap customer uses.

The same approach is available to any studio with a large launch ahead. The rest of this article covers how we ran it, so you know what to expect if you plan one with us.

How the Test Was Run

The test ran for 84 minutes and was split into four phases, each one raising the request rate:

• Smoke test: a few deployments per second, to confirm the build, configuration and connectivity.

• Ramp: a gradual climb to 20 deployments per second, then held there for about 16 minutes.

• Burst at our client-wide limit: 40 per second, held at an average of 41.6 per second for 11 minutes.

• Final burst: the highest-rate phase, averaging 61.3 per second and peaking at 70.2 over ten seconds, run for five and a half minutes.

Capacity was provisioned for the studio ahead of the test, as it would be for any planned launch. The platform still added hosts automatically during the run as demand climbed.

Requests went through the shared production control plane, the same API and scheduler that handle every other customer's deployments.

Peaking at 70 Deployments per Second

The final phase is where the numbers climbed to imitate the crest of a launch-day wave of players.

The busiest single minute saw 4,116 game server deployments requested, an average of 68.6 per second. The busiest ten-second window averaged 70.2 per second, and the single busiest second reached 85 deployments. Across the full five-and-a-half-minute phase, the average was 61.3 deployments per second.

For this studio, whose game expects an average of six players per match, that one-second peak would mean approximately 510 new players joining a match in a single second.

Those rates are well above the 40 per second we limit clients to. In total, 94,995 game server deployments were requested across the test.

The rate was capped on purpose. At the studio’s request, we kept its quota below its own load test target, to see how its launch architecture behaves in a breaking scenario. The quota started at our default of 40 per second and was raised during the test, through a support request, with no development work or special operation.

Requests above the quota were rejected, and Edgegap’s enterprise matchmaker automatically retried each failed deployment up to three times. Tickets that ran past the retry limit were cancelled, which is intended: it keeps a wave of retries from overwhelming the service, and in production those players simply queue again. Once the quota was raised, the matchmaker recovered on its own, without human intervention. Nothing broke. The cap was a limit set for this test, not a breaking point of the platform.

No Measurable Impact on the Rest of the Platform

A load test on shared infrastructure only proves something if everyone else is unaffected. So the question we cared about most was simple: did any other studio notice?

The data says no. Other customers deployed 11,924 game servers during the test window. Their error rate was 0.017%, against 0.033% the day before. Their deployment behavior was unchanged from a normal day.

The test itself was reliable too. Of the 94,995 deployments requested, 94,944 deployed without error, a 99.946% success rate. The 51 that failed returned a standard deployment error.

That is the point of running a test like this on the live platform. A launch doesn't happen on an idle platform, and neither did this test.

Running a Load Test for Your Own Launch

We limit every client to 40 deployment requests per second per organization. For context, Edgegap's own load-testing guide estimates that Fortnite, one of the world's most popular games, averages 30 to 40 deployments per second at its daily peaks.

Some launches still need more. A large free-to-play release, a platform feature, or a streamer-driven spike can push matchmaking far past normal levels within minutes. In those cases, higher rates are planned with the studio ahead of time, along with the capacity to support them.

This test is not a new baseline, and the client-wide limit is not changing. It shows what we can deliver together when a studio needs it and plans for it.

A studio preparing a launch of that size can start with three things:

1. Model launch traffic: Estimate peak matchmaking requests per second from expected concurrent players, match size and session length.

2. Test with your real build: A placeholder server tells you little about how your own game behaves under load.

3. Plan the rate with Edgegap: If your model lands above 40 deployments per second, contact the team to schedule the test and prepare capacity.

Need to prepare for a load test and not sure where to start? Read our deep dive on how to run a load test for any online multiplayer game. For the rest of the timeline, see the multiplayer game pre-launch checklist.

To plan a load test, be it below or above 40 deployments per second, or if you need even more than 70 deployments per second, contact Edgegap first, as every load test on our platform is scheduled with our team.

—

This article is based on Edgegap production data from a client load test run on 7 October 2026. The client is not named, as the test was run under NDA.