PostHog

PostHog feature flags: pricing, local evaluation and the limits that bite

PostHog's flags are genuinely good, and for a lot of teams they are free forever. This is the honest reference: exactly what the request meter counts, why local evaluation can cost more than remote if you leave the defaults alone, the caps and rate limits PostHog documents, and the point where a dedicated flag platform starts to make sense.

No card required

The short answer

PostHog feature flags are part of PostHog's single platform rather than a standalone product, and they are metered on requests to the flags endpoint, not seats, not monthly active users, and not the number of flags you define. You get 1,000,000 requests per month free, then $0.000100 per request to 2M, falling to $0.000010 above 50M. Team members are unlimited. The two things that surprise people: experiments and survey targeting checks bill on the same meter, and each local-evaluation definition fetch counts as 10 requests, which means one continuously running server at the default 30 second polling interval bills roughly 864,000 requests a month before evaluating a flag for a single user. If you already use PostHog for analytics and your volume fits the free tier, this is close to the best deal in the category. If you run a high-traffic client-side app or a large fleet of servers, model the bill carefully first.

Last updated July 2026 · verified against posthog.com/docs and posthog.com/pricing

01 · Set them up

Two evaluation modes, and the one that quietly costs more

PostHog gives you two ways to resolve a flag, and the choice is not obvious.

Remote evaluation is the default. Every check is a network call. PostHog documents this at roughly 100 to 500ms, and states that during that window the flag is disabled, which is what produces the flash of control content.
Local evaluation downloads the flag definitions on a timer and evaluates in your process. Much faster, but it needs a server-side secret key, so it works only in the Node, Ruby, Go, Python, C#/.NET, PHP, Java and Rust SDKs. There is no local evaluation in a browser or a mobile app.

The counterintuitive part: local evaluation is billed at 10 requests per definition fetch. Left at the 30 second default, a single always-on server instance costs about 864,000 requests a month doing nothing but polling. Ten instances is 8.64M, which is well into paid territory before any user is evaluated. Raising the interval to five minutes cuts it by 10x, at the price of slower flag propagation.

node · posthog-node · local evaluation live

// npm install posthog-node
import { PostHog } from 'posthog-node';

const client = new PostHog(process.env.POSTHOG_PROJECT_KEY, {
  host: 'https://us.i.posthog.com',

  // Local evaluation needs a SERVER-SIDE secret. Never ship this to a
  // browser. This is why local evaluation is server-SDK only.
  personalApiKey: process.env.POSTHOG_SECRET_KEY,

  // COST GOTCHA: each definition fetch bills as 10 flag requests.
  // At the 30s default, ONE long-lived server = ~864,000 requests/month
  // before a single user is evaluated. Raising this to 300s cuts that 10x.
  featureFlagsPollingInterval: 300000, // ms
});

// You must pass EVERY property the flag's release conditions reference.
// Miss one and the SDK silently falls back to a remote call (cost)
// or returns undefined (bugs).
const enabled = await client.isFeatureEnabled(
  'checkout.new-flow',
  String(user.id),
  { personProperties: { plan: user.plan, country: user.country } },
);

// undefined is NOT false. It means "not evaluated" and needs its own branch.
if (enabled === undefined) return renderClassicCheckout();

render(enabled ? newCheckout() : classicCheckout());

On the client, the shape is posthog.getFeatureFlagResult('flag-key'), returning an object with enabled, variant and payload. If you are wiring this into a component tree, the call-site patterns in our React feature flags guide apply the same way.

02 · The spec sheet

Everything PostHog documents, in one table

Figures taken from PostHog's own pricing and documentation pages in July 2026. Pricing in this category moves, so check the source before you build a budget on it.

