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 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 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, etc.).
All feature enablements are scoped to environment, but by default mirror production. This means that if a feature is enabled in production, it is enabled in all environments, unless that environment has explicitly overridden it (e.g. disabled in production, but enabled in local development for engineers).
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, even better, use webhooks for faster updates (than polling) and more isolation from Flipper Cloud.
Webhooks keep your application in sync with Cloud without polling. 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.
We recommend this route for production. But you can also use it for staging or other environments that are exposed to the internet. Using webhooks keeps your features in sync without polling Flipper Cloud, which means all feature check reads are local to your application and blazing fast.
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.
If you are already using the open source version of Flipper, migration to Flipper Cloud is easy since Flipper supports syncing between adapters.
# create an instance of flipper with whatever adapter you are using current_flipper = Flipper.new(Flipper::Adapters::Memory.new) # makes cloud identical to memory flipper # note: this will wipe out whatever is in cloud Flipper::Cloud.new(token: "<your-token-here>").import(current_flipper)