Documentation

Environments

Model your development lifecycle with production, personal, and custom environments in Flipper Cloud.

Overview

Environments allow you to vary feature enablement depending on where your code is running. A typical setup mirrors your deployment pipeline — production, staging, QA, and local development — so you can enable features in one context without affecting another.

Every project starts with a production environment and a personal environment for each team member. You can add custom environments (staging, QA, etc.) as needed.

Production Environment

Each project has exactly one production environment. It serves as the source of truth — all other environments mirror production by default.

When you enable a feature in production, it's automatically enabled everywhere else unless an environment has explicitly overridden it.

Production Mirroring

Non-production environments mirror production by default. This means every environment works like production out of the box without any additional configuration.

If you need a feature to behave differently in a specific environment, you can override it. For example, you might disable a feature in production but enable it in your personal environment for local development.

Overriding a feature in one environment has no effect on any other environment. You can return an overridden feature to mirrored state at any time with a single click.

Personal Environments

Every team member gets their own personal environment for each project they belong to. Personal environments are:

• Private — only visible to the person they belong to
• Isolated — changes don't affect anyone else
• Automatic — created when a member joins the project, removed when they leave

Personal environments are ideal for local development. Enable or disable features freely without worrying about impacting other team members or shared environments.

Custom Environments

Beyond production and personal environments, you can create any number of custom environments to match your workflow. Common examples include canary, staging, and QA.

Custom environments mirror production by default, just like personal environments. You can override individual features as needed and control who has access to modify feature state through environment permissions.

API Tokens

Each environment has its own API tokens for authenticating your application. Tokens are scoped to a single environment, so your staging application only sees staging feature state.

You can create multiple tokens per environment, allowing for rotation without downtime. Generate a new token, update your application configuration, then archive the old token.