# Feature flag
A **feature flag** (also called a feature toggle or feature switch) is a conditional in the code that enables or disables a feature at runtime without deploying new code. The feature is deployed but dark; it is activated by changing a configuration value, not by a release.

```c
// flag read from config or a remote service
if (config_get_bool("new_checkout_flow")) {
    render_new_checkout();
} else {
    render_old_checkout();
}
```

## Uses

**Progressive rollout**: enable the feature for 1% of users, watch metrics, increase to 10%, then 50%, then 100%. This is similar to a [[canary-release]] but controlled at the application level rather than the infrastructure level.

**Kill switch**: if a new feature causes problems in production, disable it instantly by flipping a flag, without rolling back a deployment. This reduces the risk of each release.

**Trunk-based development**: merge an incomplete feature to main but keep it behind a flag that is off. The code is integrated continuously ([[ci-cd]]) without the incomplete feature being visible to users. When it is ready, flip the flag.

**A/B testing**: send different feature configurations to different user cohorts and measure the effect on metrics. See also [[ab-testing]].

## Debt and cleanup

Feature flags accumulate. A flag that was added for a rollout and was never removed is dead code that makes the system harder to reason about. Old flags also interact: `if flagA && !flagB` conditions become exponentially hard to test. Teams that use feature flags need a hygiene practice of removing flags once a rollout is complete.