Feature Flags

Last updated:

|Edit this page

Feature Flags enable you to safely deploy and roll back new features. This means you can ship the code for new features and roll it out to your users in a managed way. If something goes wrong, you can roll back without having to re-deploy your application.

Feature Flags also help you control access to certain parts of your product, such as only showing paid features to users with an active subscription.

Creating feature flags

In the PostHog app sidebar, go to 'Feature Flags' and click 'New feature flag'.

Think of a descriptive name and select how you want to roll out your feature.

Create feature flags

Local evaluation

If you're using our server-side libraries, you can use local evaluation to improve performance instead of making additional API requests.

We consider it best practice to use local evaluation flags where possible because this method enables you to resolve flags faster and they are more efficient as they generally require fewer API calls and can reuse definitions for multiple users.

For billing purposes we count a local evaluation API request as being equivalent to 10 decide requests. One local evaluation request can compute feature flags for hundreds or thousands of users, so this ensures local evaluation is priced fairly while remaining the most cost-effective option by far.

Implementing the feature flag

When you create a feature flag, we'll show you an example snippet. It will look something like this:

if (posthog.isFeatureEnabled('new-beta-feature')) {
// run your activation code here
}

What you do inside that if statement is up to you. You might change the CSS of a button, hide an entire section, or move elements around on the page.

Ensuring flags are loaded before usage

Every time a user loads a page we send a request in the background to an endpoint to get the feature flags that apply to that user. In the client, we store those flags as a cookie.

This means that for most page views the feature flags will be available immediately, except for the first time a user visits.

To combat that, there's a JavaScript callback you can use to wait for the flags to come in:

Web
posthog.onFeatureFlags(function () {
// feature flags are guaranteed to be available at this point
if (posthog.isFeatureEnabled('new-beta-feature')) {
// do something
}
})

Persisting feature flags across authentication steps

You have an option to persist flags across authentication steps.

Consider this case: An anonymous person comes to your website and you use a flag to show them a green call to action.

Without persisting feature flags, the flag value can change on login because their identity can change (from anonymous to identified). Once they login, the flag might evaluate differently and show a red call to action instead.

This usually is not a problem since experiments run either completely for anonymous users, or completely for logged in users.

However, with some businesses, like e-commerce, it's very common to browse things anonymously and login right before checking out. In cases like these you can preserve the feature flag values by checking this checkbox.

Persist feature flags

Note that there are some performance trade-offs here. Specifically,

  1. Enabling this slows down the feature flag response.
  2. It disables local evaluation of the feature flag.
  3. It disables bootstrapping this feature flag.

Feature flags versus experiments

Experiments are powered by feature flags, but they are a specific format with test and control variants. This means a feature flag cannot be converted into an experiment. We disallow this to avoid implementation changes, targeting errors, and confusion that would come from the conversion.

For example, a boolean flag isn't able to turn into an experiment.

If you want to reuse the same key, you can delete your flag and use the same key when creating the experiment.

Further reading

Want to know more about what's possible with Feature Flags in PostHog? Try these tutorials:

Using a library other than JavaScript for your feature flag implementation? Check out these other libraries for more details.

Want more? Check our full list of PostHog tutorials.

Questions?

Was this page useful?

Next article

Bootstrapping & local evaluation

PostHog offers two main ways to use feature flags. You can send a request to the PostHog /decide API endpoint to resolve a flag, or You can use server-side local evaluation to pull flag definitions, and resolve flags using the definition data Client-side bootstrapping There is a delay between loading the library and feature flags becoming available to use. This can be detrimental if you want to do something like redirecting to a different page based on a feature flag. To have your feature…

Read next article