Feature Flag Environments
Environments let you maintain separate flag configurations for each stage of your deployment pipeline. A flag can be enabled in development, partially rolled out in staging, and disabled in production — all at the same time.
What are environments?
Section titled “What are environments?”An environment is an isolated context for flag configuration. When you create a project in Featureflip, it starts with three environments:
- Development — for local development and testing
- Staging — for pre-production validation
- Production — for live users
Each environment has its own flag states, targeting rules, and rollout percentages. Changes to one environment do not affect the others.
Independent configuration
Section titled “Independent configuration”Every flag is configured independently per environment. This means:
- A flag can be on in Development and off in Production.
- A flag can target beta users in Staging but use a percentage rollout in Production.
- A flag’s fallthrough variation can differ between environments.
This independence lets you test features safely before exposing them to real users. You promote a feature through environments as confidence grows, not by changing code.
SDK keys
Section titled “SDK keys”Each environment has its own SDK key. When you initialize a Featureflip SDK in your application, you provide the SDK key for the environment the app is running in:
const client = FeatureflipClient.get({ sdkKey: "sdk-dev-abc123", // Development environment key});The SDK key determines which environment’s flag configurations your application receives. Use the Development key in your local environment, the Staging key in your staging deployment, and the Production key in production.
Keep SDK keys out of source control. Store them in environment variables or a secrets manager.
Creating custom environments
Section titled “Creating custom environments”The default three environments work for many teams, but you can create additional ones to match your workflow:
- QA — a dedicated environment for your QA team
- Canary — for canary deployments that receive traffic before the full fleet
- Regional — for region-specific configurations (e.g., EU, US, APAC)
When you create a new environment, Featureflip automatically generates configurations for all existing flags in that environment. Flags start in the off state, so there is no risk of unintended exposure.
You can create environments from the Environments page in the Featureflip dashboard.
Best practices
Section titled “Best practices”Match your deployment pipeline. If your code goes through dev, QA, staging, and production, create an environment for each stage. This makes flag promotion predictable.
Use consistent naming. Name environments to match what your team already calls them. If everyone says “preprod,” do not call it “staging.”
Promote flags through environments. Enable a flag in dev first, then staging, then production. Treat flag promotion like code promotion.
Rotate SDK keys if compromised. SDK keys are sensitive. If a key is exposed, create a replacement on the SDK Keys page, switch your application to it, and revoke the old key.
Next steps
Section titled “Next steps”- How to Manage Environments — step-by-step guide to creating environments and SDK keys
- What Are Feature Flags? — flag types, variations, and lifecycle
- SDK Overview — choose the right SDK and learn how SDK keys are used
- Targeting & Segments — configure per-environment targeting rules
Frequently Asked Questions
Section titled “Frequently Asked Questions”What are feature flag environments?
Section titled “What are feature flag environments?”An environment is a separate context for flag configuration, with its own flag states, targeting rules, rollout percentages and SDK key. Change one, the rest stay put. That’s what lets a single flag be fully on in Development, serving 10% of users in Staging and switched off in Production on the same afternoon. New projects get Development, Staging and Production. Add QA or Canary whenever your pipeline has those stages, and every existing flag starts off there.
How do I manage separate dev and production flag configurations?
Section titled “How do I manage separate dev and production flag configurations?”Give each deployment its own environment’s SDK key. The key decides which configuration the SDK receives, so your laptop runs on the Development key and production runs on the Production key without any code changing between them. Then promote a flag the way you promote code. Development first. Staging next, then Production, widening the rollout percentage at each step. Keep keys in environment variables or a secrets manager. If one leaks, create a replacement on the SDK Keys page, switch your app over and revoke the old key, which stops working immediately.