Satori deployments

LiveOps changes (player events, experiments, segments, and messages) shouldn’t require a code deploy and a release cycle. Satori is a managed LiveOps platform where everything is configured through the console, so producers and product managers can iterate on engagement strategies independently of your engineering team.

Unlike Nakama, you don’t manage infrastructure tiers or trigger deploys. Heroic Labs handles scaling, availability, and updates.

Creating a deployment #

When creating a Satori deployment, you choose:

1. Deployment type as either development or production. This can’t be changed later.
2. Deployment zone for the region (for example, US East). Choose a zone close to your players.
3. Instance name as a unique name (may contain dashes, for example mygame-satori-prod). This can’t be changed after creation, as it forms part of the internal naming scheme of the dedicated deployment stack, including DNS records.

Development vs. production #

Development instances are intended for testing and prototyping. Don’t use a development instance to evaluate Satori’s performance under load or run pre-launch validation.

Production instances are built for live player traffic:

• Managed scaling. Heroic Labs monitors and adjusts resources based on player activity. You don’t need to anticipate traffic spikes.
• High availability and resilience. Both Satori and its database run in HA mode. Built for continuous uptime with redundancy.
• Data backup. Production data is backed up in real-time and retained for 30 days. Development instances have daily backups retained for 7 days with no real-time backup.
• SLA. Production deployments are covered by a standard SLA. An enhanced SLA with stronger uptime guarantees is also available.
• Optimization for live operations. Faster background processing and tuning designed for LiveOps workloads at scale.

Configuration and management #

A Satori deployment has two kinds of configuration:

• Satori configuration: The LiveOps content running on the deployment, such as events, audiences, experiments, feature flags, and messages. Manage it in the Satori console.
• Deployment configuration: Server settings for the deployment, such as audit_log_retention_days, session_signing_key, and webhook_retries. To view or change them, open the deployment’s Deployment tab in the Heroic Cloud dashboard and select Edit Deployment.

The Heroic Cloud dashboard also manages the deployment itself, including creation, scaling, permissions, and audit.

Deleting a deployment #

Satori deployments can’t be paused or temporarily disabled, only deleted. Deletion is permanent and takes the deployment’s data with it. Delete protection is enabled by default on production deployments and has to be disabled before the deployment can be deleted.

Instance names only need to be unique among the deployments that currently exist in your organization, so deleting a deployment releases its name for reuse. The name is released when the deletion finishes, so a recreate attempted while the deletion is still running fails.

Each deployment is provisioned with a four-character suffix appended to its instance name, generated fresh every time it’s spun up. A recreated deployment has a different hostname even under the same instance name, so clients and any configuration you manage as code need repointing. See Reusing a deployment name for the same behaviour on the Nakama side.

Connecting your game client #

Each deployment gets a unique hostname in the format {instance-name}.{zone}.heroiclabs.com on port 443 (TLS encrypted). You also get an authentication key:

• API key is used by game clients and server-side services to authenticate with Satori. Anyone with this key can send events and read LiveOps configuration on behalf of a player. Treat it as a shared secret. You can create multiple keys under Settings > API Keys in the Satori console, for example one per SDK or event source, so you can revoke a compromised key without affecting other integrations.

The API key is a sensitive credential. Leaking it means anyone can send events to your deployment or read its LiveOps configuration. For this reason, access to it is gated behind the Secrets permission. Only users and service users with this permission can view or copy it. See Access control.

SDK code snippets are available for Unity, JavaScript, Godot, Java, Dart, and Swift. For full client SDK guides, API references, and connection examples, see the Satori documentation.

Audit #

Actions performed on the Satori deployment (creation, updates, deletion) are logged in the organization-level audit log under the Satori Deployment category. See Audit log.

Billing #

For the purposes of billing, Satori has only one usage metric: the number of player-generated events your deployment receives. Satori doesn’t charge for player count or for the number of identities, audiences, feature flags, experiments, or live events you create.

Other Satori charges are:

• Deployment cost: each Satori deployment has a base cost that depends on its type (development or production). Each environment you run, such as staging and production, is a separate deployment and is charged separately.
• Data lake integrations: each data lake integration is billed monthly, per integration.
• Support plans: optional support plans with response-time SLAs are billed monthly. See Billing.

Event usage accumulates throughout the month and is invoiced at the end of the month along with your other Heroic Cloud charges. See Billing for invoice timing.

Billable events #

Whether an event counts toward usage depends on what caused it. Most events caused by a player action count. Events that Satori generates as a result of its own processing don’t count.

• Custom events: every user-defined event you send counts toward usage, including any analytics events you send to track message delivery.
• Synthetic events: Satori generates synthetic events automatically. Whether each one counts is listed in the following table.
• Events for unknown identities: events sent for an identity ID that has never authenticated, for example server events, are stored and count toward usage.
• Rejected events: events that Satori rejects as invalid, for example because they don’t match your taxonomy, still count toward usage. Use the Debugger to find and fix them.
• Message sends: Satori doesn’t record message sends as events, so they don’t count toward usage.
• Console API changes: changes made through the Console API, such as updating identity properties, aren’t tied to a player session. They don’t generate events and don’t count toward usage.

See also #

• Satori documentation for LiveOps features, SDK guides, and API reference.
• Nakama deployments for game backend deployments.
• Scaling for cost details.
• Titles and resources for how Satori fits within a title.