Feature flags
Contents
Feature flags let you ship code without shipping the feature. Wrap a change in a flag, roll it out to 1% of users, watch what happens, and turn it off the moment something looks wrong – no redeploy, no hotfix. The same flags power experiments, early access programs, kill switches, and remote config.
Because PostHog already knows who your users are, targeting is more than a percentage. Roll out by person property, cohort, or group, then see the session replays, events, and exceptions from the people who got the flag – so you find out whether the rollout worked, not just that it happened.
Where you can use it
Create and roll out flags in the PostHog web app, or manage them from an MCP client or your own systems.
PostHog Web
Create flags, set release conditions, schedule changes, and watch rollouts land.
Roll out a flag →PostHog MCP
Create, update, schedule, and clean up flags from any MCP client or AI editor.
Manage flags →Where its data comes from
A flag is only as good as what it evaluates against. PostHog decides each user's value from the release conditions you set, the person and group properties it already has, and the payload attached to the flag.
Evaluation
Where and how a flag is resolved: local evaluation, bootstrapping, and evaluation contexts.
Evaluate flags locally →Targeting
Person properties, cohorts, and groups decide who matches a release condition.
Target users and groups →Payloads and config
Ship JSON alongside a flag with remote config, and share flags across projects.
Set up remote config →