How to Set Up Feature Flags in LaunchDarkly
Deploying code and releasing a feature to users are two different events, and conflating them is one of the most common sources of product risk. Feature flags let you deploy code to production at any time while controlling exactly who sees the new behavior and when. For PMs, this means you can ship incrementally, run percentage rollouts, and kill a broken feature in seconds without waiting for an engineering rollback.
LaunchDarkly is the most widely adopted feature flag platform, but setting it up well requires more than just wrapping code in if-else blocks. This guide covers the PM-relevant setup: organizing flags by project and environment, defining targeting rules that match your rollout plan, and establishing the flag lifecycle so your codebase does not accumulate thousands of stale flags over time.
Step-by-step guide
Set up your LaunchDarkly project and environments
Create a project in LaunchDarkly that maps to your product or service. Within the project, create environments matching your deployment pipeline: typically Development, Staging, and Production. Each environment gets its own SDK key, so flags can behave differently per environment without code changes. Keep the naming consistent with your CI/CD environments to avoid confusion.
- Create a project named after your product or service
- Add Development, Staging, and Production environments
- Note each environment's SDK key for your engineering team
Define your flag naming convention
Establish a naming convention before creating your first flag. A common pattern is team.feature.variant, such as growth.onboarding-v2.enabled. Consistent naming makes flags searchable, filterable, and auditable. Add tags for the team owner and the release quarter so you can find and clean up flags later. Document the convention in your team's wiki and enforce it during code review.
- Choose a naming pattern like team.feature.variant
- Define required tags: team owner, target release quarter, flag type (release/experiment/ops)
- Document the convention and add it to your code review checklist
Create your first feature flag
In the LaunchDarkly dashboard, click Create Flag. Give it a name following your convention, add a description that explains what the flag controls in user-facing terms, and select the flag type (boolean for simple on/off, multivariate for A/B tests). Set the default variation to off in Production and on in Development so engineers can work against the new code locally without affecting real users.
- Create a boolean flag with a descriptive name and explanation
- Set default to off in Production, on in Development
- Add tags for team, quarter, and flag type
Configure targeting rules for rollout
In the flag's targeting tab, build rules that match your rollout plan. Start with individual user targeting to enable the flag for internal testers by email or user ID. Then add a percentage rollout rule starting at 5-10% of your production traffic. LaunchDarkly's percentage rollout uses consistent hashing so a user who sees the feature on one visit continues to see it on subsequent visits. Increase the percentage as you gain confidence.
- Add individual targets for your internal QA and PM accounts
- Create a percentage rollout rule starting at 5-10%
- Optionally add segment-based targeting for beta users or specific customer tiers
Integrate the SDK in your application code
Work with your engineering team to add the LaunchDarkly SDK to your application. The SDK evaluates flags locally using a streaming connection to LaunchDarkly's servers, so flag checks are fast (sub-millisecond) and do not add latency. Ensure the SDK is initialized with the user context (user ID, email, custom attributes) so targeting rules work correctly. Add a fallback value for every flag evaluation in case the SDK cannot reach LaunchDarkly.
- Install the appropriate SDK for your tech stack (React, Node, Python, etc.)
- Initialize with user context including ID and relevant attributes
- Always specify a fallback value for every flag.variation() call
Set up flag lifecycle management
Every flag should have a planned end state. In LaunchDarkly, use the flag's settings to mark it as temporary (with a planned removal date) or permanent (for long-lived operational flags). Create a monthly review process where you filter flags by age and status, identify those that are fully rolled out, and create tickets to remove them from code. Stale flags are technical debt that compounds silently.
- Mark each flag as temporary or permanent at creation time
- Set a planned removal date for temporary flags
- Schedule a monthly flag cleanup review with engineering
Common mistakes
Creating flags without a removal plan
Teams accumulate hundreds of flags because no one owns cleanup. Every flag that stays in code after full rollout is a conditional branch that engineers must reason about when debugging. Set a removal date at creation time and treat flag cleanup tickets as real work, not backlog filler.
Using flags for permanent configuration
Feature flags are for temporary rollout control, not for app configuration. If you need a setting that will always exist (like a rate limit or pricing threshold), use a proper configuration system. Flags used as config never get cleaned up and bloat your LaunchDarkly bill.
Not passing sufficient user context to the SDK
If you initialize the SDK without user attributes, your targeting rules will not work. You will end up with a flag that can only be toggled globally (on/off for everyone), losing the per-segment and percentage rollout capability that makes flags valuable. Ensure user ID, plan tier, and any segmentation attributes are passed at initialization.
Testing flags only in development environment
Flags often behave differently in production due to caching, CDN behavior, and real user attributes versus test fixtures. Always verify flag behavior in your staging environment with production-like data before rolling out to real users.
Tips
Use LaunchDarkly's audit log to create a paper trail of who changed which flag and when, which is invaluable for incident response
Create a 'kill switch' segment containing your incident response team so critical flags can be toggled instantly during an outage
Set up LaunchDarkly's Slack integration to post flag changes to a dedicated channel so PMs and engineers have shared visibility
Use flag prerequisites to chain dependent flags so enabling feature B automatically requires feature A to be on
How Vantage helps
Vantage generates implementation tickets that account for your flag strategy. When you define a phased rollout in your PRD, Vantage creates separate tickets for flag creation, SDK integration, targeting configuration, and flag cleanup, each with the right dependencies. This prevents the common failure mode where the flag cleanup ticket never gets written because the PM forgot by the time the feature shipped.