Skip to content
Featureflip Docs

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 project settings 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, regenerate it from the dashboard and update your application configuration.

Next steps

Section titled “Next steps”