# 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.

## Definition, configuration, and caller default

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.

## Configure fallbacks

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.

1. Select the required environment.
2. Initialize its missing configuration when prompted.
3. Enter a value matching the immutable flag type.
4. Review the value and confirm the change.
5. Repeat only for environments that should serve the flag.

On flag detail, the environment selector focuses the same configuration beside the targeting
workbench and runtime information.

## Choose safe fallbacks

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 configurations

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:

- Server evaluation uses the caller default.
- The flag is absent from the environment snapshot.
- Browser evaluation treats it as missing.
- Environment rules and emergency state do not exist.

Do not rely on missing configuration as authorization. The application must still enforce access.

## New environments

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.

## Unconfigure safely

Unconfiguration removes the environment fallback, rules, client exposure, and emergency state. It
does not change the flag definition or any other environment.

Before unconfiguring:

1. Identify every caller bound to the environment.
2. Confirm each caller has an acceptable typed default.
3. Disable or migrate browser use of the flag.
4. Remove rules and operational assumptions that depend on it.
5. Apply the change and watch application telemetry.

Snapshot SDKs can retain their last successful in-memory value until refresh or restart. Do not treat
unconfiguration as a remote memory wipe.

## Troubleshooting

- **The editor rejects a value:** match the immutable flag type.
- **The caller receives its default:** confirm configuration exists in the key-bound environment.
- **A browser cannot see the flag:** enable client exposure and verify allowed origins.
- **A new environment looks unexpectedly on:** review seeded values before traffic.
- **A removed flag still appears locally:** force a successful refresh or restart the process.

Related pages: [Flag types and values](/docs/flags/types-and-values),
[Targeting rules](/docs/flags/targeting-rules), and
[Environment readiness](/docs/operate/environment-readiness).