Deployment
A deployment is a single running instance of a game server build, created to host a match and destroyed when that match ends. It has an address, a lifespan measured in minutes, and a defined capacity. Counting deployments rather than machines is how session-based hosting is measured and billed.
Also called
game server deployment, server deployment
,
What Does a Game Server Deployment Contain?
A deployment is where a build meets a match. Whatever starts it, whether a matchmaker, a server browser or a game's own backend, the result carries the same few things, and each one is something the backend, the server and the players' clients have to agree on:
A build version. The exact image that runs, so every player in the match connects to the same version of the game.
A size. How much CPU and memory it gets, often a fraction of a vCPU for a light server.
A location. Where it runs, ideally close to the match's players.
An address and ports. A public address and the ports players connect to. The external port often differs from the one the server listens on inside its container, a common cause of failed first connections (port mapping).
Match data. What the server needs to know at start, such as which players are coming, the mode and the map, usually passed in as environment variables.
Tags. Labels for finding the deployment later in logs, dashboards and support tickets.
When one of these is wrong, the symptom usually shows up somewhere else: a player who can't connect, a server running the old build, or a crash nobody can trace.
How Does a Deployment Start and End?
Starting is usually automatic. A matchmaker or server browser requests a deployment once players need a server, the infrastructure picks where it runs, and the container starts. The time that takes is the cold start, and binding a group of players to a specific server is server allocation.
Ending takes more thought. A deployment typically stops in one of five ways:
The server stops itself when the match ends, by calling a stop endpoint.
The game's backend stops it, for example once every player has left.
A maximum duration runs out.
The server crashes and, depending on its restart policy, is restarted or left stopped.
The machine underneath is taken out of service.
The first is often the most reliable, because the server knows when its match is over. The last two are why match results and logs are better sent out as they happen than saved for the end, as the containers page describes.
A deployment nobody stops keeps running and, on usage-based billing, keeps costing. A maximum duration is a useful backstop, as long as it's longer than the longest match.
Session or persistent. Most deployments last a single match. A persistent world, a social hub or an MMO shard keeps one running for days. Cloud platforms often cap runtime, so long-lived servers usually run on reserved hosts, with state saved outside the container, and are replaced on a schedule rather than kept forever.
How Do Game Servers Update Without Downtime?
"Deployment" has a second meaning: rolling out a new build. It's where searches for blue-green and zero-downtime deployment land.
For match-based games, per-match deployments make this close to built in. Once a new build is published, new matches start on it while running matches finish on the old one. No server is updated in place, so no match is interrupted. Two conditions make it work: the old and new builds can run side by side for as long as the longest match, and players still on the old client are kept on old-version servers or asked to update. Server allocation covers what goes wrong on patch day.
Blue-green applies the same idea to a whole environment: the new version runs beside the old, traffic moves across, and the old one stays ready for a rollback. Persistent servers are the harder case. They need draining, with players moved to a new deployment, or a restart during the quietest hours.
On Edgegap, a server-only fix follows the per-match pattern: a new app version points to the new image, and once it's live, new matches use it while running matches finish on the old one (matchmaker documentation). Our guide to automated rolling updates covers the wider pipeline. Unique image tags, which turn a rollback into a pointer change, are covered under containers.
Why Is Game Server Hosting Measured in Deployments?
On usage-based hosting, the bill follows deployments, not machines. Each one is billed for its size while it runs, the model behind a serverless game server. Two things drive the cost: how big each deployment is, and how long it lives. Right-sizing a build, with a fraction of a vCPU where the game allows it or several matches in one multi-room server, and stopping deployments on time often matter more than the hourly rate. Current rates and a calculator are on our pricing page.
Counting deployments also measures scale and speed. Edgegap has run 135 million game server deployments since February 2019, a count that includes deployments that failed to start. Its median deployment time is 2 seconds, from cold start to container ready over a rolling 30 days, and it sustained 40 deployments per second in a November 2023 benchmark (platform data, 18 September 2026). A deployment that fails to start isn't charged (deployments documentation).
A word from our sponsor (ourselves!)
Warm pools make allocation fast because you pay for servers that sit idle. Edgegap provisions a fresh game server in a median of 2 seconds from cold start, measured to container ready before your engine starts, so a server exists only once a match needs one.
Edgegap's Take (just our opinion, take it with a grain of salt!)
Make Every Deployment Stop Itself
A large share of avoidable hosting cost often comes from deployments that outlived their match: a server that never learned the last player left, a test deployment left running over the weekend, a broken build restarting in a loop. Per-minute billing is only cost-effective if every deployment ends when its work does.
Build the stop into the server, not only the backend: when the match ends, the server ends itself. Then check it. Each week, list the deployments that ran longer than your longest possible match. Each one is either a persistent server you meant to keep or a leak to fix.
On Edgegap, every deployment receives its own stop URL and token when it starts, each app version can set a maximum duration as a backstop, and tags make test deployments easy to find and clean up.
,
