Environments
GrowthBook comes with one environment by default (production), but you can add as many as you need on the Environments page located within the SDK Configuration menu.
Feature flags can be enabled and disabled on a per-environment basis. You can also set the default feature state for new environments and scope environments to specific projects.
When a feature is disabled for an environment, GrowthBook excludes the feature from the API response. The feature evaluates to null and ignores all targeting and rules.
A feature can be enabled for an environment but still act as "off" if its value is false, null, 0, or an empty string. In these cases, even though the feature is enabled, it evaluates as "off".
Environments and SDKs
Each SDK Connection is tied to a specific environment and has its own unique SDK key. When the SDK fetches its configuration, it receives only the features and rules for that environment, keeping your production and development environments separate.
To use multiple environments in the same codebase, use environment variables to set a dynamic key (e.g., GROWTHBOOK_CLIENT_KEY='sdk-abc123') and reference the variable in your code.
Environments vs. Projects
Environments and projects are both ways to organize feature flags, but they serve different purposes.
Environments represent where your code runs — such as development, staging, and production. A single feature flag exists across all environments, but can be enabled, disabled, or configured differently in each one. Environments map to SDK connections: each SDK key is tied to one environment, so your production app only receives production rules.
Projects represent what you're working on — such as a product area, team, or application. Projects scope which flags, experiments, metrics, and data sources are visible to a given team. Items in GrowthBook can belong to multiple projects, and items with no project assigned are available globally. Projects also let you customize permissions and even statistical settings per team. Manage projects under Settings → Projects.
In practice, you use both together: a feature flag in the "Mobile App" project might be enabled in the dev environment for testing but disabled in production until launch.
| Environments | Projects | |
|---|---|---|
| Purpose | Control where a flag is active | Organize who works on what |
| Scope | One flag, different settings per environment | Flags, metrics, data sources, and experiments per team |
| SDK impact | Each SDK connection maps to one environment | SDK connections can be scoped to a project to reduce payload size |
| Permissions | N/A | Users can have different permission levels per project |
| Example | dev, staging, production | "Mobile App", "Growth", "API" |
Learn more about how to use projects.
Environment Inheritance
EnterpriseEnvironment Inheritance is available on Enterprise plans.
When you create an environment you can specify a parent environment to inherit from. The new environment initially copies all feature rules from its parent. After creation, the environments operate independently, meaning changes to feature rules in one environment won't affect the other. Think of it like creating a fork or snapshot of the parent environment.
In the GrowthBook app, you can only inherit rules from the four default environments: production, dev, staging, or test. To inherit from a custom-named environment, use the API endpoint.
Common Use Cases
- Adding new environments to an existing setup (e.g., adding "staging" after having "dev" and "production")
- Troubleshooting production issues by creating an isolated test environment to safely diagnose problems
- Creating separate environments on a per-dev or per-PR basis