Titles and resources

A title represents one game in Heroic Cloud. It’s the container that holds all of your Nakama deployments, Satori deployments, and builders for that game.

Overview #

Titles solve the multi-game problem. If your studio ships three games, you create three titles. Each title isolates its resources, permissions, audit trails, and billing from the others. A team member working on Game A doesn’t need to see (or accidentally modify) Game B’s production deployment.

Even if you only have one game, titles still matter. They’re the boundary at which permissions are scoped. Grant a team access to an entire title (all environments for that game) or restrict them to specific resources within it.

Resources such as deployments can also be associated with multiple titles simultaneously. This is useful when a single deployment serves as a shared resource across more than one game—for example, a Satori deployment used by both “Sugar Sweats Saga” and “Sugar Sweats Soda”.

What lives inside a title #

A title contains three types of resources:

  • Nakama deployments are your game server instances. Most titles have multiple: one for development, one for QA, one for load testing, and one for production. See Nakama deployments.
  • Satori deployments are your LiveOps instances. Like Nakama, dev and production Satori instances live within the same title. See Satori deployments.
  • Builders are build pipelines connected to your Git repository. They compile your server code into container images for Nakama deployments. See Builders.

All of these resources share the title’s permission scope and appear in the title’s audit trail.

Deployments can’t be migrated between zones. Non-scalable (development) instances can’t be converted to scalable (production) instances (and vice versa). If you need to change either, create a new deployment and migrate your data. Don’t use non-scalable deployments for load testing or production traffic.

Titles and permissions #

Titles are the middle layer in the permission system. Organization-level permissions set the baseline, title-level permissions can narrow or expand access for a specific game, and resource-level permissions handle individual exceptions like locking down a production deployment.

Give your “Game A” team full access to the Game A title while giving them no visibility into Game B, even though both exist in the same organization. If one person works across multiple games, add them to multiple title-level permission grants.

See Access Control for the full permission model.

Titles and billing #

Billing is tracked per deployment, not per title. A title with no deployments costs nothing. Charges are listed by individual deployment in your billing breakdown—see exactly how much each environment costs per game.

Creating titles #

Create as many titles as you need—charges only apply when you create deployments within them. All title metadata (name, icon, engine type, game links) can be edited after creation.

Moving and sharing resources #

Resources aren’t permanently locked to a title.

Nakama deployments, Satori deployments, and builders can all be moved between titles. They can also belong to multiple titles simultaneously, which is useful when a single deployment or build pipeline is shared across more than one game.

Deleting a title #

All resources within a title (Nakama deployments, Satori deployments, and builders) must be removed before the title can be deleted. Deleting a title removes its metadata, audit history, and permission configuration permanently.

See also #