Skip to content

Environments

An environment is a deployment stage within a project. It owns the state of every flag in that project, plus its own SDK keys and its own audit history.

The same flag, in the same project, can be:

  • On for 100% of users in development,
  • On for your internal team in staging,
  • Off in production,

all at once. Editing the flag in one environment never touches the others.

  • Targeting on/off for every flag.
  • The off-variation and the default rule for every flag.
  • Targeting rules and individual targets for every flag.
  • SDK keys: server, mobile, and the client-side ID.
  • Approval settings (whether changes require review, how many reviewers).
  • The “require comments” setting that forces a reason on every flag edit.
  • Scheduled changes, change requests, workflows, progressive rollouts.

What does not live at the environment level

Section titled “What does not live at the environment level”

The flag’s definition: key, value type, variations, description. Those are shared across every environment in the project. Change them in one place and every environment sees the new shape immediately.

Every project starts with a production environment. Most teams add development and staging next. There is no hard limit on how many environments you can create; per-engineer and per-region environments are common.

Archive an environment when you no longer need it but want to preserve its audit history (a sunset region, a retired CI environment). Archived environments are read-only and excluded from the dashboard’s default view. SDKs using an archived environment’s keys will still receive a datafile until you revoke the keys.

You cannot archive the last environment in a project.

Each environment has a slug (production, staging, dev-alice) that shows up in URLs and the API. Slugs are unique within the project. The environment’s identity is its UUID; renaming it changes the slug but not the ID, and SDK keys keep working.

Turn on require comments for an environment (typically production) to force every flag edit and approval to include a free-text reason. The reason is stored on the audit log entry. Use this when compliance or post-incident review matters.