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

Migration
/
PlayFab
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 Cloud Script function deploy on Edgegap the moment a match is found. Private Fleets carry your baseline on dedicated hardware, and demand past the fleet bursts onto 615+ Edge Cloud locations, placed at request time and 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 Cloud Script 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 Cloud Script function on the match_found rule posts to the deploy endpoint, and your server writes the address back to Player Data.
~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 Bridge.
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, and you can edit CloudScript in your title.
Edgegap does not require an 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".
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 build the image automatically once you have a Linux server target.
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 across 615+ Edge Cloud locations for on-demand compute, Private Fleets available for reserved capacity. |
Standby servers and target standby math | Automatic scaling for on-demand compute (Edge Cloud). Private Fleets for a persistent baseline, rightsized monthly. |
Dynamic and scheduled standby | Not required. Burst to Edge Cloud is automatic. |
RequestMultiplayerServer | One POST to the deploy endpoint, from CloudScript or your backend. |
PlayFab matchmaker | Unchanged. A match_found rule triggers the deployment. |
Server connection details | Written to PlayFab Player Data by your server, read by your client, exactly as in the published bridge sample. |
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. |
Private Fleets are the closest thing to the capacity you manage today: persistent, dedicated 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 anything past it bursts 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. A fleet sized for the floor, bursting on demand, is not.
PlayFab Multiplayer Servers | Edgegap | |
|---|---|---|
Baseline | Standby pools you size per region, tuned with thresholds and multipliers | Private Fleets, rightsized monthly as the traffic curve moves |
Burst | Dynamic standby multiplies the target standby you configured, up to your maximum servers | Automatic burst onto Edge Cloud, 615+ locations, placed 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 |

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.
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 dedicated bare-metal or VM 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. Available to each game from confirmed studios with live traffic.
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 ↑The subset of the 615+ where a studio can reserve dedicated bare-metal or VM hosts for its exclusive use rather than deploying into shared on-demand capacity. Published live on the Fleet Manager page. This is also the number that carries the included-egress allowance.
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.
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.
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 a CloudScript function on the match_found rule that deploys a server on Edgegap, and a few lines in your server that write the address and port back into Player Data for the client to read. We publish the whole thing, including a Unity sample, in the PlayFab Bridge guide.
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. What changes is what happens at the end: instead of requesting a server from your provisioned capacity, the match_found rule runs a CloudScript 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.