Using with Rails

  1. Installing Vanity
  2. Configuring Vanity
  3. Test Environment
  4. Unicorn and Forking Servers

Installing Vanity

Rails 3.x and 4.x:

Add Vanity to your Gemfile:

gem "vanity"

Configuring Vanity

Configuring identity

Once the gem is setup, enable Vanity in your ActionController:

class ApplicationController < ActionController::Base
  use_vanity :current_user
end

This example assumes you have a current_user controller method which will return a consistent value for each user.
There are other ways to identify people as well, you can read more about the options in Managing Identity.

Enabling/disable collection

When collection is off, Vanity doesn’t connect to the database server, so there’s no need to set a database configuration for these environments.

Overriding default views

If you would like to customize Vanity’s dashboard, you can create create copies of the default views in app/views/vanity by running a generator:

rails g vanity:views

You can then edit them to your heart’s content. If you need to use an alternative location for your custom templates, set the configuration variable custom_templates_path on Vanity.playground like this:

Vanity.configure do |config|
  config.templates_path = 'views/vanity'
end

Unicorn and Forking Servers

Unicorn forks the master process to create worker processes efficiently. Since the master processes opens a connection to the database, all workers end up sharing that connection, resulting in ugly contention issues.

The cure is simple, use the after_fork hook to reconnect each worker process. Here’s the relevant part from my config/unicorn.rb:

after_fork do |server, worker|
  ActiveRecord::Base.establish_connection
  Vanity.playground.establish_connection
end

You’ll run into this issue with other forking servers like Passenger as well.