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.0 →
asobi_matchmakerwith pluggable strategies (fill / skill / your own). - HathoraClient.loginAnonymous →
POST /api/v1/auth/registerwith 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.connectwith the session token; the server pushesmatch.matchedwhen 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
git clonethe asobi_lua repo and rundocker compose up. Register a player. Confirm it works.- Pick one SDK call in your client (
loginAnonymousis the usual first) and port it. - Join the Discord #migrations channel. We'll sanity-check your plan.
- 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.