Scaling

Game traffic isn’t constant, and your backend shouldn’t be either. Heroic Cloud lets you scale Nakama nodes and the database independently by CPU tier.

Development vs. production instances #

Development and production instances have different infrastructure models, which determines whether scaling is available.

Development (non-scalable): Nakama dev servers have burstable resources. Satori dev servers have fixed resources and can’t be scaled or upgraded to a production tier. Development instances run on shared infrastructure and are for building and testing only. Performance numbers from dev instances don’t reflect production behavior.

Production (scalable): Production servers run on dedicated hardware reserved for your title.

Production Nakama deployments include:

  • Dedicated instances, each on its own hardware for consistent, predictable performance.
  • Horizontal and vertical scalability.
  • High availability when provisioned with at least 2 vCPUs. The system automatically places nodes on separate physical VMs, so a hardware failure on one machine doesn’t affect the other.

Nakama resource tiers #

Production Nakama instances scale across a range of tiers, from Nano (1 CPU / 3.75 GB RAM) up to 7XLarge (120 CPU / 360 GB RAM). Each tier specifies the CPU and memory allocation for your Nakama server nodes. The dashboard lists all available tiers when you scale a deployment.

Nakama database tiers #

The database scales independently from the Nakama nodes. This lets you size compute and storage separately based on your workload. Database tiers range from Nano (1 CPU / 3.75 GB RAM) up to 3XLarge (64 CPU / 240 GB RAM).

You can’t downgrade database CPU because CPU and memory are linked directly to disk allocation. Under certain conditions, the minimum database CPU available is 2. Contact Heroic Labs (support@heroiclabs.com) if you need to reduce database resources.

How scaling works #

When you apply a tier change, Nakama performs a rolling reboot: each pod restarts one at a time. Before each restart, Nakama drains active WebSocket connections gracefully. With two or more nodes, REST and WebSocket traffic continues uninterrupted — no maintenance window is needed. With a single node, expect brief downtime during the restart.

For authoritative multiplayer, truly uninterrupted restarts require cooperation from your game module. Use the graceful shutdown grace period to let your module finish in-flight work, and implement match migration to move players to a new match on another node before the restarting node goes down.

Tier changes take effect within a few minutes. Nakama node scaling completes in approximately 2 minutes. Database CPU scaling completes in under 5 minutes but causes brief downtime — typically under a minute, though it may extend to a few minutes depending on load. Tier transitions require no special coordination, including large jumps (for example, from Micro to 5XLarge).

Satori scaling #

Satori is fully managed by Heroic Labs. You don’t select resource tiers. Heroic Labs monitors and adjusts resources based on player activity, so you don’t need to anticipate traffic spikes for Satori.

Scaling recommendations #

No universal formula exists for how many vCPUs you need per number of concurrent users. Every game uses the backend differently, so database load and CPU usage vary significantly by implementation. Always load test your deployment with your own code to validate that your chosen tier meets your performance requirements.

Leave at least 25% headroom on both Nakama CPU and database CPU. Scale up when utilization reaches approximately 75%. This headroom allows for traffic spikes without degrading performance while you wait for scaling to complete.

The dashboard supports scaling up to 120 vCPUs. Larger deployments are available on request.

Auto-scaling is available through Heroic Labs on request, but scale proactively ahead of known traffic events.

See also #