Environments

Environments represent different stages of your application lifecycle. Each environment can have different flag states, allowing you to test features safely before enabling them in production. This guide covers creating and managing environments.

What Are Environments?

Environments are:

Isolated Stages - Separate configurations for dev, staging, production
Independent Flag States - Each environment can have different flag values
Secure - Each environment has its own API key
Configurable - Customize settings per environment

Common environments include: Development, Staging, Production, Testing, and Preview. You can create as many environments as needed for your workflow.

Understanding Environments

Why Use Multiple Environments?

Safe Testing - Test flags in development before production
Staged Rollouts - Enable features gradually across environments
Isolation - Keep production stable while developing new features
Team Collaboration - Different teams can work in different environments

Environment Keys

Each environment has a unique API key:

Used for SDK initialization
Keeps environments secure and separate
Can be rotated independently
Found in Project Settings → General → Keys

Keep environment keys secure. Never commit them to version control. Use environment variables in your applications.

Creating Environments

Navigate to Environment Settings

Go to your project's Settings → Environments:

Select your project from the Projects dropdown
Click Settings in the navigation
Select the Environments tab

You'll see a list of existing environments (if any).

Click Create Environment button. A modal will open asking for environment details.

Configure Environment

Enter the environment details:

Environment Name (Required):

Descriptive name (e.g., "Development", "Staging", "Production")
Must be 1-30 characters
Use clear, standard names

Description (Optional):

Brief description of the environment's purpose
Helps team members understand when to use it

Use standard naming conventions like "Development", "Staging", "Production" to make it clear what each environment is for.

Create the Environment

Click Create to create the environment. It will be added to your project and you'll receive a unique environment key.

The environment is immediately available for use. You can start creating flags with this environment enabled.

Managing Environments

Viewing Environments

The Environments settings page shows:

Environment List - All environments in your project
Environment Details - Name and description for each
Actions - Edit or delete options

Editing Environments

To edit an environment:

Click Edit on the environment card
Update the name or description
Click Update to save changes

Editing an environment name doesn't affect existing flags. Flags will continue to work with the updated environment name.

Deleting Environments

To delete an environment:

Click Delete on the environment card
Confirm the deletion

Deleting an environment will remove all flag configurations for that environment. Make sure you no longer need the environment before deleting it.

Environment Keys

Viewing Keys

To view environment keys:

Go to Settings → General
Scroll to the Keys section
Find your environment in the list
Click to copy the key

Using Keys

Use environment keys to:

Initialize SDKs - Configure SDKs with the appropriate environment key
API Requests - Include the key in API requests
Security - Keep keys separate for each environment

Use different keys for different environments in your application. This ensures flags are evaluated correctly for each environment.

Flag Configuration Per Environment

When creating or editing flags, you configure them per environment:

Per-Environment Settings

For each environment, you can set:

Enabled/Disabled - Whether the flag is active
Payload - Environment-specific payload values
Expiration - Different expiration dates per environment

Example Configuration

Development Environment:

Flag: new_feature → Enabled
Payload: {"debug": true, "version": "beta"}

Staging Environment:

Flag: new_feature → Enabled
Payload: {"debug": false, "version": "rc"}

Production Environment:

Flag: new_feature → Disabled
Payload: {}

This allows you to test features in development, validate in staging, and control rollout in production independently.

Best Practices

Environment Naming

Use Standard Names - Development, Staging, Production
Be Descriptive - "QA Testing" is better than "Test"
Stay Consistent - Use the same names across projects
Avoid Special Characters - Keep names simple and clear

Environment Strategy

Start Simple - Begin with Development and Production
Add Staging - Include staging for pre-production testing
Create as Needed - Add environments for specific use cases
Don't Overcomplicate - Too many environments can be confusing

Flag Management

Test in Development First - Always enable flags in dev before other environments
Validate in Staging - Test thoroughly in staging before production
Gradual Production Rollout - Enable flags gradually in production
Monitor Each Environment - Watch for issues in all environments