Flipper Cloud
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, 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).
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, even better, use webhooks for faster updates (than polling) and more isolation from Flipper Cloud.
Webhooks
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.
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.
Open Source Flipper Migration to Flipper Cloud
If you are already using the open source version of Flipper, migrating to Cloud is easy without any code changes. You can use the UI or the flipper gem to migrate all your feature data in a few minutes.
Via the Flipper UI
The easiest way to migrate to Cloud is via the Flipper UI.
Since version 0.27, the Flipper UI supports exporting your feature data to a JSON file. Go to Settings and then click Download.
Once you have the exported file, go to Import / Export for the Flipper Cloud environment you'd like to import into. From there, you can upload the file and import your features.
Via the flipper gem
If you don't have the Flipper UI installed, you can use the flipper gem to export your features to a JSON file.
File.write("flipper.json", Flipper.export.contents)
Once you've exported the file, you can go to Import / Export for the Flipper Cloud environment you'd like to import into. From there, you can upload the file and import your features.
Via Flipper Cloud
In addition to importing and exporting file backups, Flipper supports syncing between adapters. This avoids the need for exporting and importing a file.
From a console or script, you can import your current adapter into Flipper Cloud:
require 'flipper/cloud'
# Get the currently configured instance of flipper with whatever adapter you are using.
current_flipper = Flipper.instance
# Or if you need to initialize flipper with a specific adapter or configuration
# current_flipper = Flipper.new(Flipper::Adapters::ActiveRecord.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)
Warning: do not configure the FLIPPER_CLOUD_TOKEN
environment variable in your application prior to running the import. This will cause your application to use the Flipper Cloud adapter which will sync your current adapter with whatever is currently in Cloud (and could result in data loss).