Scaling

Overview #

Heroic Cloud sizes infrastructure by CPU cores for both Nakama and database resources. Development instances have fixed resources and can’t be scaled. Production instances are sized by tier, and you can scale up or down at any time. All billing is handled through Stripe. See Billing for details.

Development vs. production #

Choosing the right environment type is one of the most important decisions you’ll make. The two types differ in hardware, scalability, and reliability.

Development (non-scalable): Nakama dev servers have burstable resources. Satori dev servers have fixed resources. Neither can be scaled or upgraded. Development instances run on shared infrastructure and are for building and testing only. They aren’t suitable for load testing, and performance numbers from dev instances don’t reflect production behavior.

Satori dev instances have additional limitations: lower-priority background updates (for example, audience recalculations run less frequently), no load testing, and standard SLAs don’t apply.

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.
  • Seamless horizontal and vertical scalability within seconds.
  • 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.

Production Satori deployments include:

  • Scaling managed by Heroic Labs, with resources adjusted based on player activity.
  • High availability and resilience for continuous uptime.
  • Enhanced SLAs available for stronger uptime guarantees.
  • Optimization for live operations workloads.

Nakama resource tiers #

Production Nakama instances can be scaled across a range of tiers, from Micro (2 CPU / 6 GB RAM) up to 5XLarge (64 CPU / 192 GB RAM), with the dashboard supporting up to 120 vCPUs. Larger deployments beyond what the dashboard offers are available upon request. Each tier specifies the CPU and memory allocation for your Nakama server nodes. The full list of available tiers and their specifications is visible in the dashboard when scaling 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 XLarge (32 CPU / 120 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 #

Select the desired tier for both Nakama resources and Nakama database, then apply the change. Scaling triggers a rolling reboot. Each Nakama pod restarts one at a time, so the deployment remains available throughout the process. No maintenance window coordination is needed for scaling changes.

Tier changes take effect within a few minutes. Nakama node scaling completes in approximately 2 minutes. Database scaling completes in under 5 minutes. No special coordination is required for any tier transition, including large jumps (for example, from Micro to 5XLarge).

Satori scaling #

Satori scaling is 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 own deployment with your own custom 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 applies to both Nakama nodes and database. 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 on request, but scale proactively ahead of known traffic events.

Database backups #

The database is automatically backed up every day. Differential binary backups are stored for a 7-day rolling window.

Backups are managed entirely by the platform. You don’t need to configure or schedule them.

These backups exist for infrastructure recovery purposes (for example, if a database needs to be rebuilt). They aren’t directly accessible to customers. If you need to query historical data or maintain your own backup copies, use the Data export feature for on-demand snapshots, or the database replica add-on for ongoing read-only access. See Disaster recovery and backups for full details on backup strategy and how to request a restore.