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
You create and roll out flags in the PostHog web app. The other surfaces let you manage the same flags from your editor or your own systems, and review the flag problems Self-driving finds for you.
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 →PostHog Desktop Beta
Review Self-driving reports about broken and stale flags, and merge the fixes they open.
Review flag reports →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 →How feature flags works with Self-driving
Your flags are a signal source for Self-driving. A scout watches your flag roster against the $feature_flag_called stream and files a report whenever the two contradict each other: an active flag whose calls fall off a cliff, code calling a flag key that no longer exists, a response mix that shifted with no flag edit behind it, or flag debt piling up.
Most flag findings go to a human rather than a pull request – whether a dead flag check was deliberate cleanup or a broken deploy is a judgment call, so the report lands in your inbox with no repository attached. Only the obvious code changes, like removing the dead check behind a ghost flag, auto-open a draft PR for you to review and merge.
You create and roll out flags in the PostHog web app, and review the Self-driving work in PostHog Desktop or the Self-driving inbox. See the Self-driving docs for the full picture.