Flipper Cloud is a platform for feature flipping, which in its simplest form is named conditionals used to control code execution. The primary benefit of feature flags compared to fixed conditionals is the ability to change a feature's state (enabled or disabled) from outside the running program.
We make it easy to...
We have a beautiful, web interface for managing your organizations, projects, environments and features. Additionally, we expose a simple HTTP API along with a client library that takes only a few minutes to integrate into your application.
When you create a project, it comes preloaded with a production environment and a personal environment for each user to get you up and running quickly, but we support as many other environments as necessary (e.g. staging, smoke, Heroku review app, or whatever you can dream up).
Flipper Cloud is built on top of jnunemaker/flipper. The Flipper Cloud client library is a pre-configured version of the Flipper HTTP adapter. The HTTP adapter communicates with the Flipper API mounted in our application.
If most of the bits that make up Flipper Cloud are open source, why not tack them all together on your own and self-host? The simple answer is that the bits that are open source are the easy ones. They will get you up and running, but do not address the harder parts, such as permissions, auditing and analytics.
I’ll go a step further and suggest that you don’t use self-hosted applications when hosted services are available. While it may seem simple on the surface, maintaining even one–let alone a handful–of self-hosted tools can quickly become a distraction. Security updates, availability, and upgrades are all extra work that take you away from focusing on your product. Self-hosted solutions may be worthwhile for your business in the long term, but if you have a small team, they’re one more burden that can weigh you down.
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.
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.
Features are the heart of Flipper Cloud. They allow you to control code execution based on a few different types of enablement.
All on or all off. Think top level things like :stats, :search, :logging, etc. Also, an easy way to release a new feature, as once a feature is boolean enabled it is on for every situation.
Turn on feature based on the return value of block. Super flexible way to turn on a feature for multiple things (users, people, accounts, etc.) as long as the thing returns true when passed to the block.
There is no requirement that the thing yielded to the block be a user model or whatever. It can be anything you want, therefore it is a good idea to check that the thing passed into the group block actually responds to what you are trying to do in the
register proc. This is why the
:admin group above uses
Turn feature on for individual thing. Think enable feature for someone to test or for a buddy. The only requirement for an individual actor is that it must respond to
The key is to make sure you do not enable two different types of objects for the same feature. Imagine that user has a
flipper_id of 6 and group has a
flipper_id of 6. Enabling search for user would automatically enable it for group, as they both have a
flipper_id of 6.
The one exception to this rule is if you have globally unique flipper_ids, such as UUIDs. If your flipper_ids are unique globally in your entire system, enabling two different types should be safe. Another way around this is to prefix the
flipper_id with the class name like this:
Turn this on for a percentage of actors (think user, member, account, group, whatever). Consistently on or off for this user as long as percentage increases. Think slow rollout of a new feature to a percentage of things.
Percentage of actors also takes into account the feature name to ensure that the same actors are not granted access first to every feature.
Note: 100% of actors will not return true if no actor is provided.
Turn this on for a percentage of time. Think load testing new features behind the scenes and such.
Percentage of time is not a good idea for enabling new features in a UI. Most often you'll use percentage of actors, but there are definitely times when I have found percentage of time to be very useful.
Setting up Flipper takes only a few minutes. Follow the guide below or let us know if you would prefer to have us do it for you. For the moment, Flipper Cloud only supports ruby applications. If there is another language you would like to see support for, we would love to know.
In addition to the steps outlined below, we have a fully functional example Rails application for you to peruse.
bundle to install.
If you're using the ActiveRecord adapter, you'll also need to generate the migrations and run them.
Create a new file
config/initializers/flipper.rb with the following content:
Based on that configuration, you'll need the following
If your application is not configured through
ENV variables, you can substitute the token and secret in the code below however you like.
The instructions above are great for your laptop and even staging environments, but for production we recommend syncing using webhooks.
Using webhooks means that your app is entirely disconnected from Cloud for reads (e.g.
enabled?). Your app will only communicate with Cloud for writes (e.g.
disable). This ensures that your availability is not tied to ours, which is always a good practice for external services.
Add a new production webhook in Cloud. The webhook URL can be anything, but we recommend
Once you create the webhook, you'll be taken to a page where you can get the webhook's secret.
cloud.sync_secret should be set to this value.
This mounted Rack app will receive webhooks for your app, verify that they are from Cloud, and synchronize your local adapter with Cloud.
That's it. For a dozen lines of code and a couple of clicks you get the full power of feature toggles with little to no performance impact.
We would be delighted to answer any questions or even setup a pairing session to help you get your application setup correctly. Shoot an email to email@example.com.