# Feature flags

> Put a new feature behind a switch you can turn up or down at runtime, so deploying code and releasing it are separate steps.

A feature flag decides at runtime who sees a feature, so you can release without a deploy and undo without a rollback.

## Use it when

- A feature is risky, and you want to show it to 2% of users before everyone.
- You want a kill switch for a dependency or a costly path.
- You deploy often and finish features over several releases.

## How it works

The code ships with the feature off. A flag service answers "is this on for this user?" from a rule, such as a percentage or a list. You turn the share up in steps while you watch errors, then remove the flag when the feature is at 100%. If something breaks, you turn the flag off in seconds and no new build is needed. A bad deploy of a flagged feature reaches only the users who have it.

## What it costs

Every flag is a branch that has to be tested both ways, and old flags pile up as dead code. Flag service downtime needs a safe default. Flags also let teams ship half-built work, so set an owner and a removal date for each one.

## In Quorum



Feature Flags and the CI/CD Pipeline carry no traffic, so this Design has no settings table: the Nodes are the point. Once a Feature has shipped, the Feature Flags Node lets you set its rollout to off, or to one of a few shares of users, and a bad deploy of it reaches only that share. A Feature that is off still pays its upkeep until you remove it. [Feature flags](https://wiki.playquorum.dev/research/feature-flags.md) needs [Continuous delivery](https://wiki.playquorum.dev/research/ci.md). [Graceful degradation](https://wiki.playquorum.dev/patterns/graceful-degradation.md) builds on it. The glossary defines [feature flag](https://wiki.playquorum.dev/glossary/feature-flag.md).

Source: https://wiki.playquorum.dev/patterns/feature-flags