Feature Flag Deployment
Deploy code to production with new features hidden behind flags. Enable features gradually per user segment, region, or percentage without redeploying. Disable instantly with kill switches if problems arise.
Flag Types
| Type | Purpose | Typical Lifespan | Example |
|---|---|---|---|
| Release | Control when a feature is visible to users. Decouple deployment from release. | Days to weeks | new-checkout-flow: true/false |
| Experiment | A/B test variants. Route users to different experiences for measurement. | Weeks to months | pricing-page-variant: A / B / C |
| Ops | Operational toggles for load shedding, circuit breaking, maintenance mode. | Permanent | enable-cache-layer: true/false |
| Permission | Gate access to features based on user plan, role, or entitlement. | Permanent | enable-advanced-analytics: plan=enterprise |
Implementation Patterns
Simple boolean toggle
The most basic pattern. Check a boolean flag before executing feature code. Suitable for release flags that will be removed after full rollout.
Percentage-based rollout
Hash the user ID and check if it falls within the target percentage. Ensures consistent experience per user (the same user always sees the same variant) while controlling overall exposure.
User segment targeting
Enable flags based on user attributes: region, plan tier, account age, beta opt-in status. Allows precise control over who sees what.
Multi-variate flags
Return different values (not just true/false) based on context. Used for A/B/C testing, configuration values, and feature variants. The flag returns a string, number, or JSON payload.
Gradual Rollout Percentages
A typical rollout schedule for a release flag. Adjust soak times based on traffic volume and risk tolerance.
| Stage | Target | Percentage | Duration |
|---|---|---|---|
| Internal | Team members only | ~0.1% | 1-2 days |
| Beta | Beta opt-in users | 1-5% | 2-5 days |
| Early rollout | Random user sample | 10-25% | 3-7 days |
| Broad rollout | Majority of users | 50-75% | 3-7 days |
| General availability | All users | 100% | Remove flag after stabilization |
Kill Switches
A kill switch is a feature flag designed specifically for emergency disabling. It provides instant rollback without a deployment.
- Flag evaluation must be fast. SDK should cache flag values locally and update asynchronously. Kill switch latency should be under 50ms.
- Default to safe state. If the flag service is unreachable, the SDK should default to the safe value (feature off for new features, feature on for established features).
- Propagation time matters. After toggling a kill switch, all application instances must reflect the change. SSE/WebSocket-based SDKs propagate in seconds. Polling-based SDKs depend on poll interval (10-60 seconds typical).
Provider Comparison
| Provider | Hosting | SDK Languages | Free Tier | Key Differentiator |
|---|---|---|---|---|
| LaunchDarkly | SaaS | 25+ (broadest coverage) | Limited (trial) | Enterprise-grade targeting, experimentation, governance. Largest ecosystem. |
| Unleash | Self-hosted or SaaS | 15+ (all major languages) | Open-source (self-hosted) | Open-source core. Full control when self-hosted. Strong community. |
| Flagsmith | Self-hosted or SaaS | 12+ SDKs | Open-source (self-hosted), SaaS free tier available | Remote config + feature flags combined. Edge proxy for low latency. |
| ConfigCat | SaaS | 16+ SDKs | Free tier (10 flags, 2 envs) | Simple setup, CDN-backed evaluation, good for smaller teams. |