Project-wide settings

You can configure project-wide feature flag settings to establish defaults and maintain safety measures for your team. These settings apply to all feature flags in your project and help maintain consistency across your flag management practices.

To access these settings, navigate to Settings > Feature Flags

Flag persistence default

When enabled, all new feature flags will have persistence enabled by default. This ensures consistent user experiences across authentication steps where users might have different properties before and after login.

Note: Modifying this setting will only affect new feature flags. Existing flags retain their current persistence settings.

Learn more about flag persistence in our creating feature flags documentation.

Flag change confirmation

When enabled, editing existing feature flags will show a confirmation modal before saving changes. This helps prevent accidental changes to flag release conditions that could impact your users' experience.

Why use change confirmation?

Feature flag changes can have immediate impact on your users. The confirmation modal helps prevent:

• Accidental changes to release conditions
• Unintended rollout percentage modifications
• Mistaken flag enablement/disablement

Custom confirmation messages

You can set a custom message to display in the confirmation modal. If no custom message is provided, the default message will be:

⚠️ These changes will immediately affect users matching the release conditions. Please ensure you understand the consequences before proceeding.

Custom messages are limited to 500 characters and can help provide context specific to your team or project needs.

Default release conditions

When enabled, newly created feature flags are pre-populated with the release conditions you configure here. This helps teams maintain consistent rollout patterns across flags without relying on manual processes.

Default release conditions include property filters and rollout percentages, just like regular release conditions on individual flags. Users can still modify or remove these conditions during flag creation.

Note: Default release conditions don't apply to remote config flags, which always have a fixed 100% rollout. When applying a flag template, default conditions are prepended before the template's conditions.

Default release conditions

When enabled, newly created feature flags are pre-populated with a set of default release conditions. This helps teams enforce consistent rollout patterns (e.g., targeting specific user segments or rollout percentages) without relying on manual setup each time.

To configure, navigate to Settings > Feature Flags > Default release conditions and toggle Apply default release conditions to new flags. Then use the release conditions editor to define your default groups, including property filters and rollout percentages.

Note: Default conditions are pre-populated, not enforced. Users can modify or remove them during flag creation.

Key behaviors:

• When applying a feature flag template, default groups are prepended before the template's groups.
• Remote config flags skip defaults since they always use a fixed 100% rollout.
• Modifying this setting requires admin permissions. Non-admin team members have read-only access.

Feature flags secure API key

Deprecated: The feature flags secure API key is deprecated. Use a project secret API key with the feature_flag:read scope instead. It works as a drop-in replacement for local evaluation and remote config settings, with no SDK code changes needed. Existing feature flags secure API keys keep working after you switch, so you can move one deployment at a time.

Secure API keys retrieve feature flag definitions for local evaluation or remote config settings.

Key management

If you still use a feature flags secure API key, manage it in Settings > Feature flags:

• Primary key: The currently active key used for API requests
• Backup key: Created when you rotate keys to support safe migration
• Key rotation: Generate new keys while keeping the old one temporarily active

Rotation without downtime works by maintaining both primary and backup keys during the transition period. Delete the backup key once all your systems use the new one.

Migrating to a project secret API key

1. Create a project secret API key with the Local feature flag evaluation preset (the feature_flag:read scope).
2. Replace the key in your SDK configuration. Both key types use the same phs_ prefix and the same configuration option, so nothing else changes.
3. Once all your deployments use the new key, invalidate the old key string: rotate the key in the Feature flags tab of your project settings, then delete the backup key. You can't remove the legacy key itself, and your SDKs don't need the new primary that rotation creates. If you use Support, its identity verification and external API use this key's secret: after you rotate, switch your backend to the new primary, and delete the backup only after that deploy is live.

Note: PostHog will also migrate existing legacy keys to project secret API keys server-side, with no change to the key string you send. You don't need to act, but migrating yourself gets you scoped, individually revocable keys sooner.