Flipper Cloud is a platform for simple, beautiful and performant feature flags for Ruby.
We make it easy to...
Flipper Cloud is built with a lot of ❤️ in South Bend, Indiana by Fewer & Faster — owned by John Nunemaker & Steve Smith. Steve leans toward the form (design) and John toward the function (code). That said, our venn diagram of skills overlaps quite a bit.
We owned a company together a decade ago where we were consultants and built a few products — including Speaker Deck. In 2011, we were acquired by GitHub. We worked there for many years — while it grew from 50 to thousands of employees.
While at GitHub we maintained their open source setup of Flipper, which served billions of feature checks a day and was one of the most stable pieces of infrastructure.
Seeing how Flipper changed the way GitHub released software was inspiring. Why not re-build it so everyone can partake? Thus Flipper Cloud was born.
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 developer 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).
Just show me the code! Ok, here is a quick example:
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.
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.
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.
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 firstname.lastname@example.org.
If you are already using the open source version of Flipper, migration to Flipper Cloud is easy since Flipper supports syncing between adapters.