Dimension	What PostHog documents
Metered unit	Requests to the flags endpoint. Not seats, not MAU, not flag count.
Free tier	1,000,000 flag requests per month, no time limit, no card
Paid rate, 1M to 2M	$0.000100 per request (about $100 for the first paid million)
Paid rate, 2M to 10M	$0.000045 per request
Paid rate, 10M to 50M	$0.000025 per request
Paid rate, above 50M	$0.000010 per request
Seats	Unlimited team members on every tier
Also on this meter	Experiments are billed with feature flags. Survey targeting checks consume flag requests.
What bills as a request	Server-side evaluations, client SDK initialization, identify calls, flag reloads, survey checks
Local evaluation cost	Each definition fetch counts as 10 requests. Default 30s polling is roughly 864,000 requests per server per month.
Remote evaluation latency	Roughly 100 to 500ms, and the flag reads as disabled during that window
Local evaluation SDKs	Node, Ruby, Go, Python, C#/.NET, PHP, Java, Rust. No browser, no mobile.
Flags per project	2,000 non-deleted flags. Individual flag filters capped at 512KB.
Rate limits	Local evaluation 600 per minute. The flags evaluation endpoint itself has no documented rate limit. Limits apply organization-wide.
Percentage rollouts	Down to 0.01%, with two decimal places of precision
Stickiness	Deterministic: same flag key plus same distinct ID always returns the same result
Targeting	Person and group properties, static and nested cohorts, device mode for anonymous users, flag dependencies, scheduled changes
Behavioral cohorts	Not supported for flag targeting. PostHog cites evaluation speed as the reason.
Experiments	Built in. Bayesian and frequentist engines, CUPED, holdouts, A/B/n, no-code experiments in beta.
Over quota	The flags endpoint returns a quota_limited response. Flags stop resolving rather than silently continuing.
Self-hosting	Officially unsupported. No guarantees, no paid support, no versioned releases, no published CVEs.

03 · The walls

Four walls, and the first one is a spreadsheet

None of these are hidden. PostHog documents all of them, and the fact that they publish a page called "Cutting feature flag costs" is itself the most useful signal on this list.

Wall 1

The request meter counts more than you think

Every client SDK initialization bills. Every identify call bills. Every survey targeting check bills, even though it has nothing to do with flags. On a high-traffic consumer site with client-side flags, the meter is effectively counting page loads, and 1M requests is a smaller number than it sounds. Model this before you adopt, not after your first invoice.

Wall 2

Local evaluation is faster and can be more expensive

The fix for latency is local evaluation, but definition fetches bill at 10x and poll on a timer regardless of traffic. One server at the 30 second default is roughly 864,000 requests a month. A fleet of twenty is 17M. You can raise the interval, but you are then trading away propagation speed, which is the thing a flag is for.

Wall 3

Feature interactions force you to pick two

Experience continuity, which keeps a flag stable across login, must be evaluated on PostHog servers, so turning it on disables local evaluation and bootstrapping for that flag. Behavioral cohorts cannot be used for targeting at all. Edge and serverless runtimes are documented as a bad fit for local evaluation without an external cache. You cannot have every feature at once.

Wall 4

Client-side means a visible flash

PostHog is direct about this: fetching flags takes 100 to 500ms and the flag is disabled during that window. So the control experience paints, then swaps. Bootstrapping fixes it if you can compute values server-side, and gating render fixes it at the cost of a skeleton. There is no third option, and this is a property of client-side flag delivery generally, not a PostHog defect.

The tripwire · undefined is not false

A missing property turns a targeted flag into a silent fallback

With local evaluation you are responsible for passing every property the flag's release conditions reference. Forget one and the SDK cannot evaluate locally, so it either falls back to a remote call (which costs money and latency you thought you had removed) or returns undefined. PostHog is explicit that undefined is neither false nor "flag is off", it means not evaluated, and it needs its own branch. The failure is quiet: your rollout looks like it is running and a slice of traffic is silently on the fallback path.

04 · The honest fork

Should you just use PostHog? Very often, yes.

Use PostHog's flags

Stay put if all of this is true

You already pay for PostHog analytics or session replay. Flags are close to free at the margin and the integration is genuinely useful.
You want to watch a session replay of a user hitting a flagged feature and tie that flag to a funnel, without joining data across two vendors.
Your flag request volume fits inside 1M a month, or you have modelled the tiers and the number is comfortable.
Your evaluation is server-side in a supported language, on long-lived processes rather than lambdas.
You want experiments with real statistics included rather than sold separately.

If that is you, use PostHog. One vendor doing flags, analytics and replay together is a real advantage, and paying anyone else (including us) for a second tool would be waste. Take the feature flag best practices and skip the extra vendor.

You have outgrown them

Look elsewhere when any of this is true

Your flag bill is now a line item someone asks about, and the answer involves explaining a polling interval.
You are raising the polling interval to save money, which means you are trading away the speed that made flags worth having.
You need a kill switch with a convergence time you can state out loud, not one that depends on when the next definition fetch lands.
You need behavioral cohort targeting, which PostHog explicitly does not support for flags.
You need supported on-premise deployment for compliance. PostHog states self-hosting is officially unsupported.
You want flags evaluated fast at the edge or in serverless functions, which PostHog documents as a poor fit for local evaluation.

