In PostHog, open the Feature Flags tab and click New. Enter a unique flag key and a description, choose a type (a release toggle, multiple variants with rollout percentages, or remote config), then set release conditions such as a rollout percentage and person property filters. Each team can have up to 2,000 non-deleted flags.
Pick the flag type first
A feature flag lets you switch a feature on for some people and off for others without shipping new code. PostHog offers three types, and the right one depends on the job.
| Type | Returns | Use it for |
|---|---|---|
| Release toggle (boolean) | true when enabled and a condition matches, false when disabled, null or undefined if no condition matches | Rolling a feature out gradually |
| Multiple variants (multivariate) | A variant key such as control or test | A/B/n tests with a rollout percentage per variant |
| Remote config | The same payload for everyone | Changing settings without a release |
The dropdown beside New also creates pre-configured flags: boolean, multivariate, remote config or experiment. If you're testing which version of a page works better, my guide on running A/B tests effectively covers the thinking behind the multivariate option.
Creating the flag
- Open the Feature Flags tab in PostHog and click New.
- Enter a unique flag key, such as new-landing-page, and a description your team will understand.
- Choose the type: boolean release toggle, multivariate or remote config.
- Add release conditions: a rollout percentage, person or group property filters, cohorts or location.
- Optionally add payloads and choose the evaluation runtime and contexts.
- Save the flag, then check it in your code using its key.
In code, you'd check it with expressions such as posthog.isFeatureEnabled('new-landing-page') or posthog.getFeatureFlag('betaFeature'). The key is the link between the dashboard and your code, so pick one that describes the feature and don't change it later.
Release conditions and targeting
Rollout percentages can go to two decimal places, down to a minimum of 0.01%, which lets you start with a tiny slice of users. You can target by GeoIP location, by person properties and cohorts if you capture identified events, and by group properties if group analytics is switched on. Semantic version operators let you target values such as app_version, which suits mobile app rollouts.
For multivariate flags, each variant gets a rollout percentage, and users are randomly assigned by those percentages.
Payloads
A payload is extra JSON sent to your app when a flag matches. Remote config flags always return the same payload to everyone, while multivariate flags can carry a different payload for each variant, such as a different headline for control and test.
A simple staged rollout
Here's a pattern I'd use for any feature that touches paying customers. Start at 1%, and leave it a day or two while you watch for errors. If nothing breaks, move to 10%, then 50%, then 100%. Because you're only changing a percentage on the flag, each step takes seconds, and if something goes wrong you can drop it back to zero without a new release. That's the whole point of using a flag.
Condition order and identified users
PostHog Docs flag two things that make a flag behave oddly. A flag with a person-property filter only works once users are identified. And condition sets run top to bottom, so a catch-all set placed above narrower ones can short-circuit them. Put the narrowest condition first. There's also an optional setting, Stop evaluation at first matching condition set, which is off by default.
Limits are generous but real: each team can have a maximum of 2,000 non-deleted flags, and an individual flag's filters are limited to 512KB. Delete flags once a feature is fully live, so the list stays readable.
Want AI doing the heavy lifting in your marketing?
I build the systems that handle the boring 80 percent, so you get your week back. Done properly, with the human kept in.
Moving flags from another tool
If you're coming from another feature flag tool, PostHog documents a migration path for LaunchDarkly and Statsig flags through its API. For a broader look at testing tools, my roundup of the best A/B testing tools covers more options, and my guide to using product analytics explains how flags fit with measuring what users do.
My advice for your first PostHog flag
Start with a boolean release toggle on a low-risk feature, roll it out to a small percentage of users, and watch what happens before you widen it. Use clear, permanent keys, order condition sets from narrowest to broadest, and tidy up old flags once a feature's fully released.
Want your tool on this list? Featured spots and reviews here are paid partnerships. Here's how to partner with me.
Frequently asked questions
What flag types does PostHog offer?
Release toggle, multiple variants with rollout percentages, and remote config.
How many flags can a team have?
2,000 non-deleted flags per team.
Can I roll out to a percentage?
Yes, with up to two decimal places, down to 0.01%.
Can I serve different config per variant?
Yes. Multivariate flags can have a payload per variant.
Can I migrate flags from another tool?
Yes, through the API. PostHog has guides for LaunchDarkly and Statsig.
