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, no SDK code changes needed. Existing feature flags secure API keys continue to work until you switch.

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, you can manage it from the Feature flags tab of your project settings:

• 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, delete the legacy feature flags secure API key.