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.
What lives at the environment level
Section titled “What lives at the environment level”- 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.
Default environments
Section titled “Default environments”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.
Archiving environments
Section titled “Archiving environments”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.
Slugs and references
Section titled “Slugs and references”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.
Comments and accountability
Section titled “Comments and accountability”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.
Related
Section titled “Related”- API keys live one tier down from the environment.
- Change requests gate edits per environment.
- Audit log records every change, scoped per environment.