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

Keep PlayFab. Your matchmaker, economy, auth and Player Data stay exactly where they are: only the servers move, and with them the Azure VM bill you pay for standby capacity that sits waiting between peaks.
Remove the GSDK, containerize the build you already have, and let a PlayFab Azure Function deploy on Edgegap the moment a match is found. Edgegap’s hybrid orchestration combines bare metal Private Fleets with our Edge Cloud network of 615+ locations to keep your hosting cost-effective. Each Edge Cloud deployment goes to the best available location at request time, measured from the players in the match.
What changes (and doesn't change)
A PlayFab Multiplayer Servers migration is a hosting change, not a backend change. 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.
Your PlayFab backend
Matchmaking queues and rules, Player Data, economy, auth, leaderboards and CloudScript all stay in PlayFab. This migration touches Multiplayer Servers and nothing else in your title.
Your client connect flow
Your client still receives an address and a port and connects to it. In the documented bridge it still reads them from PlayFab Player Data, exactly as it does today.
Engine, versions & CI
Same engine, same version, same build pipeline. Nothing in your CI needs a new step beyond pushing the image.
What Changes
The GSDK comes out
The PlayFab Game Server SDK leaves your binary: the agent start-up, the ready and session callbacks, and the health and state reporting it runs on a loop. Edgegap needs no server SDK. Your server reads its public IP and ports from environment variables at deployment.
One deploy call replaces the standby pool
Instead of requesting a server from capacity you provisioned in advance, a PlayFab Azure Function posts once to the deploy endpoint when a match is found, and the deployment is created for that match.
Regions stop being a purchase decision
You no longer size VM capacity region by region. Each deployment is placed at the best available location on the Edge Cloud network at request time, measured from the players in the match.
The standby math goes away
No standby target to calculate, no percentage thresholds and multipliers to tune per region, no ramp-down window, and no pool to keep warm between peaks. Capacity stops being your job: Private Fleets get resized with us as your traffic curve moves, and Edge Cloud has nothing to pre-provision at all.
Expected Timeline
Step 1
Remove the PlayFab Game Server SDK: agent start-up, the ready and session callbacks, and the health and state reporting loop.
~2 hours
Step 2
If you already ship a Linux container build, the artifact is unchanged. Windows-only builds need a Linux server build first, which is the one genuinely large task on this migration.
~30 min. to 2hrs.
Step 3
Edgegap's registry is available for free, or keep ACR, DockerHub, GitLab, etc.
~30 min.
Step 4
A match_found rule runs an Azure Function that deploys on Edgegap, and each player gets the address in read-only data once the server is ready.
~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 looking to move your game servers off PlayFab Multiplayer Servers while keeping the rest of PlayFab, the following simple steps will get you running in no time. Full instructions, including a working Unity sample: PlayFab Matchmaking with Edgegap sample.
Before getting started, it helps to be clear on what moves and what does not.
Only Multiplayer Servers moves: PlayFab keeps your matchmaker, Player Data, economy and auth, and Edgegap becomes the place the matched server runs. Edgegap is an API, with no server SDK.
We expect that: you currently use PlayFab Multiplayer Servers, you have a working game server build, you can add automation rules in your title, and you have an Azure subscription for the two Azure Functions.
Step 1:
Edgegap does not require a server SDK to integrate. The first step is to remove the code that initializes the PlayFab Game Server SDK in your game server: the agent start-up call, the callbacks you registered for server activation and session assignment, the shutdown and maintenance handlers, and the health and player-state reporting the agent expects on a loop. Nothing replaces them. On Edgegap your server reads what it needs from environment variables injected at deployment, including its public IP and its port mapping, and it is ready for players as soon as it is listening. If you used the GSDK wrapper rather than a direct integration, that comes out too, and PlayFab's own documentation notes the wrapper "is not meant for production use".
Step 2:
If you already run Linux container builds on PlayFab, this step is a check rather than a rebuild: confirm the image builds and starts locally, then push it to Edgegap's free registry, or keep ACR, DockerHub, GitLab or any other OCI-compatible registry.
If your title runs Windows VM builds, you need a Linux server build first. That is real work, but Edgegap's dedicated plugins for Unity, Unreal Engine and Godot help you build the image automatically once you have a Linux server target.
Step 3:
GSDK feature | Edgegap replacement |
|---|---|
Game Server SDK (GSDK) | |
Builds and VM sizes | Apps and Versions. Choose vCPU and memory per version, fractionable from 0.25 vCPU. |
Build regions | No region configuration. Placement at request time at the best available location on the Edge Cloud network for on-demand compute, Private Fleets on bare metal for reserved capacity. |
Standby servers and target standby math | Automatic scaling for on-demand compute (Edge Cloud). Private Fleets on bare metal for persistent capacity, rightsized monthly. |
Dynamic and scheduled standby | Not required. Overflow to Edge Cloud is automatic. |
RequestMultiplayerServer | One POST to the deploy endpoint, from an Azure Function on the match_found rule, or your backend. |
PlayFab matchmaker | Unchanged, with server allocation turned off on the queue. A match_found rule triggers the deployment. |
Server connection details | Written to each player’s read-only player data by a second Azure Function once the server is ready, and read by your client. Your game server holds no PlayFab secret. |
Server logs and archived servers | Deployment logs, Deployment Status API and Deployment Webhook. |
Server management in Game Manager | Edgegap Dashboard, Deploy API and Deployment Analytics and Monitoring. |
Porting work | Optional: connect your coding agent to the Edgegap MCP server. It loads Edgegap’s tested agent skills for your engine, then builds or checks your image, uploads it and deploys your server, and every change can be previewed as a dry run first. The PlayFab skill sets up the queue, the two Azure Functions and the match_found rule end to end. |
Step 4:
Private Fleets are the closest thing to the capacity you manage today: persistent, dedicated bare metal hosts with egress-free hosting.
The difference is the work around them. There is no standby target to compute, no per-region thresholds or multipliers to tune, and no ramp-down window. You rightsize the fleet monthly, and when a Private Fleet is full, deployments overflow onto Edge Cloud automatically.
Pricing
Discover how Edgegap's orchestration is cost effective versus your current PlayFab Multiplayer Servers bill.
PlayFab's own guidance is to size a standby pool from propping time and allocation rate, and it states that servers in the propping and standing-by states are billed to your title.
PlayFab Multiplayer Servers | Edgegap | |
|---|---|---|
Idle capacity | Billed. Standby and propping servers run and bill between peaks | Not billed on Edge Cloud. Zero active deployments costs $0 |
Sizing method | Standby target calculated from propping time and target allocation rate, per region | Nothing to size on Edge Cloud. Private Fleets rightsized monthly |
Failure mode | Standby pool starvation: server requests fail when demand outruns provisioning | Deployments are created per match, provisioned from scratch in 2 seconds, median, to container ready |
You buy a machine shape on PlayFab. You buy compute on Edgegap.
PlayFab Multiplayer Servers | Edgegap | |
|---|---|---|
Unit | VM size chosen by cores, RAM and storage, per build region | vCPU-minute, fractionable from 0.25 vCPU |
Granularity | Whole machines, plus servers-per-machine packing you manage | Per deployment, with no packing decisions |
Rate | Per VM size, per region, per PlayFab's published price list | $0.00115 per vCPU per minute worldwide, single price |
A fleet sized for peak is idle most of the week. Hybrid orchestration keeps hosting cost-effective by combining bare metal Private Fleets with on-demand Edge Cloud.
PlayFab Multiplayer Servers | Edgegap | |
|---|---|---|
Reserved capacity | Standby pools you size per region, tuned with thresholds and multipliers | Bare metal Private Fleets, rightsized monthly as the traffic curve moves |
On-demand capacity | Dynamic standby multiplies the target standby you configured, up to your maximum servers | Edge Cloud network of 615+ locations, each deployment at the best available location at request time |
Net effect at thousands of CCU | Capacity planning as an ongoing operational task | 25 to 35 percent below pure cloud with a properly optimized split. Model it in the pricing calculator |
Edgegap | Azure PlayFab | |
|---|---|---|
Orchestration | Hybrid orchestration, no game server SDK required: |
|
Infrastructure |
| Single provider:
|
Hardware |
|
|
Placement |
|
|
Pricing |
| |
Scalability |
|
|
Integration |
|
|
Support |
| |
Latency | 58% average reduction vs. public cloud (Edgegap case study) |
|
Track Records |
|

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.
No. This migration moves Multiplayer Servers only. Your matchmaking queues and rules, Player Data, economy, auth, leaderboards and CloudScript stay in PlayFab and keep working exactly as they do now. The integration is two Azure Functions: a match_found rule runs the first, which deploys a server on Edgegap near the matched players, and Edgegap calls the second when the server is ready, which writes the address and port into each player's read-only data for the client to read. Your game server holds no PlayFab secret. We publish the whole thing as a working Unity sample, and the PlayFab skill for the Edgegap MCP server can set it up with your coding agent.
It comes out and nothing proprietary replaces it. The agent start-up, the ready and session callbacks, the shutdown handler and the health-report loop all go. On Edgegap your server reads its public IP and port mapping from environment variables at deployment and is ready as soon as it listens. If you integrated through PlayFab's GSDK wrapper rather than directly, that comes out too; their own documentation says the wrapper "is not meant for production use".
Today you calculate a standby target from propping time and allocation rate, set maximum servers per region, and tune dynamic standby thresholds and multipliers so the pool does not starve, with servers in propping and standing-by states on your bill throughout. On Edge Cloud there is no pool: each match gets a deployment, provisioned from scratch in 2 seconds, median, measured to container ready, before the game engine starts. If you want capacity that is already yours, Private Fleets give you that, rightsized monthly rather than tuned per region.
It is the one thing on this page that can be real work, so here it is plainly: Edgegap runs Linux containers, so a Windows-only server needs a Linux build before anything else. For most Unity and Unreal projects that is a build target and a pass over platform-specific code. If your server depends on Windows-only libraries it is a project, and it needs an honest look at what that means for your architecture. That is a conversation we are happy to have: talk to our engineers and we will work through the move to Linux game server instances with you. If you already ship Linux container builds on PlayFab, none of this applies and your artifact is unchanged.
Yes. Queues, rules, tickets and the matchmaking behaviour your players experience are untouched, because PlayFab is still doing the matchmaking. Two things change. Server allocation is turned off on the queue, so PlayFab only forms the match. And instead of requesting a server from your provisioned capacity, the match_found rule runs an Azure Function that posts once to Edgegap's deploy endpoint with the players' locations, so the server is placed for the players actually in that match. If you would rather consolidate later, Edgegap's no-code matchmaker is there, but nothing about this migration requires it.
Mostly from capacity you stop paying for while it waits. PlayFab bills servers in the propping and standing-by states, so a pool sized for your peak allocation rate runs and bills through every quiet hour. On Edge Cloud, zero active deployments costs $0, and compute is $0.00115 per vCPU per minute, fractionable from 0.25 vCPU, rather than a VM size you pick per region. At thousands of CCU, a properly optimized split of Private Fleets and Edge Cloud lands 25 to 35 percent below pure cloud. Model your own traffic in our pricing calculator rather than taking the range on faith.
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.