Global Edge Cloud locations
Distinct deployment targets where a game server container can be scheduled on demand.

Keep the architecture you built, skip managing the game server orchestration to get back to focusing on game development.
Deploy worldwide with a simple API call, get an address and port back, and your container binary never changes. What goes is the platform underneath it: the clusters, the node pools, the controller and allocator, the fleet autoscalers, the image distribution path and the upgrade cycle that follows three Kubernetes releases forever.
Edgegap’s hybrid orchestration combines bare metal Private Fleets, capacity you still fully control, with our Edge Cloud network of 615+ on-demand locations to keep your hosting cost-effective. Each Edge Cloud deployment goes to the best available location at request time, measured from the player.
What changes (and doesn't change)
An Agones migration is a hosting change, not a rewrite, and the architecture you built stays recognisable. Here's what to expect from your migration.
A full feature-by-feature breakdown is in Step 3: Identify & Replace features below.
What Remains the Same
Your netcode and transport
Edgegap never touches your transport, serialization or tick loop. The container runs the same server binary you build today.
Containerize
You already ship a container image, so the artifact is unchanged. Push the same image to our registry, or keep the one you use today.
Your client connect flow
Your client still receives an address and a port and connects to it. Only where that address comes from changes.
Your allocation model
The shape of the thing you built stays: your backend asks for a server and gets connection details back. You are replacing one request with another, not redesigning how sessions are handed out.
What Changes
The Agones SDK comes out
Ready(), Health(), Allocate(), Reserve() and Shutdown() leave your binary, and the SDK sidecar leaves the pod spec with them. Edgegap needs no server SDK. Your server reads its public IP and port mapping from environment variables at deployment and is ready as soon as it listens.
One deploy call replaces GameServerAllocation
Instead of creating a GameServerAllocation and reading state, address and port off the result, your backend posts once to the deploy endpoint, then receives the FQDN and port through a deployment webhook or by polling the deployment status. No label selectors, no allocator topology.
The cluster stops being yours to run
No controller and allocator to operate, no node pools to provision and bin-pack, no image distribution path to build, no fleet dashboards to watch at 3am, and no decision about which regions to stand a cluster up in and pay for. One call reaches every location, and you pay for the deployment rather than the cluster sitting behind it. The pager for the thing that starts your matches moves to us.
The upgrade treadmill ends
Agones supports three Kubernetes releases at a time, so cluster and orchestrator upgrades arrive on someone else's cadence, in every region, forever. That schedule is no longer your problem, and neither is testing it.
Expected Timeline
Step 1
Remove the Agones SDK calls and the sidecar from your pod spec. Nothing proprietary replaces them.
~2 hours
Step 2
Your server already runs as a container, so this step is a check rather than work.
Already done
Step 3
Edgegap's registry is available for free, or keep the registry you already run.
~30 min.
Step 4
One deploy request, plus a webhook or status check for the address, replaces the GameServerAllocation your backend creates today.
~1 day
Step 5
Deploy globally on Edge Cloud, and optionally cut cost further with egress-free hosting on Private Fleets.
Instant Rollout
Detailed migration steps
If you are running Agones on your own clusters and want the same orchestration without operating it, the following simple steps will get you running in no time. Our engineers are available if you want to walk through your setup first.
Before getting started, it helps to be clear on what integrates with what. Edgegap is an API: your backend posts a deploy request and receives the address and port once the deployment is ready, by webhook or by polling its status, and nothing is added to your game server binary. There is no server SDK and no sidecar. We expect that: you currently run Agones on your own Kubernetes clusters, you have a working game server container, and you can change the allocation call in your backend.
Step 1:
Edgegap does not require a server SDK to integrate. The first step is to remove the Agones SDK from your game server: the connection to the SDK server, the Ready() call after start-up, the Health() ping loop, and the Allocate(), Reserve() and Shutdown() calls that move the GameServer through its states. Anything reading back through GameServer() or WatchGameServer(), and any SetLabel() or SetAnnotation() calls used to carry match metadata, comes out too. The SDK sidecar leaves the pod spec with them, along with AGONES_SDK_GRPC_PORT and AGONES_SDK_HTTP_PORT. On Edgegap your server reads what it needs from environment variables injected at deployment, including its public IP and port mapping, and it is ready for players as soon as it is listening. Match metadata that used to travel as labels travels as environment variables on the deploy request.
Step 2:
Your game server already runs as a container, so this step is a check rather than a rebuild. Confirm the image builds and starts without the SDK sidecar, then push it to Edgegap's free registry or keep the registry you run today. If you built an image distribution path to speed up pulls, and many teams running Agones at scale have, none of it comes with you: image pull and placement are ours to solve.
Step 3:
Agones - Features | Edgegap - Features |
|---|---|
Agones SDK and sidecar | |
GameServerAllocation | One POST to the deploy endpoint. FQDN and port arrive through a deployment webhook or by polling deployment status. |
Fleet and GameServerSet | Apps and Versions for the image, Private Fleets for persistent capacity. |
replicas and buffer sizing | Nothing to size on Edge Cloud (on-demand). Private Fleets rightsized monthly. |
FleetAutoscaler | Automatic. Overflow onto Edge Cloud when a Private Fleet is full. |
RollingUpdate, maxSurge and maxUnavailable | Version rollout on Apps and Versions, with rolling updates automatically handled for you. |
Packed or Distributed scheduling | Placement at request time, measured from the player. |
Multi-cluster allocation | One endpoint. No allocator topology to maintain. |
Node provisioning, bin-packing and cluster autoscaling | Handled by Edgegap. No nodes to provision, size or bin-pack, and capacity scales per deployment without a cluster autoscaler to tune. |
Image registry and distribution path | |
Kubernetes and Agones version upgrades | Fully-managed platform on your behalf |
Monitoring, logging and alerting for the platform, security | Deployment Status API, Deployment Webhook, Deployment Analytics and Monitoring, 24/7 support, DDoS protection. |
Porting work | Optional: connect your coding agent to the Edgegap MCP server. It loads Edgegap’s tested agent skills and uses your existing image to create the App and Version and deploy your server, and every change can be previewed as a dry run first. There is no Agones-specific skill yet: the Deploy API skill writes the allocation call, and the launch skill covers capacity planning with Private Fleets. |
Step 4:
Private Fleets are the closest thing to the Fleet you run today: persistent, dedicated capacity with egress-free hosting. The difference is everything around it. There are no replicas to tune, no autoscaler policy to write, no nodes to provision or bin-pack, and no cluster to upgrade. You rightsize the Private Fleet monthly, and anything past it bursts onto Edge Cloud automatically.
Pricing
Discover how Edgegap's orchestration compares to the cost of running your own.
Agones handles GameServer pods, Fleets and the FleetAutoscaler. Everything else a platform needs, a self-hosting team supplies. This table is the task list, not a price list: your engineering cost is yours to model.
Platform job | Self-hosted Agones | Edgegap |
|---|---|---|
Node provisioning, sizing and bin-packing | Yours | Handled by Edgegap. No nodes to provision, size or bin-pack |
Image registry and distribution path | Yours to build and operate | |
Capacity buffering and autoscaler policy | Yours to tune, per fleet, per cluster | Multiple strategies to leverage on Edge Cloud, automated on Private Fleets |
Kubernetes and Agones upgrades | Yours, on a three-release support window, in every region | Fully-managed platform on your behalf |
Platform monitoring, alerting and the pager | Yours | In-depth analytics and monitoring tool, with 24/7 support included |
Multi-cluster allocation topology | Yours |
What this table does not cover: the cost of operations. We ran Deconstructor of Fun’s third-party total-cost-of-ownership calculator against a modest Agones adoption, and it lands at roughly $42K to integrate and $567K over three years to develop and maintain, with maintenance benchmarked at 15 to 25 percent of build cost annually. The largest single line is opportunity cost from that model. Read the full breakdown and its caveats.
The recurring job of an orchestrator is not deployment, it is fill rate. On self-hosted Agones, you pay for every node for as long as it runs, not for the players on it.
Self-hosted Agones | Edgegap | |
|---|---|---|
Scaling up | In whole nodes. Crossing a threshold pays for a full machine to carry the overflow | Per deployment, fractionable from 0.25 vCPU |
Scaling down | Waits for stateful sessions to drain before a node can go | Ends with the match |
Warm buffer | Sized to cover provisioning time, and idle by design | Not required on Edge Cloud. Deployments are provisioned from scratch in 2 seconds, median, to container ready |
Provisioning time | Set by node provisioning and image pull, which is why teams running at scale extend Agones with their own node provisioning and image distribution before the numbers get good | 2 seconds, median, from cold start, with nothing to extend |
Billing | Per node, for as long as the node runs, whether its game servers are full or empty | Per deployment, by the minute on Edge Cloud, and billing stops when the match ends. Private Fleets bill by the hour |
Self-hosted Agones | Edgegap | |
|---|---|---|
Compute | Your cloud or bare metal contracts, at your negotiated rates | $0.00115 per vCPU per minute on Edge Cloud, single price worldwide, or $0.0261 per vCPU per hour on Private Fleets |
Coverage | The regions you stood clusters up in | 615+ Edge Cloud locations on-demand, with each deployment at the best available location at request time, measured from the player |
Egress | Per your provider agreements | Included on Private Fleets |
Net effect at thousands of CCU | Cost is compute plus the platform team | 25 to 35 percent below pure cloud with a properly optimized hybrid split. Model it in the pricing calculator |
Edgegap | Google Cloud | |
|---|---|---|
Orchestration | Hybrid orchestration, no game server SDK required: | No managed game server service: Google's Game Servers URL now serves the Cloud for Game Development page, and its client library notes "The Cloud Gaming API is officially deprecated."; Google points studios to "Run and scale dedicated game servers on GKE" with open-source Agones, installed and operated by the studio |
Infrastructure |
| Single provider: 43 Google Cloud regions and 130 zones (locations page, updated October 28, 2026); studios create a regional or zonal GKE cluster in each location they serve |
Hardware |
| GKE nodes are "Compute Engine virtual machine" instances; machine types chosen by the studio on GKE Standard, or managed by Google on Autopilot, where Agones has "pre-configured opinionated constraints" (no Windows containers, minimum Pod resource requests) |
Placement |
| Studio chooses the cluster's region or zone; Agones installs a ping service so clients can "determine which cluster to connect to based on latency"; for multi-cluster allocation, Agones now recommends "a Service Mesh in each of your Agones clusters" |
Pricing | $0.10 per cluster per hour management fee, with a $74.40 monthly credit per billing account; Autopilot $0.0445 per vCPU-hour plus memory (us-central1, on-demand); Standard nodes billed at Compute Engine prices; internet egress $0.12 per GiB up to 1 TiB (Premium Tier, Iowa to North America) | |
Scalability |
| Up to 65,000 nodes per GKE Standard cluster and 5,000 per Autopilot cluster; "Not all node quota increases are automatic"; no game server load-test or deployment-rate figure published (as of Q4 2026) |
Integration |
| Agones client SDK required: "The client SDKs are required for a game server to work with Agones", for Unreal Engine, Unity, C++, C#, Node.js, Go, Rust, Python and REST; matchmaking through open-source Open Match, named in Google's games FAQ |
Support | "Support for Game Servers is offered under the Premium support package" (minimum $15,000 per month, $180,000 per year by Edgegap calculation); Agones issues go to GitHub and community channels | |
Latency | 58% average reduction vs. public cloud (Edgegap case study) | No latency measurements published for game servers on GKE (as of Q4 2026); clients can time Agones' HTTP and UDP ping service |
Track Records | Agones co-developed by Google and Ubisoft since 2017, donated by Google to the CNCF (March 2026); DeNA named as running its dedicated game servers on GKE (Google Cloud blog, March 2023) |

Clients
15 case studies are available from studios that moved to Edgegap from another platform.

Migrating a LiveOps Multiplayer to Edgegap to Solve DevOps Workload
Discover why #1 VR extraction shooter is powered by Edgegap's game server hosting & orchestration.
Case Study

Persistent Servers that Scale Instantly & Improve End Users Experience
Discover how The Isle improved its players’ experience with Edgegap’s global deployments of persistent servers.
Case Study

A Cozy MMO Migrated in Days with Edgegap's Game Server Orchestration
How Qloud Games migrated Loftia's game server hosting to Edgegap in under 24 hours and ran a flawless closed beta with thousands of concurrent players
Case Study

VR Warfare at Scale: Triangle Factory Launches Forefront 1.0 on Edgegap
How Triangle Factory migrated their most ambitious VR shooter to Edgegap and launched their full 1.0 with confidence.
Case Study

From Peer-to-Peer to Fair Fights: Bloody Bastards on Dedicated Servers
How Tibith Ltd migrated Bloody Bastards, a 40M download mobile hit, from P2P to Edgegap's dedicated servers & matchmaking, ensuring every match is server-authoritative.
Case Study

How Noodlecake Delivers Multiplayer and Forgets the Servers Exist
How Noodlecake moved Super Flappy Golf to Edgegap's automated orchestration and got back to building the game.
Case Study

Competitive VR needs Infrastructure to Match: Breachers Migrates to Edgegap
How Triangle Factory brought their competitive 5v5 VR shooter to infrastructure built for the precision the genre demands.
Case Study

Using Edgegap’s Fleets for a fully automated server management flow
Learn how Blue Duck Studios uses Edgegap's Fleets API to orchestrate its soccer game's servers.
Case Study

1047 Games on Edgegap: A Smooth Migration and Launch
How 1047 Games moved Splitgate: Arena Reloaded onto Edgegap and launched Empulse on its orchestration, with hosting that stayed reliable throughout.
Case Study

From homebrew orchestration to 50k players overnight
How Slipstream Games cut server costs by 50%, reduced its ping from 200-250ms to 100-110ms & launched on CrazyGames reaching 50k players in 24 hours.
Case Study

From Fleet to On-Demand: Dedicated Servers for an Indie Scooter Game
How iScoot migrated from fleet-based hosting to on-demand instance-based orchestration, resulting in 10x smaller dedicated servers and a cost model built for an indie game.
Case Study

On Demand, On Budget: Triangle Factory Brings Hyper Dash to Edgegap
How a free-to-play VR shooter stays fast, global, and cost-efficient with on-demand infrastructure that scales with its players.
Case Study
Discover the impact of Edgegap's automated game server orchestration for a flawless multiplayer experience.
Edgegap is the hosting & orchestration experts. Our platform is tailor built to help you speed up your development process, which allows you focus on what you excel at - development.
It does not, and the reason is the artifact. What you push is a standard container image with nothing of ours inside it: no server SDK, no sidecar, no lifecycle calls in your binary. The same image runs anywhere that takes a container, whether that is your own cluster if you stand it back up or another provider entirely, and the only integration you would unwind is one HTTP call in your backend. The flexibility you kept Agones for stays with you on the orchestration side too. Reserve compute that is yours alone with Private Fleets, in the locations you choose, or run on multi-tenant Edge Cloud with reserved vCPU and memory and pay for the deployments you actually use, or split the two and move the line whenever your traffic moves. You decide where servers run and how they scale. What you hand over is the operating of it, not the control of it.
Private Fleets, for capacity that stays yours: dedicated bare metal with egress-free hosting, rightsized monthly rather than tuned with replicas and autoscaler policies. Hybrid orchestration combines them with Edge Cloud to keep hosting cost-effective, with nothing to configure: when a Private Fleet is full, deployments overflow onto Edge Cloud, each created for the match that needs it, provisioned from scratch in 2 seconds, median, measured to container ready, before the game engine starts. The buffer you keep today to cover provisioning time is not needed, which is also where a large part of the saving lives.
They come out and nothing proprietary replaces them. Ready(), Health(), Allocate(), Reserve() and Shutdown() all go, along with the SDK sidecar in the pod spec and the GRPC and HTTP port variables it used. On Edgegap your server reads its public IP and port mapping from environment variables at deployment and is ready as soon as it listens. Match metadata you carried as labels or annotations travels as environment variables on the deploy request instead.
It collapses into one endpoint. Today you keep clusters in each region, an allocator in front of them, and policy deciding which cluster serves a request. On Edgegap you send one deploy request with the players' locations and it is placed at the best available location on the network at request time. There is no topology to maintain, no cross-cluster policy to keep in sync, and no per-region capacity to provision ahead of demand. If you want capacity in specific places, that is what Private Fleets are for: bare metal in the locations you choose, with automatic overflow to Edge Cloud rather than to another cluster you own.
On compute alone we are in a strong position, and you can check it against your own rates rather than take our word for it. Edge Cloud is $0.00115 per vCPU per minute, fractionable from 0.25 vCPU, at a single price worldwide, and Private Fleets are $0.0261 per vCPU per hour with egress-free hosting. If your cloud pricing is close to list, the gap is usually large. If you have negotiated well, volume pricing narrows it and then keeps going as you grow. Harder to put in a spreadsheet, and usually worth more: hybrid orchestration keeps hosting cost-effective by combining bare metal Private Fleets with Edge Cloud, and you rebalance the two whenever your traffic moves, instead of buying for peak all year. Then there is what you stop maintaining. Your integration is already built, so that cost is behind you, but the upkeep is not. An industry benchmark puts ongoing maintenance at 15 to 25 percent of build cost annually, before the evolution work that arrives with every new region, platform and engine version. Autoscaling, analytics and monitoring come with the platform, so tuning cost and performance happens in a dashboard rather than in your sprint. Model your own traffic in the pricing calculator.
Yes, and more of it than you might expect. You keep your game server image and your netcode untouched. You keep your backend and the allocation model you designed: one request in, an address and port back. And you keep capacity that is yours, in the locations you choose, through Private Fleets, which is the part of self-hosting most worth keeping: predictable, dedicated, egress-free. What you add is an orchestrator you do not have to build or maintain, already deploying game servers every day for 1,600+ studios, improved on our payroll rather than yours. Teams usually start by pointing one region at Edgegap and running it beside the cluster they already have for a week, then move the rest once it is uneventful. Nothing requires a hard cutover.
Methodology
Each metric states what is measured, over what window, and what is excluded. Benchmark results are dated to the test that produced them and are not restated as current figures.
Where servers can run, and how many we have run.
Distinct deployment targets where a game server container can be scheduled on demand.
Locations where a studio can reserve Private Fleet hosts for its exclusive use.
Total game server deployments orchestrated since February 2019, including deployments that failed to start, the same basis our competitors use.
How fast our orchestration delivers a server, and what it sustains under test.
From cold start: provisioned from scratch, not allocated onto an already-running server. Measured to container ready, before the game engine starts.
Started deployments per second, averaged over a continuous 60-minute benchmark. The standard rate for each game from confirmed studios with live traffic; higher rates are available on request.
Concurrent sessions reached on real game server containers, at 100 players per server.
What we commit to contractually for our orchestration, and what the monitors record.
Committed under our SLA. Trailing 90-day measured uptime: 99.999%.
Cloud and bare-metal providers under contract and carrying production traffic. Failover is automatic.
Live component status is published at status.edgegap.com.
One entry per metric: what is measured, how, and over what window.
A location is a distinct deployment target: one datacenter site at one of our infrastructure providers, in which a game server container can be scheduled on demand. Sites are counted once each regardless of how many providers operate in the same metro, and count only while accepting deployments.
Back to the metric ↑Counted separately from the 615+ Edge Cloud locations, which are on-demand cloud capacity: a Private Fleet location is a site where a studio reserves hosts for its exclusive use. Published live on the Fleet Manager page. Each Private Fleet host includes 6 TB of egress per month.
Back to the metric ↑Counted as total deployment records since February 2019, including deployments that failed to start, the same basis our competitors use.
Back to the metric ↑From cold start: provisioned from scratch, not allocated onto an already-running server. Measured to container ready, before the game engine starts.
Back to the metric ↑The orchestrator started real game server containers continuously for 60 minutes, averaging 40 started deployments per second over the full hour, counted at deployment start rather than at ready state. Measured across 550+ locations and 17 providers in November 2023. The benchmark ran for a single game. Capacity is allocated per game, so every game on the platform can scale to this level independently and at the same time. 40 per second is the standard rate. Studios that need more can plan a higher rate with us: in an October 2026 client load test, deployments peaked at 70 per second, with 85 in a single second, through the same production API and scheduler every customer uses, with no measurable impact on other customers. How we ran the test.
Back to the metric ↑In November 2023, the platform sustained 40 game server deployments per second for 60 minutes across 550+ locations and 17 providers, reaching 14 million concurrent sessions at 100 players per server. Game servers were real containers; player clients were simulated. The benchmark ran for a single game. Capacity is allocated per game, so every game on the platform can scale to this level independently and at the same time.
Back to the metric ↑Availability is committed at 99.99% under our SLA and measured continuously against five independently monitored components: Container Registry, Dashboard, Public API, Public Documentation and Website. Trailing 90-day measured uptime: 99.999%. The live figure is published on status.edgegap.com.
Back to the metric ↑Distinct suppliers under contract and carrying production traffic, counted at corporate-entity level. Failover across providers is automatic; it is the premise of the multi-cloud architecture.
Back to the metric ↑What gets reviewed, on what cadence, and what carries its own date.
Platform figures on this page are reviewed and refreshed quarterly. Metrics drawn from live sources (availability and game server deployments) carry their own as-of dates and are updated as measured. Benchmark results are dated to the test that produced them and are not restated as current figures.