Feature flags let you deploy code and control feature visibility independently — enabling safer rollouts, quick rollback without redeployment, and gradual feature exposure. This guide covers implementing them practically.
What Feature Flags Solve
Without feature flags, deploying code means the new feature is immediately live for everyone — feature flags decouple "code is deployed" from "feature is active," letting you deploy with confidence and control exposure separately, reducing deployment risk.
Simple Feature Flag Implementation (Environment Variable Based)
const FEATURE_NEW_CHECKOUT = process.env.FEATURE_NEW_CHECKOUT === 'true';
if (FEATURE_NEW_CHECKOUT) {
renderNewCheckout();
} else {
renderOldCheckout();
}
The simplest possible approach — toggling via environment variable requires a restart/redeploy to change, but is trivially simple to implement for basic needs.
Database-Backed Feature Flags (Runtime Toggleable)
CREATE TABLE feature_flags (
name VARCHAR(100) PRIMARY KEY,
enabled BOOLEAN DEFAULT FALSE,
rollout_percentage INT DEFAULT 0
);
SELECT enabled FROM feature_flags WHERE name = 'new_checkout';
Allows toggling flags without any deployment/restart — a meaningful capability upgrade over environment-variable-based flags, at the cost of slightly more implementation complexity.
Implementing Percentage-Based Rollout
function isFeatureEnabled(userId, rolloutPercentage) {
const hash = simpleHash(userId) % 100;
return hash < rolloutPercentage;
}
Gradually expose a feature to an increasing percentage of users — using a consistent hash ensures a given user always gets the same experience (not randomly flipping between old/new on each request), important for a coherent user experience during rollout.
Using a Dedicated Feature Flag Service (For More Sophisticated Needs)
Several open-source and commercial feature flag platforms exist, providing targeting rules (specific users, cohorts, geographic regions), analytics on flag usage, and a management UI — worth considering if your feature flag needs grow beyond simple on/off toggles.
Combining Feature Flags with Canary Deployments
See Canary Deployments: Gradually Rolling Out Changes — feature flags and canary deployment are complementary; canary deployment controls which server instances run new code, while feature flags control which users experience new functionality, and they can work together for very fine-grained rollout control.
Cleaning Up Old Feature Flags
Feature flags accumulate technical debt if left indefinitely after a feature is fully rolled out — establish a practice of removing flags (and the old code path they guarded) once a feature is stable and fully rolled out, avoiding an ever-growing tangle of conditional logic.
Using Feature Flags for Quick Incident Response
A feature flag lets you instantly disable a problematic feature without a full rollback/redeployment — valuable during an active incident where a specific new feature is suspected as the cause; see How to Roll Back a Bad Deployment Quickly for the complementary full-rollback approach when a flag-based fix isn't sufficient.
Testing with Feature Flags
Ensure your test suite covers both flag states (on and off) for any feature under active flag control — a feature that's only tested in one state risks a surprise when the flag is toggled in production.
Common Errors
Feature flag check itself has a performance cost at scale — for high-traffic applications, ensure flag evaluation (particularly if checking a database on every request) is appropriately cached, rather than adding a database round-trip to every single request.
Continue Reading
- Canary Deployments: Gradually Rolling Out Changes
- How to Roll Back a Bad Deployment Quickly
- How to Set Up Blue-Green Deployment on a VPS
Browse more articles in DevOps & CI/CD.