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

Migration
/
Hathora
Hathora closed its game hosting service in May 2026.
Your container does not have to change: keep the image you already ship, re-point one allocation call, and deploy to automated Private Fleets for cost-effective hosting. When demand runs past your fleet, hybrid orchestration bursts to our Edge Cloud network of 615+ locations worldwide, so players get coverage you never had to buy in advance.
What changes (and doesn't change)
A Hathora migration is a hosting change, not a rewrite. 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 to Hathora, 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.
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 CLI goes away
There is no server SDK to strip out, because Hathora never required one, and Edgegap does not either. What goes is the hosting CLI and the upload step around it: you push an image to a registry and create a Version, from the Dashboard or the API.
One deploy call replaces the room
Where your backend called CreateRoom and then asked for that room's connection info, you POST once to the deploy endpoint and get back an FQDN and port. Rooms become deployments, and processes become deployment status and webhooks.
Regions stop being a purchase decision
You no longer buy capacity region by region. Every deployment is placed at the best of 615+ locations at request time for Edge Cloud.
Reserved capacity becomes an option
Hathora billed you per running server and offered nothing underneath it. Private Fleets add egress-free dedicated hardware for your steady load, resized as your traffic curve moves, with everything past it deploying on Edge Cloud.
Expected Timeline
Step 1
Replace room creation and connection-info calls with one deploy request. No game server code changes.
~2 hours
Step 2
Your server already runs as a container on Hathora, so this step is a check rather than work.
Already done
Step 3
Edgegap's registry is available for free, or keep ECR, DockerHub, GitLab, etc.
~30 min.
Step 4
One HTTP request replaces room creation and connection info.
~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
Make sure to refer to our Switch from Hathora documentation for the latest updates to this process.
Before getting started, we expect that: you currently use, or recently used, Hathora, and you have a working game server container.
Edgegap does not require an SDK to integrate, and neither did Hathora, so nothing comes out of your game server. The work is in your backend. Wherever it created a room and then asked for that room's connection info, it now makes one deploy request to Edgegap and receives the address and port in the response. Deployment status and webhooks replace the process lifecycle you polled, and your client keeps connecting to an address and a port exactly as it does today.
Your game server already runs as a container, so 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 ECR, DockerHub, GitLab or any other OCI-compatible registry. If you want to rebuild from scratch, the quickstart tools for Unity, Unreal Engine and Godot take 5 to 20 minutes on a development project.
Hathora - Feature | Edgegap - Feature |
|---|---|
Authentication | Optionally, add fine-grained access controls: |
Hosting CLI | No CLI required! Use our Dashboard or automate builds with API. |
Create a Build | Try our quickstart tools - Unity / Unreal Engine. |
Hathora Lobbies |
|
Fleet | Private Fleets with Persistence and Cloud Overflow. Optionally add later on, or default to Match-Bound cloud. |
Eager Caching (Pro, Enterprise) - 3 seconds deployments | Active Caching (Pay as you Go) - 0.5 second deployments |
Ping Service (Regions) | Ping Beacons (automated in engine-specific SDKs) |
Telemetry (Analytics) |
Edgegap also offers an optional feature similar to Hathora's fleets and Elastic Metal: Private Fleets of persistent servers on bare metal, with egress-free hosting and automatic overflow to Edge Cloud when demand runs past the fleet.
Pricing
Discover how Edgegap's orchestration is cost effective versus what you were paying Hathora.
Hathora | Edgegap |
|---|---|
Billed. Per-region, fleet-based billing meant idle capacity was charged. | Not billed on Edge Cloud, where zero active deployments costs $0, and rightsized monthly on Private Fleets. |
Hathora | Edgegap |
|---|---|
IPv4 addresses billed as an extra. | IPv4 included, single worldwide price, pay per use at $0.00115 per vCPU per minute, fractionable from 0.25 vCPU. |
Hathora | Edgegap |
|---|---|
Capacity chosen and paid for per region across 14 regions, 5 of them in the United States. | Private Fleets for your baseline, bursting onto Edge Cloud at the best available location at request time. |
(Hathora figures as published in our comparison and migration guide, March 2026.)
Full comparison available here: "Edgegap vs Hathora".

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, but your situation decides the first step. If your game is still running somewhere, the migration is the ordinary one described on this page: your container is already a container, and the work is re-pointing one allocation call. If your servers are already dark, the path is the same with the order reversed: get the image deployed on Edgegap first, then re-point the backend. Either way, nothing about your build or your netcode has to be rewritten to get players back online.
Because a transition offered to you is still a migration, and the two paths cost different amounts of engineering. The transition path published for Hathora customers asks you to integrate a server SDK into your game server for lifecycle signalling, ready, allocate and shutdown, and to order its allocation service separately if your backend requests servers on demand, as the CreateRoom API did. Hathora asked for no server SDK in your game server. Neither do we: your container stays as it is, and your backend makes one deploy call. Weigh that alongside published pricing and self-serve access.
Less than on any other migration we publish, and we would rather say so than invent work. Hathora was container-based, so the artifact you push is the artifact you already build. What changes is the vocabulary and one call: rooms become deployments, processes become deployment status and webhooks, and the CLI is replaced by the Dashboard or the API. Your engine, your netcode and your client connect flow are untouched.
There is no single drop-in, which is the honest answer: Lobbies bundled three things and Edgegap separates them. For DevOps and testing, the Deployment Status API tells you what a deployment is doing. For backend automation, the Deployment Webhook pushes those events to you. For the player-facing part, Server Browser handles search and browse, with Group Up for matchmaking or Reserve Seat to hold a spot. Most teams end up using two of the three.
Private Fleets, and they are a closer match than the name suggests: persistent servers on dedicated hardware, with lower egress, and cloud overflow when traffic goes past what the fleet covers. The difference is what you maintain. Scaling is automated rather than a per-region configuration you keep in tune, and you rightsize monthly as your traffic curve moves instead of committing ahead of a season. Worth checking on any option you compare: a buffer of pre-started servers is capacity you run and pay for between sessions. On Edge Cloud there is no buffer to size.
Yes. Every backend Hathora supported is supported here: Epic Online Services, PlayFab, Unity Gaming Services, Nakama by Heroic Labs, Pragma (see our joint case study), Beamable, and custom backends. Edgegap also integrates with BrainCloud, LootLocker, Invokation Games, XSOLLA and Network Next, among others. If your backend is the part you were most worried about, it is usually the part that moves with the least work.