Hathora Shut Down May 5, 2026. Migration Options That Don't Suck

Fireworks AI bought Hathora in March, froze the game-hosting platform on day one, and turned it off completely on May 5, 2026. Customers got pushed to Nitrado via GameFabric. Here's what actually happened and what to do if you're still scrambling.

Hathora shut down for good on May 5, 2026. Two months earlier, Fireworks AI bought the company and froze the platform on day one. The engineering team got reassigned to AI inference work. The game-hosting customers got pointed at Nitrado.

If you weren't on Hathora, you're still affected. This is the second major game server hosting provider to disappear in two months (after Unity Multiplay shut down March 31). The pattern is worth paying attention to even if your fleet is currently fine.

What actually happened

Fireworks AI announced the acquisition on March 4, 2026. The game-hosting platform was effectively frozen the same day - no new fleet provisioning, no new customer onboarding, support continued through May 5. The official line from Hathora was that they were "joining Fireworks AI" to work on compute orchestration for AI inference.

The game customers were handed to Nitrado via Nitrado's GameFabric product. GameFabric is Nitrado's white-label dedicated-server-as-a-service play, and the Hathora deal seems to have been the proof point Nitrado was looking for. Whether your studio accepts that handoff depends on how well GameFabric's orchestration model maps to whatever Hathora was doing for you.

Some studios didn't wait for the handoff. Stormgate, one of the most public Hathora customers, announced they were rushing an offline mode to keep the game playable. Splitgate 2 and Predecessor migrated quietly. The smaller indie titles on the platform mostly ate the cost in private.

If you're still scrambling

The default option Nitrado wants you to pick is GameFabric. If your needs are simple and you trust Nitrado's operational track record (they've been running game servers for over a decade), this is the lowest-friction path. The migration tooling exists and the team has been doing this work for the entire Hathora customer base.

That said, the default isn't always the best fit. A few studios have told us they ran the migration calculator and went elsewhere:

Edgegap if your game cares about edge latency. They have 615+ locations globally and a usage-based pricing model: $0.00115 per vCPU-minute on the dedicated tier, $0.10/GB egress. Good fit for FPS, battle royale, anything where the server distance to the player is more important than the headline per-vCPU price.

Gameye if your accounting team wants a single number per vCPU-hour with no egress surprise. $0.07/hour on-demand, $0.025/hour reserved, bandwidth included in the compute rate. Their cost calculator vs AWS and Edgegap shows the egress savings clearly on high-traffic games.

Crux if your Hathora setup was bundled with a separately-managed backend (auth, leaderboards, player data, live ops). Crux consolidates server hosting and backend services on one platform, free up to 2K MAU plus 2M API calls. The migration trade-off here is that you're not just replacing the server orchestration layer, you're potentially also replacing your auth and player-data layer at the same time. Worth it if you wanted to consolidate anyway, more work than necessary if your backend stack is fine.

AWS GameLift if you have AWS muscle in-house already. The pricing is opaque and the lock-in is real, but if you're already running on AWS and you have a DevOps team that knows the AWS console, this is the path that adds the least new vendor risk.

The pattern worth paying attention to

Two providers in two months. Multiplay was a Unity-corporate decision (cost optimization, sunset a service that wasn't strategic). Hathora was an acquihire (Fireworks AI wanted the team for AI inference, the games were collateral).

The technology underneath is the same problem either way: schedule compute workloads across global regions with low latency and reliability. AI inference and game servers both need that. AI inference margins are much, much better than game server margins. So every game server provider with a strong orchestration team is an acquisition target until further notice.

What this means for your provider selection: vendor concentration is now a real risk dimension, on par with price and latency. The right question to ask a prospective game server vendor in May 2026 isn't "what's your SLA". It's "what's your business model and are your investors patient".

The vendors least exposed to the next acquisition are the ones whose game-hosting business is core to their identity, not a side bet. Nitrado has been doing this since 2001. Gameye has been doing it since 2017. Edgegap is purely game-hosting and not chasing the AI pivot. Rocket Science Group is literally the Multiplay engineering team operating as a single-purpose company. Crux is a game backend platform - game hosting is one product line of several, not the entire balance sheet.

The vendors most exposed are the ones whose orchestration tech is good but whose game-customer revenue is thin compared to what their team could earn doing AI work. That description fit Hathora exactly. It's worth asking who else it fits.

If you weren't on Hathora but you're paying attention

The smart move is to build a "second provider" plan now, before you need it. Most studios that survived the Multiplay shutdown without panic had one thing in common: they'd already piloted a second provider on a small percentage of traffic. When the main provider went away, they had a runbook for scaling the secondary up.

The work is real but small if you do it cold: about a week of engineering to get a second provider's SDK integrated behind a feature flag, plus a few days of canary traffic to confirm it works. The same work in panic mode after your primary disappears takes four times as long and produces twice as many bugs.

What we'd do this week

If you were on Hathora and you took the Nitrado default, you're fine, run a load test before week three. If you picked an alternative, you're probably also fine, just keep the Hathora SDK code in your repo for a few months in case something breaks.

If you weren't on Hathora but you're on a different mid-size provider, this is the week to ask yourself how you'd react if your provider got the same call. Pilot a second option. Write the runbook. Don't wait for the press release.

Related reading