Environment strategy

Two things define how studios work on Heroic Cloud: how you structure environments within a title, and how a title moves from first deployment to live production. These are related but separate concerns. The environment structure you establish early shapes how you execute each step of the lifecycle. This page covers both.

Getting environments right early saves time and avoids costly rebuilds later. The core principle: use development instances for building and iterating, and production instances for anything that requires reliable performance (load testing or live traffic).

InstanceTypePurpose
DevelopmentDevShared development and iteration. Supports roughly 100 concurrent players depending on workload. Cheaper but not scalable.
QADevQA validation and functional testing. A cost-effective way to verify builds before promoting to production.
Load testingProductionDedicated load testing, isolated from live traffic. Gives you accurate performance baselines.
ProductionProductionLive player traffic.

Why four deployments? #

A single deployment for “everything” creates risk. QA traffic can interfere with load tests. Load test traffic can impact live players. Separating concerns into four distinct deployments gives each team a clean environment. QA doesn’t need production-grade hardware since its purpose is functional testing, not performance validation. Save production deployments for load testing and live traffic where dedicated resources actually matter.

Can I use fewer instances? #

Yes. Smaller studios often start with just a development instance and a single production instance, then add QA and load testing instances as they approach launch. The key constraint is that development instances must never be used for performance assessment.

Key principles #

Development instances can’t be used for load testing or performance assessment. They run on shared, burstable hardware that is fundamentally different from production. Any numbers you get from a dev instance will be misleading.

Load testing should always run on a production-class instance. This is the only way to get performance numbers that translate to real-world capacity. See Load testing guide.

All environments live within a single title. A title groups all resources for one game. Your dev, QA, load testing, and production Nakama instances all live under the same title alongside your builders and Satori deployments. This keeps permissions, audit trails, and billing organized per game.

Standard lifecycle #

The steps below walk through the standard progression for a new title, from account creation to a running production game. Read through the full list before starting—the environment structure you establish in steps 5 and 6 depends on decisions made in earlier steps.

  1. Create your account and organization. Register using email/password, Google OAuth, or enterprise SSO. Skip billing and explore the demo title first if you’d like.
  2. Set up your organization. Enforce MFA (unless using SSO or OAuth), configure a support plan if needed, and invite team members. See Organizations.
  3. Create a title. Provide a game icon, engine type, and game links. All of this is editable later.
  4. Connect a builder. Create a Nakama Builder, connect it to your GitHub or GitLab repository, and trigger your first build. See Builders.
  5. Deploy to development. Create a dev Nakama instance and deploy the built image. Start building your game logic.
  6. Add QA and production instances. Create a second dev instance for QA, and production instances for load testing and live traffic. Scale production instances to the appropriate tiers. See Scaling.
  7. Set up CI/CD. Automate builds and deploys using service users and GitHub Actions. See CI/CD guide.
  8. Monitor and operate. Use dashboard metrics, logs, and optionally set up log or metric exporting add-ons for your own observability stack.