Launch readiness checklist

While every game launch is different, this is the general list we’d recommend any studio put in place before a soft launch or full release. We’re happy to work through it with you.

Tell us your launch date as soon as you have one. Some of what follows takes lead time. Add-ons have to be provisioned. Assigning an engineer to your load tests needs calendar space. Give us the date early and we’ll have it ready. Please contact support@heroiclabs.com .

Load testing #

We view load testing as an ongoing exercise for any major release. It has saved teams a lot of production rollbacks. For a launch, we’d recommend running more than one round of testing. The first usually surfaces the major issues. Later runs narrow in on the core game loops worth optimizing, such as a database hot spot that needs an index.

Have your custom runtime code audited first. We consider this more or less essential before go-live. We’ve historically caught bad queries and calls that cause significant utilization issues at scale, and they’re much cheaper to find now than on launch night.
Run against a production-type instance. Development instances don’t scale and can’t be used for performance assessment.
Start small, then repeat at larger scale. Start with a single-core baseline on Nakama, then scale up from there rather than jumping straight to a massive test.
Capture profiling during the run. Profiling shows which parts of your code are burning CPU, allocating memory, or waiting on locks while the test runs. Profiling needs a support plan, and the export add-ons need setting up on our side, so give us notice either way.

We’re happy to run load tests with your team. That requires a support plan in place so we can assign an engineer. See Load test your Nakama deployment for the full method.

Infrastructure and sizing #

Nakama #

Right-size the node. Your own load test numbers should inform the node size. As a general starting point, most indie and AA games run on 2 to 4 vCPU and 4 to 8 GB RAM per Nakama node.
Run more than one node in production. A single node works in isolation, but you have no failover and can’t do rolling reboots during an update. High availability needs at least 2 vCPU.
Add 25% headroom on your baseline. The extra headroom covers traffic spikes and rolling reboots. During a rolling reboot one node drops out and the rest can absorb its load until it rejoins.
Segregate environments. Production Nakama must not point at a development Satori instance or database. Rotate service account keys before launch.
Confirm your Nakama version is inside the supported window. Heroic Cloud supports the last four official versions, and going back one is something we do for you. Upgrading during a launch window isn’t a plan.
Go through keys and secrets with your team. Confirm every key is held in your secret store rather than in source control or a client build. Only the people who need production access have it.
Set session token lifetimes for production. In your Nakama configuration, set session.token_expiry_sec to 2 or 3 times your game’s average play session. See Sessions .

Satori #

Move to a production Satori instance before you turn on the taps. A development instance won’t handle a burst of traffic, and deployment type is fixed at creation. Satori is fully managed, so there are no tiers to choose.
Give every experiment and live event a QA phase in production environment. You can create a QA audience with only test identities, so you can confirm variant values and flag overrides in production environment before launch.

Observability #

Every deployment comes with built-in metrics, logs, and an audit trail. If you’d like that data in your own monitoring stack, we can set up log export, APM export, a database replica, or continuous profiling for you.

Set up APM export if you run your own monitoring. We provide a secure endpoint, protected with authorization, that aggregates metrics across all Nakama nodes in Prometheus format. You scrape it once a minute with the scraper of your choice into Grafana, Stackdriver, CloudWatch, or anything compatible. It includes any custom metrics you emit from your own game module. See Metric exporting .
Set up log export if you need raw logs. We stream logs in batches to an S3 or GCS bucket, which can be read from Stackdriver or CloudWatch, or ingested into the system of your choice. See Log exporting .

Both APM and log exports run on dedicated exporters outside our shared system, for security and to prevent cross-contamination between deployments. We’re working on making them self-service from the dashboard, and in the meantime, contact us and we’ll set them up ahead of your run.

Support coverage #

We offer support plans that carry an SLA with uptime guarantees and put your deployment under active monitoring by our team, so outages and poorly performing queries are picked up on our side as well as yours and our on-call engineers can step in as soon as something goes wrong.

A support plan is also what lets us assign an engineer to your load tests and run the code audit of your custom server runtime. If you have a soft launch approaching with a full release behind it, we’d recommend a plan regardless, so that we’re monitoring the launch with you.

Talk to us about a support plan before your launch date. Contact sales@heroiclabs.com and we’ll walk you through the options and the SLA terms that come with them.
Confirm which add-ons you’ll have in place ahead of the date. Log export, APM export, database replicas, and profiling are all available. Reach out and we’ll get them provisioned in good time.