Is Crux a drop-in replacement for Nakama?

No. Nakama includes an extensible server runtime and realtime multiplayer/social features. Crux is a managed fixed-scope backend and does not execute your Go, TypeScript or Lua runtime modules. Migration is a fit decision, not an API rename.

When should I keep Nakama?

Keep Nakama when source-level control, self-hosting/private cloud, embedded server runtime logic, chat/groups, or Nakama realtime multiplayer are core requirements and your team is comfortable operating that stack or paying Heroic Cloud to operate it.

When does Crux fit better than self-hosted Nakama?

Crux fits when your requirements are mostly managed backend primitives such as player identity, durable documents, stats, achievements, leaderboards, economy, social friends, matchmaking, live config, webhooks and server registry, and you do not want an embedded backend runtime to operate.

Nakama · self-hosted vs managed

Do not replace Nakama unless the thing you want to remove is operating Nakama.

Nakama is a capable open-source backend with realtime multiplayer, social features and an embedded server runtime. Crux makes a different trade: fewer extension points, no backend code runtime, and no Nakama cluster/database for your team to operate.

Test the managed path free → Compare Nakama costs

If you depend on Nakama runtime code, groups/chat, or its realtime multiplayer engine, staying on Nakama can be the correct decision.

Different ownership models not drop-in

Nakama OSS / Heroic Cloud
  source + server runtime
  realtime multiplayer
  chat / groups / social
  self-host or managed Nakama

Crux
  managed fixed-scope API
  persistent game data
  progression + economy
  matchmaking + registry
  webhooks / live config
  no embedded code runtime

Verify before you integrate

Compare the actual surfaces, not category labels.

Nakama's documentation and source are public. Crux exposes its OpenAPI contract and MIT client SDKs. You can inspect both before deciding which ownership model fits.

Live API status

A live check of the hosted API right now. No made-up uptime percentage and no hidden demo environment.

Check current status

Public API contract

The hosted HTTP surface is documented as OpenAPI. Inspect the wire format before choosing an SDK or writing an adapter.

Open the spec

MIT client SDKs

The JavaScript, Godot, Unity, and Roblox client SDK source is public. The hosted backend itself remains a managed proprietary service.

Inspect the SDK source

Documented exit path

Read what is exportable today and the written commitment for advance notice plus an export window if the hosted service winds down.

Read the exit guarantee

Migration gap matrix

See which Nakama capabilities map to Crux, which change semantics, and which need to stay in another service before estimating a migration.

Inspect the gap matrix

Decision first

Nakama wins when extensibility is the product requirement.

Heroic Labs documents Nakama as an open-source social/realtime backend with server runtime modules in Go, TypeScript/JavaScript and Lua. If that runtime is where your game rules live, replacing it with a narrower managed API can increase—not reduce—complexity.

Choose Nakama / Heroic Cloud when

You need to run custom backend logic inside the platform.
Realtime multiplayer, chat, groups/clans or richer social primitives are central.
Self-hosting, private cloud or source-level control is mandatory.
Your team already operates Nakama successfully, or wants Heroic Cloud to operate the same architecture.

Evaluate Crux when

The backend is mostly standard game-service primitives rather than embedded runtime code.
You want a managed API without running Nakama + database infrastructure.
Authoritative game logic already lives in your game server or another service.
You value a small explicit surface over maximum backend extensibility.

Capability boundary

Capability	Nakama	Crux
Source / self-host	Open source; self-host or Heroic Cloud	Hosted backend is proprietary; client SDKs are MIT and OpenAPI is public
Server runtime code	Go, TypeScript/JS and Lua runtime modules	No embedded runtime; logic runs in your game server/service
Realtime multiplayer	Built in	Not a netcode engine
Persistent player data	Storage engine	Player/project documents, stats and progression primitives
Social	Friends, groups, chat and more	Friends/requests/blocks; no groups or player chat service
Economy / leaderboards	Native APIs	Native APIs, but schemas/semantics are not 1:1
Operations	You operate OSS, or Heroic Cloud operates Nakama	Managed Crux API; your game-server compute remains yours

Evaluate before migrating

Prove the smaller surface is enough.

The right experiment is not “can Crux imitate every Nakama API?” It cannot. The useful experiment is whether your game actually needs the parts that do not map.

Inventory Nakama runtime modules, realtime matches, chat/groups, storage, leaderboards, economy and authentication providers.
Mark every dependency as native in Crux, semantic rewrite, or external service.
Create the free Crux project and run one real request from your engine/server.
Migrate one non-critical data path first; do not start with auth or the economy.
Only plan a full cutover after the gap matrix has no unresolved critical feature.

Run the managed-backend test → Read the migration gap matrix