What Are Feature Flags?

Feature flags let you change what your application does at runtime, without deploying new code. They act as decision points in your codebase that you control from a dashboard or API.

What are feature flags?

A feature flag is a conditional wrapper around functionality. In code, it looks something like this:

if (featureflip.boolVariation("new-checkout", user, false)) {
  showNewCheckout();
} else {
  showOldCheckout();
}

The flag’s value is determined by configuration on the Featureflip server, not by your application code. You can change which variation is served to users instantly, without redeploying.

Feature flags are sometimes called feature toggles, feature switches, or feature gates. They all refer to the same concept.

Why use feature flags?

Safe rollouts. Release a feature to 5% of users first. If metrics look good, increase to 25%, then 50%, then 100%. If something breaks, roll back to 0% instantly.

Kill switches. Wrap risky or resource-heavy features in a flag. If a feature causes problems in production, disable it in seconds rather than reverting a deployment.

Trunk-based development. Merge incomplete features into your main branch behind a flag. The code ships but the feature stays hidden until it is ready. No more long-lived feature branches.

A/B testing. Serve different variations to different groups of users and measure which performs better.

Targeted access. Give beta users, internal teams, or enterprise customers early access to features while keeping them hidden from everyone else.

Flag types in Featureflip

Featureflip supports four flag types:

Type	Values	Example use
Boolean	true or false	Toggle a feature on or off
String	Any text value	Select a theme: "blue", "green", "red"
Number	Any numeric value	Set a rate limit: 100, 500, 1000
JSON	Structured data	Pass configuration: {"maxItems": 10, "layout": "grid"}

Boolean flags are the most common. Use string, number, or JSON flags when you need to control more than just on/off behavior.

Variations

Every flag has a set of variations — the possible values it can return. A boolean flag always has exactly two variations: true and false. Other flag types can have as many variations as you need.

For example, a string flag called checkout-button-color might have three variations:

• "blue" (the current design)
• "green" (a new design being tested)
• "red" (another candidate)

Targeting rules and rollout strategies determine which variation each user receives. See Targeting & Segments and Rollout Strategies for details.

Flag lifecycle

A typical flag goes through these stages:

1. Create — Define the flag with its type and variations in the Featureflip dashboard or via the API.
2. Configure targeting — Set up rules to control who gets which variation.
3. Enable in development — Turn the flag on in your dev environment and verify behavior.
4. Test — Validate in staging or QA with broader access.
5. Enable in production — Roll out to real users, often starting with a small percentage.
6. Monitor — Watch metrics and error rates to confirm the feature is working.
7. Archive — Once the feature is fully rolled out and stable, remove the flag from your code.
8. Delete — Clean up the flag from Featureflip.

Flags that live too long become technical debt. Plan to remove them once they have served their purpose.

For a step-by-step walkthrough, see How to Create Feature Flags.

Off variation vs. default variation

These two concepts are easy to confuse:

Off variation. When a flag is disabled (toggled off), the off variation is served to all users. For boolean flags, this is false. No targeting rules are evaluated.

Default (fallthrough) variation. When a flag is enabled but a user does not match any targeting rules, the fallthrough variation is served. This is the “catch-all” for users who are not specifically targeted.

Here is the evaluation flow:

1. Is the flag enabled? No — serve the off variation. Stop.
2. Is the flag enabled? Yes — evaluate targeting rules top to bottom.
3. Does a rule match? Yes — serve that rule’s variation. Stop.
4. No rules matched — serve the fallthrough (default) variation.

This distinction gives you precise control: you can target specific users with rules, define a default experience for everyone else, and still have a quick way to shut the feature off entirely.

Next steps

• How to Create Feature Flags — step-by-step guide to creating flags in the dashboard
• Environments — manage separate configurations for dev, staging, and production
• Targeting & Segments — control which users see which variation
• SDK Overview — choose the right SDK for your platform and get started

Frequently Asked Questions

What is the difference between feature flags and feature toggles?

Feature flags and feature toggles are the same concept — different names for the ability to turn features on or off without deploying new code. The term “feature flag” is more widely used today, popularized by continuous delivery practitioners, while “feature toggle” comes from the older trunk-based development community. You may also hear “feature switch” or “feature gate” — all refer to the same pattern. The distinction that actually matters is not the name but the type: release toggles (short-lived, for deployment decoupling), experiment toggles (for A/B testing), ops toggles (kill switches for risky behavior), and permission toggles for controlling user-tier access. Featureflip supports all of these use cases through a single flag abstraction with boolean, string, number, and JSON flag types. Whether your team calls them flags or toggles, the workflow is the same: wrap functionality in a conditional, configure the value remotely, and change behavior without touching code or redeploying.

When should I use feature flags?

Use feature flags when you want to decouple deployment from release — ship code to production before it is visible to users. This is the foundation of trunk-based development: merge incomplete features behind a flag so your team avoids long-lived branches. Use flags for gradual rollouts, starting at 5% of users and expanding as metrics confirm stability. Use them as kill switches for any feature that could degrade performance or trigger errors — you can disable it in seconds, no deployment required. Run A/B experiments by serving different variations to different user groups and measuring which performs better. Grant early access to beta users, internal teams, or enterprise customers while keeping features hidden from the general population. If you are shipping software to production more than once a week, feature flags should be a standard part of your workflow. Featureflip supports all of these patterns out of the box.

Are feature flags a security risk?

Feature flags themselves are not a security risk, but there are important principles to follow. Never use feature flags as a substitute for proper server-side authorization. A flag controls whether a feature is visible or active — it does not restrict access at the data or API level. Sensitive operations should always have permission checks independent of any flag state. On the configuration side, treat SDK keys like API keys: store them in environment variables or a secrets manager, never in source code. Featureflip uses separate SDK keys per environment, limiting the blast radius if a key is exposed. Flag configurations are not user-facing secrets, but you should still rotate keys if one is compromised. The bigger risk with feature flags is operational: flags that are never cleaned up become invisible branches in your code. Audit and archive flags regularly to keep your codebase understandable and your attack surface small.

Do feature flags slow down my application?

With Featureflip, flag evaluation is designed for minimal latency. Server-side SDKs — for Node, Python, Go, Java, C#, PHP, and Ruby — download the full flag configuration once at startup and cache it in memory. Flag checks are pure in-memory lookups that typically complete in under one millisecond, adding no network round-trips to individual requests. Configuration updates are pushed to SDKs in real time via Server-Sent Events, so you get fresh values without polling. Client-side SDKs for browsers, React, Flutter, Android, and Swift receive pre-evaluated flag results tailored to the current user, keeping the payload small. The evaluation infrastructure is purpose-built for low latency and high throughput, handling millions of flag checks without adding measurable overhead to your application. The practical performance impact of adding feature flags to your application is negligible — the evaluation overhead is far smaller than a typical database query or API call.