Nakama · Rate Limits

Nakama Rate Limits

Nakama does not ship a fixed, published per-endpoint rate-limit table the way a typical hosted SaaS API does. Because the server is open source and self-hosted, throughput is bounded by the operator's own compute and database capacity and by server configuration. Nakama's runtime provides mechanisms an operator uses to bound and shape load - for example configurable maximum message sizes and per-connection limits on the realtime socket, session and token lifetimes, and the ability to enforce custom rate limits inside runtime (Go / TypeScript / Lua) RPC and before/after hooks. On Heroic Cloud, effective limits are governed by the provisioned tier (node count, database capacity, and concurrent-user allowance) rather than by a per-key request quota.

Nakama Rate Limits is the machine-readable rate-limit profile for Nakama on the APIs.io network, conforming to the API Commons Rate Limits specification.

It captures 5 rate-limit definitions, measuring bytes, seconds, connections, and requests.

The profile also includes 3 backoff/retry policies defined and response codes documented for throttled.

Tagged areas include Gaming, Game Backend, Realtime, Open Source, and Rate Limiting.

5 Limits Throttle: 429
GamingGame BackendRealtimeOpen SourceRate LimitingQuotasThrottling

Limits

Realtime Socket Message Size connection
bytes
operator-configured (max_message_size_bytes)
Maximum inbound WebSocket message size, set in the socket configuration.
Realtime Socket Ping/Pong and Idle Timeout connection
seconds
operator-configured (ping_period_ms / pong_wait_ms / idle_timeout_ms)
Idle and heartbeat timeouts close inactive realtime connections.
Concurrent Connections server
connections
bounded by infrastructure / Heroic Cloud tier
Concurrent-user capacity depends on provisioned nodes and database.
Custom RPC / Hook Rate Limits account
requests
operator-defined in runtime code
Operators enforce per-user or per-endpoint limits inside runtime functions and before/after hooks.
Session and Token Lifetime account
seconds
operator-configured (token_expiry_sec / refresh_token_expiry_sec)
Bounds how long a session token and refresh token remain valid.

Policies

Operator-Controlled
Because Nakama is self-hostable, most limits are configuration- or code-driven rather than fixed by the vendor.
Tier-Governed on Heroic Cloud
Managed capacity (nodes, database, concurrent users) sets the effective ceiling on Heroic Cloud.
Backoff Strategy
Clients should implement exponential backoff with jitter and honor server-side error responses (including 429).

Sources