Fixback docs

The dashboard

Environments

An environment is one deploy target of a Project — Production, Staging, and the like. Each has its own keys and its own Gate, so staging can run Open for testers who never sign in while production stays Invited or Internal — and every report still lands in the Project's one queue.

What an environment owns

Environments live in the Project's rail: an environment switcher sits above three pages that show the one picked — Install, Access (its Gate, Open, Invited or Internal, and its sites) and Keys. Switching keeps you on the same page; the switcher's menu adds, renames and deletes them. Every environment owns:

  • its own publishable key (pk_…) and secret keys (sk_…);
  • its own Gate;
  • its own sites — the origins its key may report from, beside any the Project lists for all environments;
  • a name, unique within the Project — the label its Issues carry and the queue filters by.

Everything else stays with the Project: one queue, one repository connection, one set of Reporter invites and Reporters, the default landing and the app links sign-in returns through, and the capture and privacy settings. Staging and production are environments of one Project, not two Projects.

The key decides the environment

No SDK has an environment option. Fixback resolves the environment from the key a request presents — never from anything the client says — and weighs the reporter against that environment's Gate. A deploy target is chosen by the keys it carries: the staging build ships Staging's publishable key, and the staging server holds a Staging secret key as FIXBACK_SECRET_KEY. Nothing else in your code changes.

  • Browser and mobile reports land in the environment of the publishable key.
  • Backend errors land in the environment of the secret key that sent them.
  • A Host identity verifies only against the secret keys of the environment whose publishable key the SDK presents — a staging server's secret mints nothing production accepts.
  • Source maps upload with any environment's secret key. Artifacts are keyed by release, so a build promoted from staging to production symbolicates against the same maps.

Staging Open, production Invited

  1. Every Project starts with Production

    A new Project has one environment, Production, gated Internal — only your team can report until you widen it. Install it as the Quickstart says; its Install and Keys pages render its keys.

  2. Add a Staging environment

    Open the environment switcher in the Project's rail, choose + Add environment, name it Staging, and pick the Open Gate. It gets its own publishable key immediately, and the page moves to its Install.

  3. Give the staging deploy Staging's keys

    With Staging picked in the switcher, Install, Access and Keys all follow it: the install steps and the agent prompt carry its key. Ship that publishable key in the staging build, and generate a Staging secret key under Keys for the staging server if it runs @fixback/node.

  4. Scope the origins

    On Staging's Access, paste the staging site into Sites and apps; a site added there belongs to that environment. Add the production site the same way on Production's Access. A site marked All environments accepts any environment's key — remove it and add it under the environment it belongs to — so keeping production's site on Production is what keeps Staging's Open key inert there. "Staging is Open" never means anyone can file from production.

  5. Open Production to your testers

    Switch back to Production, and on its Access set Who can report to Invited and send invites under Reporters. Invites belong to the Project, so an invited tester is admitted wherever the Gate is Invited or Open.

In the queue

Every Issue shows its environment's name in the Deploy env row of its properties. Once the Projects in scope carry at least two distinct environment names, the queue gains an All environments picker. It groups by name, so Production spans every in-scope Project's Production. See Issues & triage.

A captured error folds only within its environment: the same crash on staging and on production is two Issues, one in each, each with its own occurrence count and its own Alert.

Renaming and deleting

Rename an environment from the switcher's menu and its Issues relabel with it. Delete, in the same menu, stops its keys at once and removes the origins scoped to it; its Issues stay in the queue, unlabelled. A Project's last environment cannot be deleted — a Project always has somewhere to install. Feedback filed before environments existed carries no label either.