A feature flag is a runtime control that turns functionality on or off without redeploying code, separating deployment from release.
A feature flag wraps new behavior behind a conditional branch evaluated at runtime. Flags can target user segments, percentages, environments, or allowlists. Removing a flag is a separate cleanup step once the feature is fully rolled out.
That separation is why feature flags changed release management. Teams can merge code continuously while keeping incomplete features hidden. They can release to internal users, enable for beta cohorts, or instantly disable failing behavior without a rollback. The risk is flag sprawl: unused flags become hidden technical debt that complicates reasoning about system behavior.
Think of it like this. Think of light switches for individual rooms. You can add new wiring throughout the house and only turn on a room when it is ready. Leaving old switches off indefinitely does not make the wiring disappear.
The application evaluates flag rules from a config service, local JSON, or evaluation SDK. Rules may depend on user attributes, environment, rollout percentage, or explicit allowlists. Flags should have owners, expiration dates, and cleanup policies to prevent permanent branching.
"Flags are free." Every flag adds branching logic, testing matrix growth, and cleanup debt. "Flags only replace releases." They also enable experiments, emergency kill switches, and dark launches. "Any flag system works." Evaluation latency, caching, and auditability matter at scale.
Enables continuous deployment, experiments, and instant rollbacks, but introduces runtime branching and maintenance debt. Best practice is to treat flags as temporary and remove them after full rollout.