Feature flags (also called feature toggles) are one of the most powerful techniques in continuous delivery — they let you merge code to main and deploy it to production without actually turning the feature on for users. That separation between deployment and release unlocks percentage rollouts, A/B experiments, instant rollbacks, and per-customer feature gating. In 2026, feature flags are a standard part of the deployment toolkit for any team shipping frequently.
What changed in 2026
- Flags are integrated into CI/CD pipelines. GitHub Actions and GitLab CI pipelines now commonly check flag state as a deployment gate — a flag must be healthy before the pipeline progresses.
- Statsig and Growthbook gained ground against LaunchDarkly on price and open-source availability, giving smaller teams access to enterprise-grade flag infrastructure.
- SDK performance improved dramatically. Modern flag SDKs stream flag state locally, evaluating flags in microseconds from in-process memory rather than making network calls on each request.
- LLM-powered flag analysis. Teams use Claude/GPT-class models to audit stale flags across large codebases and generate cleanup PRs automatically.
Types of feature flags
| Type |
Purpose |
Lifespan |
| Release toggle |
Gate new features during deployment |
Days to weeks |
| Experiment toggle |
A/B or multivariate testing |
Duration of experiment |
| Ops toggle |
Kill switch for risky subsystems |
Permanent |
| Permission toggle |
Feature gating per user/plan tier |
Long-lived |
| Infrastructure toggle |
Switch between implementations |
Short to medium |
Basic implementation
// Simple boolean flag with LaunchDarkly Node.js SDK
import { LDClient } from "@launchdarkly/node-server-sdk";
const flagKey = "new-checkout-flow";
const user = { key: userId, email: userEmail, plan: "pro" };
const showNewCheckout = await ldClient.variation(flagKey, user, false);
if (showNewCheckout) {
return renderNewCheckout(cart);
} else {
return renderLegacyCheckout(cart);
}
The false at the end is the default — what the SDK returns if the flag service is unreachable. Always define a safe default.
Percentage rollout pattern
// Gradual rollout: start at 1%, increase to 5%, 25%, 100%
const rolloutConfig = {
"new-payment-processor": {
enabled: true,
percentage: 5, // 5% of users
targeting: [
{ attribute: "plan", operator: "in", values: ["pro", "enterprise"] }
]
}
};
With a managed service, you change the percentage in the dashboard — no code change, no deploy.
Flag lifecycle management
1. Create — flag defined with a clear owner, description, and expiry date.
2. Development — flag off in production, on in dev/staging.
3. Staged rollout — 1 % → 10 % → 50 % → 100 %, monitoring error rates and latency at each step.
4. Full release — flag at 100 %, behavior validated.
5. Cleanup — remove the flag check from code, delete the flag from the service. This step is critical and frequently skipped.
# Find stale flags older than 90 days (example audit script)
grep -r "ldClient.variation" src/ | grep -oP '"[^"]+flag[^"]*"' | sort | uniq
# Compare against flags last modified >90 days ago in LaunchDarkly API
Managed services compared
| Service |
Pricing model |
Open-source option |
Notable feature |
| LaunchDarkly |
Per seat |
No |
Mature SDKs, audit logs |
| Statsig |
Per event/user |
No |
Built-in experimentation |
| Growthbook |
Per seat or self-host |
Yes (MIT) |
A/B stats engine |
| Unleash |
Per seat or self-host |
Yes (Apache 2) |
Simple, Kubernetes-native |
| Flagsmith |
Per seat or self-host |
Yes (BSD-3) |
Remote config + flags |
For small teams on a budget, Unleash or Growthbook self-hosted on a small VM costs ~$10/month in infra vs ~$200–500/month for managed LaunchDarkly at modest scale.
How to pick
- Small team, tight budget? Start with Unleash (open-source, self-hosted) or a simple database-backed flag table.
- Need A/B experimentation with stats? Statsig or Growthbook handle experiment design, assignment, and p-value calculation built in.
- Enterprise compliance, audit trails? LaunchDarkly is the most mature with SSO, role-based access, and detailed audit logs.
- Kubernetes-native deployment? Unleash has Helm charts and Kubernetes operator support.
- Already using Vercel/Edge? Vercel Edge Config provides ultra-low-latency flag reads at the edge without a full flag service.
Common mistakes
Not defining a safe default. If the flag service is down, variation(key, user, undefined) can cause NullPointerException or unexpected behavior. Always pass an explicit, safe default.
Flag explosion. Teams that never clean up flags end up with hundreds of stale toggles. Set expiry dates and review quarterly.
Testing only the "on" path. Both branches of a flag must be tested. CI should run tests with the flag forced both on and off.
Nesting flags. Flag A inside Flag B creates combinatorial explosion. Keep flags orthogonal.
What to skip
- Feature flags for permanent config — max connection pool size, timeout values, and feature pricing belong in configuration files or environment variables, not feature flags.
- Client-side-only flags for security-sensitive features — always enforce on the server; client-side flag state can be manipulated.
- Manual percentage changes without monitoring — always attach error rate and latency dashboards before increasing rollout percentage.
FAQ
Can feature flags replace blue-green deployments?
They complement each other. Blue-green switches infrastructure; flags switch application behavior. Many teams use both: blue-green for zero-downtime infra changes, flags for feature rollouts.
How do feature flags affect database migrations?
Use expand-contract migrations: first deploy the schema addition (backward-compatible), then enable the flag, then later remove the old code path, then clean up the schema.
Are feature flags a testing anti-pattern?
Only if overused. Short-lived release flags are fine. The risk is flags that stay in code permanently, creating dead code branches. Enforce cleanup policies.
What is a kill switch?
An ops toggle set to "on by default" that you flip to "off" to disable a problematic feature instantly — no deploy needed. Essential for payment processors, third-party integrations, and anything that can cascade.
Where to go next