PostHog
Use PostHog feature flags with the Flags SDK.
The PostHog package provides a managed PostHog adapter for the Flags SDK.
Learn more about Adapters
Deploy the template
Example usage
Getting started
Install the required dependencies:
Environment variables
Always required, read by postHogAdapter:
Optional, opts postHogAdapter into local evaluation, where
flag definitions are polled in the background instead of evaluating each flag remotely:
For the Flags Explorer, read by getProviderData only:
Import the PostHog adapter for Flags SDK, which reads POSTHOG_PROJECT_API_KEY, POSTHOG_HOST and POSTHOG_SECRET_KEY when it is first used:
If needed, you can instead initialize the adapter with your own options by importing createPostHogAdapter
The postHogAdapter is a single callable adapter. You can pass it directly, or
invoke it — both are equivalent:
postHogAdapter(orpostHogAdapter()): resolves the flag's evaluated value. For a boolean flag this is a boolean; for a multivariate flag it is the variantstring. Type the flag (e.g.flag<boolean>) to get the value type you expect.postHogAdapter.payload(orpostHogAdapter.payload()): resolves the flag's attached payload.
The flag's key is used as the PostHog feature flag key as-is. Every flag needs an
identify function returning the entities the adapter evaluates against:
The adapter throws if entities is missing, so a flag without identify will fail at
evaluation time.
Flags backed by this adapter participate in bulk evaluation:
evaluate() resolves flags that share an identify source through a single PostHog
request.
Then use it in your framework:
Evaluation modes
PostHog can evaluate flags remotely or locally.
Remote evaluation (default)
With only POSTHOG_PROJECT_API_KEY and POSTHOG_HOST set, the adapter evaluates
remotely. PostHog makes a network request for every feature flag evaluation, and each request
is billed separately. Having to make a network request for every flag evaluation
also adds latency. If you provide user ids, PostHog will look up additional properties from its database.
Local evaluation
Setting POSTHOG_SECRET_KEY (phs_...) is the only thing that switches evaluation
modes — the default adapter enables local evaluation exactly when that key is present.
In this mode, posthog-node periodically fetches your flag definitions in the
background (every 30s by default) and evaluates flags in-process against those cached
definitions, avoiding a network round trip on most checks after initialization. Because evaluation happens
locally, you're responsible for providing every property the flag's release conditions
depend on.
Each background poll is billed as 10 flag requests, independent of how many checks it serves, so for a long-running process this is usually far cheaper than paying per check. But the poller runs per compute instance, so PostHog recommends against local evaluation in short-lived compute, where each invocation would otherwise start its own poller and multiply cost rather than amortize it. Use remote evaluation there instead. You can widen the polling interval to trade slower propagation of flag changes for lower polling cost.
With Fluid Compute you may see latency and cost benefits from using local evaluation. It depends on your traffic patterns and load.
You can also enable it explicitly with createPostHogAdapter:
POSTHOG_PERSONAL_API_KEY and POSTHOG_PROJECT_SECRET_API_KEY are used only by
the Flags Explorer (getProviderData, below) to discover flag definitions. They
are never passed to the runtime client and do not enable local evaluation.
The default adapter also sets disableGeoip: true, since the server's IP is not a good
proxy for the user's location. Use createPostHogAdapter if you want the GeoIP-derived
person properties.
Flags Explorer
How to inform the Flags Explorer about flags
You can view and override these flags using the Flags Explorer
getProviderData supports either a project secret API key or a personal API key,
plus your project ID. Existing personal API key configurations continue to work.
Project secret API key
Create a project secret API key (phs_...) in your PostHog project's settings.
Only feature_flag:read is required for the project-scoped token. In the
permissions editor, set Feature flag to Read and every other scope to
No access, including Endpoint, Account, Loop, and Experiment.
No write access is needed. The definitions endpoint checks the feature flag scope;
experiment variants and payloads are included without an additional Experiment
permission.
This mode fetches /flags/definitions/ from the ingestion host configured by
POSTHOG_HOST (for example, https://us.i.posthog.com). The key identifies the
project for authentication; projectId supplies links to flags in the PostHog
dashboard. Pass apiHost to override the ingestion host and appHost to override
the dashboard host for a self-hosted or proxied instance.
The response includes descriptions from PostHog's name field and available flag
options. Nonempty payloads are used as options; otherwise the adapter exposes
boolean values or multivariate variants. This endpoint does not return creation
timestamps.
Personal API key
Alternatively, create a personal API key with Feature flag > Read
(feature_flag:read) and access to the intended project.
Personal API key mode calls PostHog's management API on the app host, which it derives from POSTHOG_HOST
(https://us.i.posthog.com becomes https://us.posthog.com, and the EU host maps
accordingly). Pass appHost explicitly if you use a self-hosted or proxied instance.
Missing credentials or host are reported back as hints in the Flags Explorer rather
than throwing.
Learn more about the Flags Explorer