MIGRATION GUIDE · 2026-07-01

Hathora alternative 2026:
how to migrate your backend and validate it before cutover.

By Alexander Strandberg · Founder, Aevs

Hathora Cloud shut down on May 5, 2026, after the company was acquired by Fireworks AI. If your game ran dedicated servers on Hathora, you need a new host — and a way to prove the replacement behaves the same before your players find out it doesn't.

This guide maps Hathora's primitives to Aevs validation concepts, gives you a sandbox config template and a validation plan, and walks the migration step by step. Aevs is Netcode CI — it does not host your servers; it validates whichever host you move to.

What happened to Hathora?

Hathora Cloud — the room-and-process dedicated-server platform popular with indie and mid-size multiplayer studios — shut down on May 5, 2026, following Hathora's acquisition by Fireworks AI. Studios were given a migration window to move their server workloads elsewhere.

For many teams this was the second migration in a single year. Unity Multiplay shut down in March 2026, and a number of studios that moved from Multiplay to Hathora then had to move again weeks later. If that's you, the Multiplay guide is a useful companion — the validation approach below is identical. See the Unity Multiplay migration guide →

Concept mapping: Hathora → Aevs

Aevs doesn't reproduce Hathora's hosting primitives — it validates that whatever replaces them still works. The table below maps each Hathora primitive to the Aevs concept that verifies it on your new host.

Sandbox config template

Drop an aevs.sandbox.yaml at your repo root. The comments show where each field comes from in your old Hathora deployment. This is illustrative — adjust image, ports, and regions to your stack.

# Migrating from Hathora
version: 1
sandbox:
  name: hathora-migration
  runtime:
    image: ghcr.io/your-studio/game-server:latest  # was: hathora deploy build
    transport: [udp, tcp]                           # Hathora transportType
    port: 7777                                       # Hathora containerPort
  regions:                                           # Hathora region list
    - eu-central
    - us-east
    - ap-southeast
  concurrency:
    maxConcurrentSandboxes: 20                        # Hathora process ceiling
validate:
  plan: ./aevs.plan.ts                               # runs on every pull request

Validation plan: mirror your Hathora behavior

Write the plan first, while Hathora — or your captured Hathora behavior — is still the reference. It becomes the pass/fail contract for the migration: if the replacement passes the same plan, it is behaviorally equivalent for the scenarios you care about.

export default {
  id: 'hathora-migration-smoke',
  steps: [
    // 1. Room allocation (Hathora "create room")
    { type: 'http', method: 'POST', path: '/v1/rooms/create',
      body: { region: 'eu-central', gameMode: '4v4' },
      assert: { status: 'allocated' } },

    // 2. Process ready within 5s (Hathora "process running")
    { type: 'wait', condition: 'room.status === "ready"',
      timeout: 5_000 },

    // 3. Player joins via lobby (Hathora Lobby)
    { type: 'http', method: 'POST', path: '/v1/lobby/join',
      body: { playerId: 'p1', roomId: '{{room.id}}' } },
    { type: 'wait', condition: 'session.connected === true',
      timeout: 3_000 },

    // 4. Reconnect flow survives a drop
    { type: 'http', method: 'POST', path: '/v1/session/reconnect',
      body: { playerId: 'p1', roomId: '{{room.id}}' },
      assert: { reconnected: true } },
  ],
}

Estimated migration time

Rough guide for a mid-size studio. The validation work is fast and front-loaded; the host cutover dominates and varies by provider.

Step-by-step migration guide

Frequently asked questions

Is Aevs a drop-in replacement for Hathora?

No. Aevs does not host game servers. It is Netcode CI — it provisions an isolated sandbox per pull request, runs a declarative validation plan, and blocks merge when the plan fails. During a Hathora migration you still pick a new host; Aevs proves that host works before players see it.

I already migrated from Multiplay to Hathora. Do I have to start over?

No — the validation plan you write is host-independent. Point the same plan at your next host and it re-runs unchanged. If you moved Multiplay → Hathora and now need to move again, the plan you write once protects every future migration. Multiplay migration guide →

How much of my game code changes?

That depends on how deeply you used Hathora-specific APIs. Standard room create/join and process lifecycle calls have equivalents on most hosts. Hathora Lobby usage and region-routing logic will need provider-specific replacements — which is exactly what the validation plan is there to catch.