Skip to content
Feature flippers.
Branch: master
Clone or download
Latest commit ebd1724 Jun 30, 2017
Type Name Latest commit message Commit time
Failed to load latest commit information.
gemfiles Test with multiple redis versions Nov 24, 2016
lib Bump version 2.4.3 Jun 30, 2017
spec Merge pull request #123 from yossi-eynav/add_method_to_set_users Jun 30, 2017
.document Initial commit to rollout. Jul 17, 2010
.gitignore Test with multiple redis versions Nov 24, 2016
.rspec Add .rspec with color :P Feb 13, 2016
Appraisals Test with multiple redis versions Nov 24, 2016
Gemfile We don't need redis in our Gemfile anymore since we only require it f… May 15, 2014
Gemfile.lock Bump version 2.4.3 Jun 30, 2017
Rakefile Add Rakefile with default rspec task Feb 14, 2017


Fast feature flags based on Redis.

Build Status Code Climate Test Coverage Dependency Status

Install it

gem install rollout

How it works

Initialize a rollout object. I assign it to a global var.

require 'redis'

$redis   =
$rollout =$redis)

Update data specific to a feature:

$rollout.set_feature_data(:chat, description: 'foo', release_date: 'bar', whatever: 'baz')

Check whether a feature is active for a particular user:

$, User.first) # => true/false

Check whether a feature is active globally:


You can activate features using a number of different mechanisms.


Rollout ships with one group by default: "all", which does exactly what it sounds like.

You can activate the all group for the chat feature like this:

$rollout.activate_group(:chat, :all)

You might also want to define your own groups. We have one for our caretakers:

$rollout.define_group(:caretakers) do |user|

You can activate multiple groups per feature.

Deactivate groups like this:

$rollout.deactivate_group(:chat, :all)

Specific Users

You might want to let a specific user into a beta test or something. If that user isn't part of an existing group, you can let them in specifically:

$rollout.activate_user(:chat, @user)

Deactivate them like this:

$rollout.deactivate_user(:chat, @user)

User Percentages

If you're rolling out a new feature, you might want to test the waters by slowly enabling it for a percentage of your users.

$rollout.activate_percentage(:chat, 20)

The algorithm for determining which users get let in is this:

CRC32( % 100_000 < percentage * 1_000

So, for 20%, users 0, 1, 10, 11, 20, 21, etc would be allowed in. Those users would remain in as the percentage increases.

Deactivate all percentages like this:


Note that activating a feature for 100% of users will also make it active "globally". That is when calling Rollout#active? without a user object.

In some cases you might want to have a feature activated for a random set of users. It can come specially handy when using Rollout for split tests.

$rollout =$redis, randomize_percentage: true)

When on randomize_percentage will make sure that 50% of users for feature A are selected independently from users for feature B.

Global actions

While groups can come in handy, the actual global setter for a feature does not require a group to be passed.


In that case you can check the global availability of a feature using the following


And if something is wrong you can set a feature off for everybody using

Deactivate everybody at once:


For many of our features, we keep track of error rates using redis, and deactivate them automatically when a threshold is reached to prevent service failures from cascading. See for the failure detection code.


Rollout separates its keys from other keys in the data store using the "feature" keyspace.

If you're using redis, you can namespace keys further to support multiple environments by using the redis-namespace gem.

$ns =, redis: $redis)
$rollout =$ns)
$rollout.activate_group(:chat, :all)

This example would use the "development:feature:chat:groups" key.

Frontend / UI

Implementations in other languages



Copyright (c) 2010-InfinityAndBeyond BitLove, Inc. See LICENSE for details.

You can’t perform that action at this time.