What is a feature flag?
It is how a team ships broken code to production on purpose, because nobody has switched it on yet.
Feature flag
feature toggle
A feature flag is a conditional check in the code that decides whether a piece of functionality runs. A setting outside the codebase controls it, not which branch is deployed. Flip the setting and the behaviour changes for chosen users, with no new deploy.
The check is usually one line: if the flag is on, run the new path. If not, run the old one. The interesting part is not the code. It is where the flag's value lives.
A config file, a database row, or a flag service such as LaunchDarkly holds the current state. Changing it takes effect immediately, for whichever users the rule targets. No build, no redeploy, no waiting for a pipeline.
Shipping and releasing become two different acts
Without flags, a deploy and a release are the same event. The code goes out and every user gets it in the same instant, whether it is ready or not.
A flag splits that in two. The code can sit deployed and dark, running in production but reachable by nobody, for days before anyone turns it on. That is the mechanism behind "we deployed Friday and released Monday."
It also changes who controls the release. You can target one internal account, one percent of traffic, or one paying tenant. Your support team can turn a feature off the moment it causes trouble, without waiting for an engineer to write and ship a revert.
- WrapNew code sits behind a flag check.
- DeployShips to production. Flag stays off.
- TargetFlag turns on for one tenant or 5% of users.
- WatchErrors and metrics judge the rollout.
- Widen or killRaise the percentage, or flip it off in seconds.
The kill switch is the point. Reverting a bad release this way takes seconds, not a redeploy.
A feature flag against the things it gets mistaken for
| Criterion | What people reach for | What a feature flag does |
|---|---|---|
| A git branch | Splits code at development time. Merging it back is the risky, manual step. | Splits behaviour at runtime, after the code is already merged and deployed. |
| A canary deployment | Routes a slice of traffic to a new build of the whole service. It works at the infrastructure layer. | Targets one feature inside one version, controlled by an application-level setting. |
| An environment variable set at deploy time | Needs a new deploy to change, same as the code it guards. | Changes instantly, with no deploy, and can target individual users. |
| A config flag for infrastructure settings | Controls things like timeouts or connection pools, usually the same for every user. | Controls product behaviour, usually different per user or per tenant. |
Common questions
01What is the difference between a feature flag and a branch?
A branch splits code before it merges; a feature flag splits behaviour after it has already merged and deployed. Branching defers the risk to a merge that has to happen eventually, often after weeks of drift from the main line. A flag lets the code live in production immediately, merged and current, with the risk controlled by a setting instead of by keeping code unmerged.
02How is a feature flag different from a canary deployment?
A canary deployment routes a slice of traffic to a new build of the whole service, testing everything that changed in that release together. A feature flag works inside one running version and targets a single piece of functionality. A team can test one change at a time instead of a whole deploy at once. The two are often used together: canary the deploy, flag the feature.
03Do feature flags slow down the codebase?
A handful of active flags cost little: one conditional check and a lookup against a config service or database. The cost shows up later, when flags accumulate and nobody removes the ones whose rollout finished. At that point the slowdown is not runtime performance. It is engineers reading code that branches for a decision made a year ago.
04Can a feature flag target specific users or accounts?
Yes, and that targeting is usually the reason a team adopts flags in the first place. Rules can match a percentage of traffic, a specific account, an internal team, or a paying tier. That is what makes a staged rollout to one tenant, then five percent of users, then everyone, possible without three separate deploys.