That is the gap a dedicated feature flags platform fills: flat pricing with no meter to model, a real gradual rollout workflow, and a kill switch whose speed is not a function of your billing settings.

05 · Side by side

PostHog flags vs Toggled, without the marketing

PostHog wins the first three rows outright and we are not going to pretend otherwise. It is shipping today, it is free for most teams, and nothing else in this category gives you session replay next to your flag. Everything below that line is where a dedicated platform earns its place.

Dimension	PostHog feature flags	Toggled (planned)
Status	Shipping and supported today	Early access, launching soon
Entry price	$0 for 1M requests per month	Flat: $49 / $149 / $499 per month, planned
Analytics and replay in the same tool	Yes, and it is the main reason to choose it	No, we do flags and experiments only
Pricing model	Per request, with experiments and surveys on the same meter	Flat per team, no usage meter to forecast
Cost of a large server fleet	Definition fetches bill at 10x and scale with instance count	Not metered on requests or instances
Seats	Unlimited	Unlimited
Flags included	2,000 per project	Unlimited
Local evaluation	Server SDKs only, requires a secret key	Edge evaluation, no secret in the client
Behavioral cohort targeting	Not supported for flags	Attribute and cohort rules
Client-side flash	Documented 100 to 500ms window where the flag reads as disabled	Bootstrapped values, no fetch before first paint
Experiments	Built in, Bayesian and frequentist, CUPED	Built in from the first plan
Supported self-hosting	No, officially unsupported	No, managed only

Read the first row before you decide anything. PostHog is shipping today and Toggled is in early access. Our planned pricing is flat per team with unlimited flags and seats, which removes the polling-interval-versus-invoice conversation entirely. The numbers are on the pricing page, and the wider field is compared on best feature flag tools.

06 · FAQ

Questions people actually search

Are PostHog feature flags free?

Yes, up to a point. PostHog gives you 1,000,000 feature flag requests per month free, with no time limit and no card required. Past that the first paid million costs about $100, and the rate drops as volume climbs. Team seats are unlimited on every tier, so the meter is purely request volume.

How much do PostHog feature flags cost?

PostHog bills per request to its flags endpoint: $0 for the first 1M per month, then $0.000100 per request from 1M to 2M, $0.000045 from 2M to 10M, $0.000025 from 10M to 50M, and $0.000010 above 50M. Experiments are billed on the same meter, and survey targeting checks also consume flag requests.

What counts as a feature flag request in PostHog?

More than you would guess. Server-side flag evaluations count, but so does every client-side SDK initialization, every identify call, every flag reload, and every survey targeting check. Local evaluation definition fetches count as 10 requests each. The number of flags you have defined does not affect the bill; only requests do.

What is the difference between local and remote evaluation in PostHog?

Remote evaluation makes a network call to PostHog for every flag check, which PostHog documents at roughly 100 to 500ms. Local evaluation periodically downloads the flag definitions and evaluates them in your own process, which is far faster but requires a server-side secret key, so it is available only in server SDKs, never in a browser or mobile app.

Why are my PostHog feature flags slow or flickering?

Because fetching flags takes about 100 to 500ms and, in PostHog's own words, the flag is disabled during that window. Your control experience renders first and then swaps when the real value lands. The documented fixes are bootstrapping the client with known values at init, or holding the branch until flags have loaded.

Can you self-host PostHog feature flags?

You can run the open-source code, but PostHog states that self-hosted deployments are officially unsupported: no guarantees, no paid support, no versioned releases, and they do not publish CVEs for PostHog. If you need a supported on-premise flag service for compliance reasons, self-hosting PostHog is not the route.

How many feature flags can you have in PostHog?

The documented cap is 2,000 non-deleted flags per project, and any single flag's filters are limited to 512KB. Those are generous ceilings that most teams never approach. The practical constraint on PostHog is the request meter and the local evaluation rate limit of 600 per minute, not the flag count.

Is PostHog or LaunchDarkly better for feature flags?

They optimize for different things. PostHog is the better answer if you want flags, product analytics, session replay and experiments from one vendor with one bill, because the integration between them is real. LaunchDarkly is stronger on enterprise governance, approval workflows and SDK breadth. PostHog's own comparison page concedes the governance point.

Early access · launching soon

Outgrown the request meter? Keep the workflow, drop the forecasting

Unlimited flags, unlimited seats and built-in experiments on flat per-team pricing. Join the early-access list, no card required.

No card required · your data stays yours

Keep exploring