Shipping code and releasing a feature used to be the same event. You merged, you deployed, and every user saw the change at once. If something broke, the only way out was a rollback or a hotfix under pressure.
Feature flags break that link. They let you deploy code to production while keeping it switched off, then turn it on for a small group, a region, or everyone, without another deployment. This guide explains how feature flags work, the different types, the tools teams use, and the habits that keep flags from turning into technical debt.
What Is a Feature Flag?
A feature flag (also called a feature toggle or feature switch) is a conditional in your code whose value is decided at runtime instead of at build time. In its simplest form, the application asks a question like "is the new checkout enabled for this user?" If the answer is yes, it shows the new checkout; if not, it shows the old one.
The answer to that question comes from a configuration source such as a database, a config file, or a flag management service. Changing that value changes behaviour in production immediately, with no rebuild and no redeploy.
Why Feature Flags Matter in DevOps
DevOps teams aim for small, frequent, low-risk changes. Feature flags support that goal in several ways:
- Deployment is separated from release. Engineers can merge unfinished work to the main branch behind a disabled flag, which makes trunk-based development practical.
- Instant kill switch. If a new feature causes errors, you turn the flag off in seconds instead of waiting for a rollback pipeline.
- Progressive rollout. You can expose a feature to 1% of users, watch your metrics, then move to 10%, 50% and 100%.
- Experimentation. Flags power A/B tests by serving different variants to different user groups.
- Targeted access. Beta customers, internal staff, or a single region can see a feature before everyone else.
The Four Main Types of Feature Flags
Not all flags have the same purpose or lifespan. Treating them differently is the key to managing them well.
1. Release Flags
Release flags hide incomplete or untested features. They are short-lived and should be removed within days or weeks of the feature reaching 100% of users.
2. Experiment Flags
Experiment flags split users into cohorts to compare variants, for example two pricing page layouts. They live as long as the experiment runs and need consistent user bucketing so a user always sees the same variant.
3. Ops Flags
Ops flags control operational behaviour, such as disabling an expensive recommendation engine during a traffic spike. Some of these act as permanent circuit breakers and may stay in the codebase for a long time.
4. Permission Flags
Permission flags turn features on for specific customers or plans, such as premium features or early-access programmes. These are often long-lived and closely tied to business logic.
How Feature Flags Work Under the Hood
A feature flag system has three main parts:
- Flag definitions stored centrally, including the flag key, its variations (on/off, or several values), and targeting rules.
- An SDK in your application that evaluates flags. Most SDKs cache the rules locally and evaluate in memory, so a flag check takes microseconds and does not add a network call to every request.
- A control plane, usually a web dashboard or API, where engineers and product managers change rules and see an audit log.
Targeting rules commonly use attributes like user ID, email domain, country, app version, or account plan. Percentage rollouts hash a stable identifier (for example the user ID) so the same user consistently lands in the same bucket.
Feature Flags vs Canary and Blue-Green Deployments
Canary and blue-green deployments control traffic at the infrastructure level: which servers or pods receive requests. Feature flags control behaviour at the code level: which users see which code path. They complement each other. (New to the concept? Read what is blue-green deployment.) A common pattern is to roll out a new version with a canary deployment to confirm it is stable, then use flags to gradually release the new features inside that version.
Popular Feature Flag Tools
- LaunchDarkly – a widely used commercial platform with strong targeting, experimentation and audit features.
- Unleash – open source with a self-hosted option, popular with teams that want control over their data.
- Flagsmith – open source with a hosted service, supports remote config as well as flags.
- Split – focuses on tying flags to measurement and experimentation.
- AWS AppConfig and Azure App Configuration – cloud-native options with built-in feature flag support.
- OpenFeature – a CNCF project that provides a vendor-neutral API, so you can switch flag providers without rewriting application code.
Small teams sometimes start with a simple config file or environment variables. That works for a handful of flags but quickly becomes hard to manage once you need percentage rollouts, audit logs, or non-engineers changing flags.
Using Feature Flags in a CI/CD Pipeline
Feature flags fit naturally into a CI/CD pipeline. If you are setting one up, see how to build a CI/CD pipeline from scratch. A typical flag workflow looks like this:
- A developer creates the flag (default off) before writing the feature.
- Code is merged to main behind the flag and deployed through the normal pipeline.
- Automated tests run with the flag both on and off, so both paths stay working.
- The flag is enabled for internal users in production, then rolled out progressively while dashboards track error rates and latency (see DevOps metrics that actually matter).
- Once the feature is at 100% and stable, a cleanup ticket removes the flag and the old code path.
Best Practices for Managing Feature Flags
Give every flag an owner and an expiry
Record who created the flag, why, and when it should be removed. Many tools support tags or expiry dates and can warn you about stale flags.
Use clear naming conventions
A name like "release-checkout-v2" or "ops-disable-recommendations" tells everyone the flag type and purpose at a glance.
Keep flag checks at the edges
Evaluate a flag once near the entry point of a feature rather than scattering the same check across dozens of files. This makes removal easier.
Have a safe default
If the flag service is unreachable, the SDK should fall back to a safe default, usually the old behaviour.
Restrict and audit changes
Changing a flag in production is effectively a production change. Use role-based access, require approvals for sensitive flags, and keep an audit trail.
Pay down flag debt
Old flags make code harder to read and test, because every flag doubles the number of possible paths. Schedule regular cleanup and treat stale flags like any other technical debt.
Common Mistakes to Avoid
- Leaving release flags in the code for months after a full rollout.
- Reusing an old flag name for a new feature, which can switch on unexpected code.
- Putting secrets or sensitive logic in client-side flags that users can inspect.
- Testing only the "on" path and letting the fallback path break.
- Letting flags become an undocumented way of configuring the whole system.
Conclusion
Feature flags give DevOps teams control over who sees what and when, without tying every release to a deployment. Used with discipline – clear ownership, short lifespans for release flags, and regular cleanup – they reduce release risk, improve your CI/CD practices, enable trunk-based development, and make experimentation part of everyday delivery. Start with one high-risk feature, wire it behind a flag, and build the habit from there.
