Dashboard Overview

The Rudder dashboard at app.rudder.build is where you author all of your game’s content, manage players, and control releases. Everything you can do in the dashboard is also available through the platform API, but this page walks through what you see in the UI.

Signing up

Register with your email and a password (the name field is optional). After signing up you land on a confirm your email screen — we send a confirmation link to your inbox. Open the link to activate your account; it signs you in and takes you straight to the Projects list. The link is valid for 24 hours, and you can resend it from the confirmation screen.

Projects

A project is one game. The Projects page lists all projects you belong to, with your role on each. From here you can:

Create Project — give it a name and optional description, and invite team members.
Open — enter the project’s workspace.
Edit / Delete — available if your role is owner or admin.

Deleting a project soft-deletes it along with all associated data, so the UI asks for confirmation.

Inside a project

Opening a project takes you to its workspace: a sidebar on the left, a topbar on top.

The sidebar is grouped into sections:

Main — Dashboard.
LiveOps — Counters, Modules, Calendar.
Users & Config — Players, Storage.
Deployment — Releases, SDK.
System — Settings.

Below these, every installed module adds its own section with its pages and a Settings entry (for example Leaderboards → Boards or Store → Offers).

The topbar holds, left to right:

Breadcrumbs for the current page.
Environment selector (see below).
Plan badge showing your pricing plan and current MAU usage as a percentage. It turns into a warning state as you approach the limit; click it to open project settings.
Quick navigation (⌘K on macOS, Ctrl+K elsewhere) — a command palette for jumping between pages.
A light/dark theme toggle and the user menu (account settings, logout).

Environments

Every project has exactly two environments: staging and prod (shown as “Production”). Content — counters, module installs, resource rows, releases — is authored per environment, and so are players, wallets and storage. The environment selector in the topbar controls which one you are looking at, including on the Players and Project Storage pages.

Key behaviors:

prod is read-only. When the production environment is selected, authoring UI (create/edit/delete buttons) is disabled. Changes reach production only through a release promotion (see Releases below).
No custom environments. Environments cannot be created, merged, or deleted — two is the whole model, and staging is a full sandbox with its own players.
Keys are per environment. Project Settings shows the SDK key and the admin key of the selected environment, each regenerated independently.

See Projects and Environments for how environments map to the API.

Feature areas

Dashboard

The project home page. It shows DAU/MAU stat cards with change indicators, your pricing plan and MAU quota, a retention chart, a calendar of scheduled module rows for the next 14 days, your installed modules, and quick links into the main pages.

Counters

Sidebar → LiveOps → Counters. Counters are named player-level integers used for currencies, XP and progress. Each has a name, a slug and a kind (currency or number); slug and kind are fixed after creation. Counters take effect in the runtime after a release. See Counters.

Modules

Sidebar → LiveOps → Modules. Lists installed modules and the marketplace. Installing a module also offers to install its dependencies. Each installed module gets a sidebar section built from its manifest: resource pages (tables, cards, timelines, tracks, results), detail pages with widgets, and a Settings page where you update, enable or disable, eject, uninstall the module and download its source. Logs shows module console output and failures for the last 7 days. See Modules and First-party modules.

Calendar

Sidebar → LiveOps → Calendar. A timeline of the rows of enabled modules that have a schedule field, such as store offers, quests, battle pass seasons and remote config overrides.

Players

Sidebar → Users & Config → Players. Search players by ID or nickname, or browse the paginated list. Opening a player shows a detail page with:

Profile fields: player ID, nickname, region, language, payer status, ban status, created/ updated timestamps.
Wallet tab — current balances and recent transactions per currency.
Storages tab — the player’s storage documents, with type and expiry.
Custom Data tab — the raw player JSON, read-only.
Linked Accounts tab — the identities linked to the player (device, Google, Apple, or custom providers).
Widgets added by installed modules, for example the inventory module’s item table with Grant item and Remove item actions.

From the detail page you can ban a player (with a required reason), unban, adjust wallet balances (amount plus a required reason), and delete the player. Deleting anonymizes the player and cannot be undone. Every adjustment asks for a reason, which is recorded for audit.

Storage

Sidebar → Users & Config → Storage. Global (project-level) key-value storage — typed documents shared across all players, as opposed to the per-player storages on the player detail page. Create, edit, and delete entries here.

Releases

Sidebar → Deployment → Releases. Releases snapshot your environment’s counters, module installs and project-scoped resource rows. The page lists releases for the currently selected environment with version number, status, description, included content versions, and creation date.

Publish (staging only) snapshots the current environment. Only one release can be building at a time — the button is disabled while a release is being built.
Promote copies a completed release from one environment to another (e.g. staging → prod). After promoting, the dashboard switches you to the target environment so you see the result immediately.
Rollback creates a new release with the content of an older version.

See Releases and Publishing for the underlying model.

SDK

Sidebar → Deployment → SDK. Step-by-step installation instructions for each client SDK — npm (@rudder/sdk), Unity Package Manager (build.rudder.sdk), and NuGet (Rudder.Sdk) — including the private registry configuration. Use this page when wiring a new game client to the project.

Settings

Sidebar → System → Settings. Project-level configuration:

Project Information — rename the project, and manage the two API keys:
- SDK Key — authenticates game clients in the selected environment.
- Admin Key — secret for server-side integrations in the selected environment; never ship it in a game client.
- Both keys have Copy and Generate buttons. Generating a key persists immediately and invalidates the previous key on the spot — there is no grace period.
Authentication — configure the sign-in providers available to your players:
- Google and Apple — each with an enable toggle and a list of client IDs (one per line).
- Custom Providers — point Rudder at your own auth backend. You can add multiple named providers, each with an enabled toggle, a webhook URL, and an HMAC secret (used for the X-Signature header). The secret’s Generate button only fills in a random value locally; nothing is saved until you click Save.
Pricing and Usage — your current plan and MAU consumption.
Danger Zone — delete the project (owner only).

Account settings

The user menu in the topbar (top right) opens /settings, which manages Personal Access Tokens for your account. PATs authenticate API access on your behalf. You can create and revoke tokens there; revoking takes effect immediately and cannot be undone.

Good to know

Almost all content pages are scoped to the current environment — if you can’t find an item you just created, check the environment selector first.
If authoring controls look disabled, you are probably looking at prod. Switch to staging to make changes, then promote a release.
The dashboard talks to the same API (https://api.rudder.build) that the SDKs use, so anything you do here is reproducible programmatically.