Releases & Publishing

What is live and what needs a release

A project has two environments, staging and prod. Most changes take effect in their environment as soon as you save them:

• Module installs — installing, upgrading, configuring, enabling or ejecting a module changes what the environment runs right away.
• Resource rows — items, offers, quests, boards, configs and every other resource row are read live by module functions.

Counters are the exception. The runtime resolves counter slugs from the environment’s latest release, so a new counter does nothing (an increment of an unknown slug is silently ignored) until a release that contains it has completed.

Because edits are live, you author in staging, test there with staging players, and ship to players by promoting to prod. The dashboard shows prod as read-only.

What a release is

A release belongs to one project and one environment and carries:

• a version, incremented per project and environment (v1, v2, …);
• an optional description and notes;
• a status: building, then completed or failed;
• a snapshot: a JSON document stored as projects/<project>/<env>/v<N>.json, also written to projects/<project>/<env>/latest.json.

A snapshot contains:

• counters (archived counters excluded);
• module installs: slug, pinned version, config, enabled and ejected flags;
• project-scoped resource rows (rows of resources with scope project).

Player data is never part of a snapshot: players, wallets, player storage and player-scoped resource rows such as inventory or quest progress.

When a release completes, the backend reloads the environment’s counters from the new latest.json and bumps the catalog revision, so connected SDKs pick up new currencies on their next sync.

Promotion

Promote copies staging into prod in one transaction:

1. Counters, module installs and project-scoped resource rows from staging are created in prod, or updated in place when prod already has them. Counters and installs are matched by slug; resource rows are matched by resource slug and row id, and keep the same id in both environments.
2. Anything in prod that is missing from staging is deleted. Deleting a row or uninstalling a module in staging and promoting is how you remove it from production.
3. A new prod release is then built asynchronously.

Player-scoped rows in prod are not touched, so player progress that references content by slug or id keeps working after a promote.

If promotion fails, prod is left unchanged.

Rollback

Rollback restores an environment to a previous release:

1. Pick a completed release of the same project that still has its snapshot.
2. The environment’s counters, module installs and project-scoped rows are replaced with the snapshot contents in one transaction.
3. latest.json is overwritten and a new release row is created, so the rollback shows up in the history and can itself be rolled back.

Rollback restores content, not player data: rewards already granted stay granted.

Typical lifecycle

1. Install modules and author rows in staging; test with a staging SDK key.
2. Publish a staging release when you add or change counters.
3. Promote staging → prod.
4. If something is wrong in production, roll back prod, fix in staging, and promote again.

For the dashboard walkthrough, see the Releases guide. For the environment model, see Projects & Environments.