How to Set Up Feature Flags in PostHog (Rollouts, Targeting, and Cleanup)
Feature flags separate deploying code from releasing it. With flags, engineers can merge unfinished work behind a switch, PMs can roll out to a small group first, and anyone with access can turn a feature off without a deploy if something goes wrong. PostHog includes feature flags alongside its analytics, which means the people you roll out to can be analyzed in the same tool.
This guide covers creating a flag, writing release conditions, running a percentage rollout, using multivariate flags and payloads, avoiding UI flicker, and the cleanup step most teams skip. It assumes the PostHog SDK is installed in your app.
Rolling out behind a flag? Write the experiment brief before you ship.
Describe the change and the number you want to move. Vantage turns it into a written brief you can share with eng and data before anything ships.
How this works
- We save what you typed. No AI runs on this page.
- You create a free account.
- Vantage builds an experiment brief from it inside your own workspace.
Why ask for an account? We’re a small team, and a full generation runs a multi-step AI pipeline that costs us real money. So we tie it to a free account instead of running it anonymously. You also get to keep the result and edit it.
Your text is only used to create your project, and it stays private to your account. If you don’t sign up, we delete it after 7 days. Privacy policy
Step-by-step guide
Create the flag with a descriptive key
Open Feature flags in PostHog and create a new flag. Choose a key that describes the feature and is easy to search for in code, such as new-billing-page. Add a description explaining what the flag controls and who owns it. That description is what someone will read six months from now when deciding whether the flag can be removed.
- Create a new feature flag
- Use a short, descriptive key in kebab-case
- Write a description with the owner and the related ticket or spec
Write release conditions
Release conditions decide who gets the flag. You can match on person properties such as email domain or plan, on cohorts, and on a rollout percentage within each condition. A common first condition is your own team, by email domain or an internal cohort, so you can test in production before anyone else sees the feature.
- Add a condition for internal users first
- Add conditions for beta customers using a cohort or property
- Set rollout percentages per condition
- Save and verify the flag returns the expected value for test users
Implement the flag in code
Use the SDK to check whether the flag is enabled, for example with isFeatureEnabled, and branch your code accordingly. Keep the check close to where the behavior changes and avoid scattering the same flag across many files; a single check that selects a component is easier to remove later.
Roll out gradually
Move from internal users to a small percentage of all users, then increase in steps while watching error rates and key metrics. PostHog assigns users consistently based on their distinct ID, so a user who gets the feature at 10% keeps it when you go to 25%. Define what you will watch before each step so the decision to continue is not a guess.
- Release to internal users and verify behavior
- Release to a small percentage of users
- Check errors and key metrics before each increase
- Roll out to 100% when stable
Use multivariate flags and payloads when needed
Multivariate flags return one of several variant keys instead of true or false, which is useful when testing more than one version. Payloads let you attach JSON to a flag or variant, such as copy or configuration, so you can change values without a deploy. Use payloads for configuration, not for large chunks of logic.
Avoid flicker on page load
Client-side flags may load after the first render, causing the old UI to flash before the new one appears. PostHog supports bootstrapping flag values from the server and server-side evaluation, including local evaluation in server SDKs, to reduce this. For UI-visible flags, render a neutral loading state or evaluate the flag server-side.
Clean up flags after launch
Once a feature is fully rolled out and stable, remove the flag check from code, deploy, and then delete or archive the flag in PostHog. Create the cleanup ticket at the same time as the flag so it is part of the plan, not an afterthought.
Common mistakes
Flags with no owner
Flags without an owner and description become permanent fixtures that nobody dares remove. Record the owner when you create the flag.
Skipping internal testing
Going straight to a percentage of real users means customers find the bugs. Always release to your team first.
Using flags as long-term configuration
Temporary release flags that become permanent configuration are hard to reason about. Use a separate, clearly named flag or config system for permanent settings.
Tips
Prefix temporary flags with a convention such as release- so they are easy to find for cleanup.
Create a PostHog cohort of internal users and reuse it as the first condition on every flag.
Link the flag key in the ticket and the ticket in the flag description.
Review flags at 100% rollout monthly and schedule their removal.
How Vantage helps
Rollout plans belong in the spec, not in someone's head. Vantage PRDs can capture rollout stages and success metrics, and the generated tickets include both the flagged implementation and the cleanup work, sequenced with dependencies and pushed to Linear or Jira.