Feature Flag

Updated September 30, 20263 min read

In short

A feature flag is a switch in code that turns a feature on or off at runtime, letting teams deploy code without releasing it to every user at once.

What is a feature flag?

A feature flag, also called a feature toggle, is a conditional check in the code that decides whether a piece of functionality is active. The value of the flag comes from outside the code, such as a configuration file, a database, or a dedicated flag service, so it can change while the application is running. This separates deploying code, which puts it on the servers, from releasing a feature, which makes it visible to users.

At its simplest, a flag is an if statement around the new code path. More advanced systems evaluate flags on every request using targeting rules, for example turning a feature on for internal staff, for users in one country, or for a random 5% of accounts, and increasing that share over time. If the feature causes errors, anyone with access can switch it off in seconds, which is often faster and safer than a rollback.

Teams use flags for gradual rollouts, beta programs, kill switches for risky dependencies, and A/B testing, and flags make trunk-based development practical because unfinished work can be merged to the main branch while hidden behind a flag. Think of a flag like the light switches in a newly wired house: the electrician installs all the wiring in advance, and you decide later which rooms to light up. The main cost is complexity, so old flags should be removed once a feature is fully launched, or they pile up as technical debt.

Feature flags are often confused with canary deployments and environment variables. A canary deployment routes a share of traffic to a new version of the whole application at the infrastructure level, while a feature flag switches individual features inside one running version, often per user. An environment variable is usually read once at startup and is the same for every request, whereas a flag can be changed live and can give different users different answers.

Key takeaways

A feature flag turns functionality on or off at runtime without a new deployment.
It separates deploying code from releasing a feature to users.
Targeting rules can enable a feature for specific users, groups, or a percentage of traffic.
A flag doubles as a kill switch when a new feature misbehaves in production.
Stale flags add complexity and should be removed after a full launch.

Example

Hiding a new checkout flow behind a flagjavascript

// The flag values come from a flag service or config, not from the code
const flags = await loadFlags({ userId: user.id, country: user.country });

if (flags.isEnabled("new-checkout")) {
  renderNewCheckout(cart); // only users the flag targets see this
} else {
  renderLegacyCheckout(cart); // everyone else keeps the current flow
}

Readers ask

What is the difference between a feature flag and a feature branch?

A feature branch keeps unfinished work in a separate Git branch until it is merged. A feature flag lets unfinished code be merged into the main branch and deployed while it stays switched off, which avoids long-lived branches and painful merges.

Are feature flags technical debt?

They become technical debt when they stay in the code after a feature is fully launched. Many teams give each release flag an owner and an expiry date, then delete the flag and the old code path once the rollout is finished.

Can feature flags be used for A/B testing?

Yes. A flag can assign users to different variants of a feature, and an analytics system then compares how each group behaves. A/B testing is one use of feature flags, alongside gradual rollouts, kill switches, and beta access.