/Docs
IntroductionHow FeatureGate worksQuickstart
OrganisationsProjectsEnvironments
OverviewTypes and valuesConfigure across environmentsTargeting rulesPercentage rolloutsDesign evaluation contextLifecycle and intentTags and discovery
Choose an evaluation approachEvaluation credentialsNode.js SDKEvaluate over HTTPEvaluate in browsersSnapshots and configuration freshnessErrors and fallbacksTest flags locallyProduction integration checklist
Run a controlled rolloutKill switchesProject insightsActivity and audit historyReview and clean up flagsEnvironment readinessTroubleshooting and limits
Members, roles, and permissionsInvite and manage a teamOrganisation settings and operational defaultsProject lifecycle and transferPlans, billing, and team organisationsOrganisation closure and reactivationAccount settings and security
Management API overviewPreviewProvision flags through automationPreviewRotate runtime keys through automationPreviewAudit project changes through automationPreview
DocsAPI Reference

Platform/Environments

Get access
/Docs
Get access
  1. Docs
  2. Platform
  3. Environments

Environments

Model runtime boundaries, configuration readiness, and environment lifecycle.

MarkdownFeedback
PreviousProjectsNextFlags overview

On this page

Design the environment setConfiguration and readinessManage keys and configurationArchive and deleteDiagnose environment problems

An environment is a runtime boundary inside one project. Flags have independent fallbacks, rules, client exposure, and emergency state in each environment. Evaluation keys bind to one environment.

Use environments for deployed boundaries that need independent values and credentials. Do not use them as a promotion queue, release checklist, or substitute for deployment automation.

Design the environment set

development, staging, and production are useful defaults when they match real runtime stages. Create custom environments only when they correspond to another durable runtime boundary.

ModelUse it whenAvoid it when
Standard environmentsThe application has development, staging, and productionThose names do not map to real runtimes
Regional environmentRegions are deployed and operated independentlyRegion is only a targeting attribute
Preview environmentIt is a durable runtime with owned credentialsA short-lived branch can use bootstrap data

FeatureGate does not copy configuration from staging to production. Apply each production change deliberately so a non-production experiment cannot become production configuration accidentally.

Environment keys are immutable because credentials, audit events, and URLs depend on them. Use a stable machine key and reserve the display name for wording that may change.

Configuration and readiness

Creating an environment seeds configurations for existing flags. Review the generated values before traffic. A ready environment progresses through these states:

  1. Create or restore the environment.
  2. Ensure at least one active flag exists.
  3. Review the fallbacks seeded for the environment.
  4. Create a server runtime key with the required scopes.
  5. Send the first hosted request.
  6. Review default warnings after real traffic.

An all-off fresh environment is not automatically risky before it serves traffic. After the first hosted request, fallback review becomes operationally relevant.

Client keys add two requirements: allowed origins and explicit client exposure on each flag. A client key does not make every environment flag browser-readable.

Manage keys and configuration

Open the project Environments page and select an environment by its URL path. Create, list, and revoke runtime keys from that boundary. Raw secrets are shown once and cannot be recovered.

Missing configurations can occur after deliberate unconfiguration. A configured boolean false differs from a missing configuration: false is a valid result and may still be overridden by rules.

Archive and delete

Archive is reversible and prevents new normal use while preserving history. Restore the environment before creating keys or changing active configuration.

Permanent deletion is available only after archive. Before deletion, replace callers, confirm safe caller defaults, and allow snapshot clients to refresh or shut down.

A running SDK may retain its last successful in-memory snapshot until refresh, restart, or shutdown. An environment lifecycle change is not a remote memory wipe.

Diagnose environment problems

  • No flags: create a flag after confirming the environment is active.
  • Missing defaults: configure every required flag with the correct type.
  • No runtime key: create one and store its one-time secret immediately.
  • No first request: send a hosted evaluation or snapshot request with the bound key.
  • Review defaults: inspect fallbacks after hosted traffic establishes relevance.
  • Stale value: wait for a successful refresh or call refresh().

Related pages: Evaluation credentials, Environment readiness, and Configure flags across environments.