Documentation

Concepts

A brief overview of key terms used throughout Flipper to help you get started and get a feel for how the various concepts relate to each other.

Organizations

Organizations allow you to group projects for permissions and billing purposes. You can belong to one or more organizations. Each organization can have as many projects and members as necessary. Organization members are automatically granted access to all projects owned by the organization.

Projects

Projects allow you to manage many different applications and services under one organization. Each project has its own environments and features. All members of the owning organization are automatically granted access to the project. Additionally, you can grant access for people directly to one or more projects.

Environments

Environments allow you to model your development lifecycle and vary feature enablement depending on where the code is executed (e.g. from local development to staging to production).

Production and personal environments (one for each organization member and project collaborator) are automatically created for each project, but you are free to add any others as needed (e.g. staging, QA).

All feature enablements are scoped to environment, but by default mirror production. This makes it so that every environment works like production by default.

If a feature is enabled in production, it is enabled everywhere else, unless that environment has explicitly overridden it (e.g. disabled in production, but enabled in local development for engineers).

Audit history

One of the handiest upgrades from open source Flipper is Flipper Cloud's audit history. We keep track of who changed a feature, when they changed it and what changes were made.

We even go one step farther and allow you to view or rollback to any point in time. Accidentally enable a feature that was previously conditionally enabled for 3 actors and 2 groups? No problem. Just rollback to where things were good and get back to work.

Permissions

On free version of Flipper Cloud, all team members belong to the organization and have full access to manage the organization as well as acess to all current and future projects within that organization.

Flipper's paid plans include the ability to restrict access to some team members through several options. Organization team members can be administrators, billing team members, or standard team members.

• Organization Administrators can manage anything under the organization. That includes billing, projects, environments, team members, and features.
• Organization Members can view any projects within the organization and manage the features according to each environment's permissions. They cannot invite additional team members.
• Organization Billing can only manage the subscription and billing information. They can cancel a subscription but not delete an account or invite additional team members.

At an environment-level, each environment can be restricted to only environment owners (hand-picked for each environment), only organization members, or all project members—including collaborators who are not members of the organization. (Personal environments are always only visible and manageable by the user to which they belong.)

When environment access is restricted, only the designated group will be able to enable, disable, or roll back feature flag states for that environment. Similarly, once a given feature flag has been seen in production, only the designated group will be able to rename or delete that feature flag.

API Tokens

Each environment can have one or more API tokens as well, allowing for rotation without impacting currently in use tokens. You can generate a new token, update your application configuration to the new token, and archive the old token to rotate the token.

The only purpose of the API is to keep your application in sync with changes in Flipper Cloud. You can poll the API to stay in sync or use webhooks for faster updates.

Webhooks

Webhooks are another way to keep your application in sync with Cloud. Each environment can have multiple webhooks. Anytime something changes for that environment, we'll send a webhook request to your app to tell it to sync with Cloud.