Orchestrator
An orchestrator is the system that decides where and when each game server instance runs, starts it, and shuts it down afterwards. It sits between your matchmaker and your infrastructure: the matchmaker says a match is ready, and the orchestrator produces a server for it in the right place.
Also called
game server orchestrator
,
What Is a Container Orchestrator?
A container orchestrator runs containers across a group of machines. You declare what should run, such as five copies of a web service, and it keeps that true: it places each container on a machine with room, restarts any that fail, and adds or removes copies as load changes. Kubernetes is the most widely used.
Inside, an orchestrator usually has an API that takes requests, a scheduler that picks where each container runs, a record of what runs where, health checks, and cleanup. The scheduler is one part of the orchestrator, not the whole of it.
Most container orchestrators treat the copies as interchangeable. Any one of them can be stopped to scale down, move to another machine or roll out an update, because another copy serves the next request just as well. A game server holding a live match isn’t interchangeable: stopping it ends the match for every player on it. A game server orchestrator starts from that difference and manages each server as a match with its own lifecycle.
What Does a Game Server Orchestrator Do That a Container Orchestrator Doesn't?
Compared with a general-purpose container orchestrator, a game server orchestrator typically:
Starts a server per match on request, and makes its address and port available, once it’s ready, to the matchmaker or backend that asked.
Doesn’t stop a server while its match runs to scale down or rebalance. The server ends when its match does, or at a set maximum runtime.
Exposes each server’s ports to players, usually UDP, often mapped to a different port outside the container (port mapping).
Places each server by where its players are, rather than wherever a machine has room.
How it knows each server’s state differs between orchestrators. Some track it through an SDK added to the server build; others manage it from outside, through an API, environment variables and a stop call the server makes when its match is over.
Do Live Matches Depend on the Orchestrator?
Not once they're running. An orchestrator is a control plane: it decides where servers run, starts them and stops them. The game server is the data plane: players connect to it directly, and match traffic doesn't pass through the orchestrator. The orchestrator matters most at the moment a match needs a server.
That makes two things worth checking in any orchestrator: how it keeps placing new servers when a provider or location has a problem, and what the game does while a request is retried. Whatever the orchestrator, a client that holds the player’s place in the queue and retries with backoff turns a slow start into a short wait.
Edgegap’s orchestrator runs as a managed service and places servers across 17+ infrastructure providers (as of 18 September 2026), so a new server can be placed with another provider if one has an outage. Hosting needs no Edgegap SDK in the game server: any container image deploys worldwide from a single API call, the server reads its ports and match details from environment variables, and it can end itself with one HTTP call when the match is over (docs). Match servers start and stop on demand on Edge Cloud, while persistent servers, such as a world that keeps its state between sessions, run on Private Fleets (fleet management).
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.
