AMS Game Servers Now Download and Unpack Builds in About Half the Time

When a dedicated game server starts, it has to do more than run the game process. In our setup, it first downloads and unpacks the server build. That step happens every time a new server comes online, including when more capacity is needed during a spike in player traffic.

We recently found a way to make that step faster in AccelByte Multiplayer Servers (AMS), our service for deploying and scaling dedicated game servers. Across new server launches outside Ohio, median build download and unpack time dropped from 31 seconds to 17 seconds after the change—about a 45% reduction.

Here’s why those downloads were taking longer than they needed to, and how we changed the delivery path.

The Bottleneck: Builds Were Coming from One Region

Until recently, every new AMS game server downloaded its build from storage in Ohio (us-east-2), regardless of where that server was running. A server in Seoul or São Paulo was pulling its build from the other side of the world.

That distance matters when you need to transfer a server build before the game process can start. It was an avoidable part of the time spent bringing a new instance online.

What We Changed

Since early October, we’ve been delivering server builds through a content delivery network (CDN). Instead of always fetching from Ohio, a new server can download its build from an edge location closer to where it runs. The change applies to AMS fleets on AWS, Azure, and Google Cloud. Servers in Ohio still use the direct path because they’re already near the storage.

The build access model hasn’t changed. Each server still receives a short-lived signed link for its own build, and the storage behind the CDN isn’t publicly reachable. Moving delivery closer to the server hasn’t made the builds public.

What We Saw in Production

We compared real AMS production launches from September 30–October 6, 2026 (before the change), with October 15–21 (after the change). The metric here is the median time for a new server to download and unpack its build—not the total time for that server to be ready for players.

Regional median build download and unpack times, in seconds. Source: AMS production server launches, September–October 2026.

Every region shown in the chart got faster. Seoul went from 54.8 seconds to 19.5 seconds (64% less time). Frankfurt went from 35.2 to 18.8 seconds (47% less time), and Sydney from 65.5 to 42.2 seconds (36% less time). The size of the improvement varies by region.

We also checked Ohio, where the delivery route stayed the same. Its median remained roughly level at 13–15 seconds. That gave us a useful reference when comparing the periods before and after the rollout.

Why This Matters for Dedicated Servers

Getting the build onto a new server is only one part of startup. The game process still has to launch and become ready to accept sessions. So a 45% reduction in build download and unpack time does not mean the full server startup time dropped by 45%. It does mean one step is shorter whenever AMS brings another game server online. That’s useful when a fleet has to add capacity, particularly in regions that previously fetched builds over longer distances.

What Other Game Server Teams Can Take from This

Even if you don’t use AMS, build distribution is worth looking at if new dedicated servers take longer than expected to come up. Where are your builds stored relative to the regions running your servers? How much data needs to move each time a new instance launches?

Build size still matters too. Strip debug symbols and leave out client-only assets where you can. Every megabyte you remove is less data to transfer and unpack on each launch. And if you run fleets that scale on demand, keep an eye on ready capacity: improving startup helps, but it doesn’t replace having servers available when players need them.

For teams already using AMS, the CDN delivery change is live. There’s no SDK update, fleet configuration change, or build change required.