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

Use secure API keys to retrieve feature flag definitions for local evaluation or remote config settings. These keys replace personal API keys for flag-related operations.

Key management

• 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

Best practices

1. Keep keys private: Never expose these keys in client-side code
2. Rotate regularly: Generate new keys periodically for security
3. Clean up backups: Delete backup keys once you've migrated all systems
4. Use project-specific keys: Each PostHog project should use its own secure API key

The secure API key system enables you to safely rotate keys without downtime by maintaining both primary and backup keys during the transition period.