Projects & Environments

Projects

A project is the top-level container in Rudder. One project corresponds to one game: it holds all players, all authored content (counters, installed modules and their resource rows), and all keys.

Projects are created in the dashboard (Projects → Create Project). The creator becomes the project owner; other dashboard users can be added as members. Every dashboard and admin API operation checks project membership, so members of one project cannot see or modify another.

Environments

Every project has exactly two environments, and only two:

• staging — the authoring environment and a complete sandbox. All day-to-day content work happens here, and it has its own players.
• prod — the live environment your shipped builds point at. Content in prod is read-only in the dashboard; it changes only through a release or a promote (see Releases & Publishing).

You cannot create, rename, merge, or delete environments. There are no custom environments — one sandbox and one live environment is the whole model.

Keys

Each environment has its own pair of keys, shown under Project Settings for whichever environment the dashboard switcher is on:

• SDK key — identifies the project and the environment at player login. Safe to embed in a shipped game client; it grants access only to the player-facing /sdk/v1 API.
• Admin key — grants full server-side admin access for that environment (the /game/v1 HTTP API with X-API-Key, called from your game servers). Treat it as a secret and never ship it in a client.

The key is the environment selector. There is no environment parameter in the client API: the SDK key is resolved at login and the environment is stamped into the player’s access and refresh tokens, and an admin key resolves to the environment it was issued for. Point a development build at the staging SDK key and a shipped build at the prod one, and give your staging game servers the staging admin key.

Both keys can be rotated from Project Settings (Generate). Rotation takes effect immediately and the previous key is rejected from that moment — there is no grace window, so rotate only when you can deploy the new key.

What is isolated

Almost everything. An environment is a full copy of the game, not just a content branch:

• Content — counters, module installs and resource rows each belong to one environment. Editing in staging never touches prod.
• Players — a player belongs to the environment they logged in through. The same device ID or the same custom-auth subject produces two unrelated accounts under the staging key and the prod key.
• Player data — wallets, counters, player storage and player-scoped resource rows (inventory, quest progress, battle pass progress, purchases, leaderboard entries) all hang off the player, so they are isolated too.
• Project storage and module logs — stored per environment.
• Custom auth — the webhook URL and secret are configured per environment, so staging can point at your test backend.

Nothing crosses over. There is no way to migrate a player between environments; staging is where you break things without consequences.

What is not per environment

Project membership, billing, and your monthly active user count. MAU is measured on prod players only — testing in staging never costs you anything. See Pricing.

What needs a release

Module installs and resource rows are live in their environment as soon as you save them. Counters are resolved from the environment’s latest completed release: an environment that has never had one has no currencies in wallets and ignores counter increments. That is not an error — publish a release in staging and counters start working.

Scheduled module functions run in both environments, each against its own installs and rows, so you can test schedules in staging. See Releases & Publishing.

Typical workflow

1. Install modules and author content in staging; publish a staging release when counters change.
2. Test with a build using the staging SDK key and a staging player.
3. Promote staging → prod to ship it. Resource rows keep their ids and counters and installs are matched by slug, so live players keep their progress.
4. Rotate keys from Project Settings if one leaks.

Next: Releases & Publishing.