Configure flags across environments
Set typed fallbacks and decide where a flag exists at runtime.
A flag definition does not make the flag evaluable everywhere. Each active environment needs its own configuration before FeatureGate can serve a valid value there.
Use configuration presence to decide where a flag exists. Use the fallback and targeting rules to decide what a configured environment serves.
These three layers have different responsibilities:
| Layer | Owns | Used when |
|---|---|---|
| Flag definition | Key, type, lifecycle, tags | Identifying the decision |
| Environment configuration | Fallback, rules, exposure, emergency state | Resolving the flag in one runtime |
| Caller default | Application-safe typed value | FeatureGate cannot resolve a valid value |
A boolean fallback of false is a configured result. Missing configuration means the flag does not
exist in that environment at evaluation time.
From the project Flags page, open Configure fallbacks on a flag row. The dialog shows all active environments and focuses one typed editor at a time.
On flag detail, the environment selector focuses the same configuration beside the targeting workbench and runtime information.
The fallback is returned when no targeting group matches. It should represent the intended broad state for that environment, not an exceptional cohort.
For a temporary release flag, production commonly begins on the known-safe old behaviour. After a successful rollout, make the new behaviour the fallback before deleting rollout rules.
Non-production does not have to mirror production. Development may use the new branch by default while production stays on the existing branch.
Missing configuration is useful when work must not be discoverable in selected environments. It is stronger than an off fallback because there is no resolvable environment value or targeting model.
When configuration is missing:
Do not rely on missing configuration as authorization. The application must still enforce access.
Creating an environment seeds configurations for existing flags. Review those generated defaults before creating credentials or serving traffic.
An all-off fresh environment does not require an operational warning before its first request. After real traffic begins, environment readiness can identify defaults that need deliberate review.
Unconfiguration removes the environment fallback, rules, client exposure, and emergency state. It does not change the flag definition or any other environment.
Before unconfiguring:
Snapshot SDKs can retain their last successful in-memory value until refresh or restart. Do not treat unconfiguration as a remote memory wipe.
Related pages: Flag types and values, Targeting rules, and Environment readiness.