Blog / 2026-04-21

Hathora shuts down May 5. Here's how to move to Asobi.

Hathora ends game hosting on 2026-05-05 after its acquisition by an AI company. If you're running a game on it, you have two weeks. We wrote a migration guide, and we'll help you ship before the deadline.

On 2026-03-04 Hathora announced it was ending its game-hosting service after being acquired by an AI-inference company. The shutdown date is 2026-05-05. Stormgate, Splitgate 2, and Predecessor are among the casualties. If you're running on hathora.dev or hathora.cloud, you have about two weeks.

We've written a full migration guide. This post is the short version, the pitch, and an open offer: we will prioritise Hathora-migration help in the Discord through May.

The short version

Asobi is an open-source, Apache-2, self-hostable multiplayer backend. One container, one Postgres, no Kubernetes. It has the pieces Hathora had (matchmaker, lobbies, rooms, regions) plus the pieces Hathora didn't (hot-reloadable Lua, voting, phases, seasons, spatial zones, Godot/Defold SDKs).

Managed cloud opens later in 2026. For the next fortnight the path is self-host. A small Hetzner box (CX22, €4/mo) comfortably holds thousands of concurrent players. You can run it on your laptop while you port, then move it somewhere real when you're ready.

Concept map

Hathora's nouns line up with ours almost cleanly:

  • Application → asobi deployment (one container per env).
  • Room / Process → Match (a BEAM process per match, thousands per container).
  • Lobby → Matchmaker ticket + match in "waiting" phase.
  • Matchmaker 2.0asobi_matchmaker with pluggable strategies (fill / skill / your own).
  • HathoraClient.loginAnonymousPOST /api/v1/auth/register with a client-generated username+password (no anonymous flag today; the guide has details).
  • getConnectionInfo(roomId) → one long-lived WebSocket per player. First frame is session.connect with the session token; the server pushes match.matched when matchmaking resolves.

Two paths

A. Keep your existing game server

If you have a lot of C# / Go / Node server code, keep running it in its own container on Hetzner, Fly, or Scaleway. Let Asobi handle auth, matchmaking, lobbies, leaderboards, and persistence. Your server talks to Asobi with an API key. This is the fast path — usually a week of work.

B. Fold the game into Lua

Rewrite your tick/input/state logic as a match.lua file. The callbacks are init / join / leave / handle_input / tick / get_state. For most Hathora games this is a few hundred lines. You get hot-reload for free (edit + save + live matches update), and you delete a container from your ops budget.

Cost comparison

A small-indie Hathora game was typically $200–800/month on process-hours. The same game on Asobi at Hetzner is €5–20/month of infra. That's not a typo. The BEAM gets you tens of thousands of cheap processes per node; Hathora was paying container-per-match overhead.

What Asobi doesn't do

Be honest with yourself before committing:

  • No UDP transport. WebSocket/TCP only. If you're a twitch FPS, pair Asobi with a UDP relay for physics and use Asobi for everything else.
  • No auto-multi-region. Deploy one container per region yourself.
  • No client-side prediction / rollback primitives yet. On the roadmap.
  • Pre-1.0 API. Minor breaks possible before 1.0.

What to do today

  1. git clone the asobi_lua repo and run docker compose up. Register a player. Confirm it works.
  2. Pick one SDK call in your client (loginAnonymous is the usual first) and port it.
  3. Join the Discord #migrations channel. We'll sanity-check your plan.
  4. Set a cutover date before 2026-05-05.

We'd rather you land on Asobi than drown in a 72-hour panic next month. Even if you don't migrate to us, the full guide has enough concept-mapping to help you migrate to any backend. Good luck, and ping us if you need a hand.