When to use feature flags

When you create a feature flag in LaunchDarkly, you create a decision point that changes an application’s behavior at runtime. Flags are a simple but powerful primitive that applies to many use cases. This page helps you decide whether a use case is a good fit for a feature flag.

Three questions to ask

Most good use cases fall into one of three buckets: dynamic, contextual, or delegated. If you answer “yes” to one or more of these questions, a flag is likely the right tool.

Dynamic

Ask: does this need to change at runtime?

Deploys are the slowest, riskiest way to change behavior. A flag lets you flip a decision in seconds, without a rebuild, a rollout, or a rollback. Use it in the middle of an incident, during a launch window, or in response to a customer issue. Scheduled and time-bound changes fit here too, because the mechanism is the same and only the timing is automated.

Good fits include:

• Release of new features or behavior
• Circuit breakers around flaky dependencies or expensive operations
• Rate limits and throttles tuned in response to load
• Operational toggles such as maintenance mode or read-only mode
• Scheduled launches that enable behavior at a set time
• Auto-expiring targeting such as internal access for 30 days
• Coordinated releases across services

Contextual

Ask: does this depend on who, where, or what?

Flag rules evaluate against a context, so the same line of code behaves differently for different users, tenants, regions, requests, or deployments. This is what makes flags different from an if statement on an environment variable.

Good fits include:

• Per-user or per-tenant entitlements and beta access
• Per-request routing such as A/B tests, shadow traffic, and canaries
• Per-deployment behavior distinguished by a runtime context attribute, such as blue/green or region-specific rollouts
• Progressive rollouts by percentage, cohort, or attribute

Delegated

Ask: does someone else need to control this?

A feature flag delegates control of behavior to any person or system without code changes. When you add a flag to a decision point, you gain:

• Control through the UI and API
• A full audit log and change history
• Governance with right-sized access control policies and approval workflows

Good fits include:

• Ops and on-call toggling a circuit breaker during an incident
• Support enabling a workaround for a specific customer
• Product turning on a feature for a launch partner
• Automation through triggers and the API, reacting to monitoring or business events

When not to use feature flags

Every flag has an ongoing cost: evaluation calls, a cleanup task, and one more piece of behavior someone must understand when reading the code. Skip the flag when one of these cases applies.

Handling secrets or credentials

Secrets create two distinct problems with the same answer: use a secrets manager.

• Storing secrets in flag values. Flag payloads deliver to every SDK that requests them and appear in analytics events. Anything in a variation is effectively public to your client fleet.
• Targeting on secrets or credentials. Attributes you target on travel with every evaluation event. A raw token or password in a context attribute is a leak waiting to happen. Hash it, or target on a derived claim instead.

Replacing configuration management

If a value never changes at runtime, it is configuration, not a flag. A good test is whether the application would fail to start without it. Database hostnames, API base URLs, and region identifiers belong in configuration. Flipping them with a flag means your app cannot boot until LaunchDarkly responds.

Flags can augment configuration by overriding a default or rolling out a new value gradually. They should not be the source of truth for values that gate startup.

Serving as a content management system or data store

Flags are a control plane, not a database. Variations ship in the SDK payload and count against evaluation and network budgets. Keep flag payloads lean:

• Keep variations small, such as a boolean, a string, or a short enum.
• Avoid large or deeply nested JSON. If the dynamic part is one field, make that one field the flag.
• Do not treat flags as a source of truth for data that belongs in a database, a CMS, or a config service.

Every minor code change

Not every commit or trivial change needs a flag. The overhead of flag creation, testing both paths, and cleanup outweighs the benefit for small, low-risk changes. Flag features as a whole, not individual lines of code. Reserve flags for:

• Significant features
• Experiments
• High-risk changes
• Operational controls such as kill switches

Next steps

After you confirm your use case is a good fit, determine how many flags you need.