**Feature Gates**, commonly known as feature flags, allow you to toggle the behavior of your product in real time without deploying new code.

Developers often use them to turn on certain features for a small percentage of the total user base. This approach enables safer, gradual software releases because you can monitor the impact on system behavior. Feature Gates also let you limit application behavior for a specific set of users, such as dogfooding [environments](/guides/using-environments).

{% figure %}
![Feature Gates hero image](/images/feature-flags/featuregates.png)
{% /figure %}

## When to use

#### Use when you need to

* Schedule gradual feature rollouts to safely deploy new code
* Set up dev staging environments before code hits production, like dogfooding
* Have an emergency disable switch that lets you immediately turn off a particular code branch for users in production
* Modify the user experience based on attributes like username, email, or other identifiers
* Change app behavior based on context like device, browser type, version, and other environment attributes

#### Not recommended if

* You need to return structured or multi-value data based on targeting rules and conditions: use a [Dynamic Config](/dynamic-config/overview) instead.
* You want to test complex hypotheses beyond simple A/B tests and launch impact: set up an [Experiment](/experiments/overview) instead.

## How it works

1. [Create a Feature Gate](/feature-flags/create) with [targeting rules](/feature-flags/conditions) in the Statsig console.
2. To have the Feature Gate impact users, integrate the [Statsig SDK](/sdks/getting-started) into your product code. The SDK queries the gate value at runtime and returns a true/false result based on user attributes, environment data, and other conditions you define.
3. [Test a Feature Gate](/feature-flags/test-gate) to confirm it behaves as expected before rolling it out.
4. For finer targeting control, set up [Feature Gate overrides](/feature-flags/overrides) to allow specific users to bypass the gate.
5. After your Feature Gate is live, [view Feature Gate exposures](/feature-flags/view-exposures) in the Statsig console to monitor who encounters your gate.
6. Set up deprecation rules and clean up old flags by [managing Feature Gate lifecycles](/feature-flags/feature-flags-lifecycle).

## Key capabilities

### Scheduled rollouts

Gradually deploy a feature over time by setting up a Feature Gate as a [Scheduled Rollout](/feature-flags/scheduled-rollouts).

### Overrides and bypass lists

Implement Feature Gates with [Overrides](/feature-flags/overrides) to allow a specific list of users to bypass your gate.

### Chained flag dependencies

Chain Feature Gates together in parent-child or other dependent relationships so a top-level gate can enable or disable all its dependent flags at once. This is useful for global disable switches that guard sub-features.

### Built-in A/B tests

Run simple A/B tests without additional setup using [Pulse](/feature-flags/view-exposures). In practice, this means treating the users who see the new feature as the "treatment" group, and the users who are gated (and therefore don't see the new feature yet) as the "control".

### Feature Gate testing

[Test your Feature Gates](/feature-flags/test-gate) with Statsig's built-in tools to check whether your Feature Gate is configured to target the right people.

## FAQs

{% accordion-group %}
{% accordion title="How are Feature Gates different from Dynamic Configs?" %}
Dynamic Configs are key-value configs that let you return structured data (not just true/false) based on targeting rules. They're more for customizing behavior, tuning parameters, or supporting complex logic *beyond booleans*. Feature Gates are simpler on/off switches for gating access to a feature. Technically, you can set up a Dynamic Config as a Feature Gate.
{% /accordion %}

{% accordion title="When should I use Feature Gates instead of Experiments (and vice versa)?" %}
Go to [Choosing Feature Flags vs. Experiments](/guides/featureflags-or-experiments) for a full guide. Use Feature Gates to measure the general impact of a feature rollout. Use Experiments when you have a more specific hypothesis or test in mind.
{% /accordion %}
{% /accordion-group %}

## Related tutorials

* [Set up dev environments with Feature Gates](/guides/using-environments)
* [Customize dev environments with Feature Gates](/guides/testing)
* [Choosing Feature Flags vs. Experiments](/guides/featureflags-or-experiments)
* [Best Practices for Feature Gates](/feature-flags/best-practices)