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.
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, the flipper gem, or the flipper-cloud 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.
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 the flipper-cloud gem
In addition to importing and exporting file backups, Flipper supports syncing between adapters. This avoids the need for exporting and importing a file.
First, add the gem to your application:
Then, from a console or script, you can import your current adapter into Flipper Cloud:
# create an instance of flipper with whatever adapter you are using, # could be active record, redis, etc. 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)
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).