Tools tagged "feature-flags" let teams turn features on or off, or roll them out gradually, without deploying new code. A feature flag wraps a piece of functionality in a conditional check against a flag service, so a team can enable a feature for internal testers, a percentage of users, or a specific customer segment, and roll it back instantly if something breaks.
Common use cases include gradual rollouts (releasing to 5% of users, then increasing), A/B testing and experimentation tied to flag variants, kill switches for quickly disabling a broken feature in production without a redeploy, trunk-based development where unfinished code ships behind a flag rather than sitting in a long-lived branch, and per-customer feature entitlement in B2B products (this plan gets this feature). Some tools focus narrowly on boolean on/off flags, others extend into full experimentation platforms with statistical analysis of variant performance.
When choosing one, check targeting rule flexibility (percentage rollouts, user attributes, segments), SDK support for your languages and frameworks, evaluation latency (flags are checked on every relevant request, so a slow flag service adds latency everywhere), whether flag state changes propagate in real time or require a cache refresh, and audit logging for who changed which flag and when, since flags directly control production behavior. Self-hosted flag services also need to be resilient: a flag service outage should not take down the features it is supposed to control.
Self-hosted feature flag tools typically replace LaunchDarkly, Split, and Optimizely's feature flag product. Teams self-host to avoid per-seat or per-flag pricing that gets expensive as usage grows, and to keep flag evaluation latency low by running the service close to the application rather than over the network to a third party.