My Ruby on Rails Stack

For deploying Ruby on Rails apps to production, I’ve previously used many different tools to get an idea of what will suit me the most.

Today, I think I’ve found what I wanted, so I’d like to share this with you, as picking around on the net config files and ideas was very useful to me.

Here’s the short version : I use Nginx as the frontal web server, it will act as a reverse proxy, sending all the requests from the browser directly to a unix socket on which several unicorn workers are listening. I use capistrano to automate the deployment, based on a github (or any git) repository.

I usually create 3 instances of the same website :

production (The master branch on the git repository) pre-production (The preprod branch on the git repository) development (The develop branch on the git repository)

In fact, I have 3 config files for nginx, 3 checked-out repositories (one for each branch) and my capistrano script is tuned so it can deploy to the branch we want.

For simplicity issues, this won’t be discussed here, as I will paste you simplified config files for only one version of the website. That should be enough for small websites who don’t need such care.

However, if you’d like to know more, you can send me an e-mail (adrien at siami dot fr)

So let’s get started.


So as I said, Nginx is just acting as a reverse proxy here, the configuration is pretty straight forward :

upstream your_website_name {
  server unix:/tmp/ fail_timeout=0;

server {
  listen 80;


  root /var/www/;

  access_log /var/log/nginx/;
  error_log /var/log/nginx/;

  index index.html index.htm index.php;

  gzip on;

  location ~ ^/(assets)/  {  # Directly serve assets w/out proxying
    root /var/www/;
    expires max;  
    add_header  Cache-Control public;  

  location / {    
    proxy_pass http://your_website_name;
    include proxy.conf;


Now comes the unicorn setting, for those who don’t know, unicorn is a HTTP server for ruby on rails, he’s the one who will in fact execute the ruby code. Unicorn works with workers processes that are bound to a shared socket, you have to define a number of workers, depending on your machine and your preferences. Here is my unicorn configuration file, located in config/unicorn.rb :

# Sample verbose configuration file for Unicorn (not Rack)
# This configuration file documents many features of Unicorn
# that may not be needed for some applications. See
# for a much simpler configuration file.
# See for complete
# documentation.

# Use at least one worker per core if you're on a dedicated server,
# more will usually help for _short_ waits on databases/caches.
worker_processes 4

# Since Unicorn is never exposed to outside clients, it does not need to
# run on the standard HTTP port (80), there is no reason to start Unicorn
# as root unless it's from system init scripts.
# If running the master process as root and the workers as an unprivileged
# user, do this to switch euid/egid in the workers (also chowns logs):
# user "unprivileged_user", "unprivileged_group"

# Help ensure your application will always spawn in the symlinked
# "current" directory that Capistrano sets up.
working_directory "/var/www/" # available in 0.94.0+

# listen on both a Unix domain socket and a TCP port,
# we use a shorter backlog for quicker failover when busy
listen "/tmp/", :backlog => 64

# nuke workers after 30 seconds instead of 60 seconds (the default)
timeout 30

# feel free to point this anywhere accessible on the filesystem
pid "/tmp/"

# By default, the Unicorn logger will write to stderr.
# Additionally, ome applications/frameworks log to stderr or stdout,
# so prevent them from going to /dev/null when daemonized here:
stderr_path "/var/www/"
stdout_path "/var/www/"

# combine Ruby 2.0.0dev or REE with "preload_app true" for memory savings
preload_app true
GC.respond_to?(:copy_on_write_friendly=) and
  GC.copy_on_write_friendly = true

before_fork do |server, worker|
  # the following is highly recomended for Rails + "preload_app true"
  # as there's no need for the master process to hold a connection
  defined?(ActiveRecord::Base) and

  # The following is only recommended for memory/DB-constrained
  # installations.  It is not needed if your system can house
  # twice as many worker_processes as you have configured.
  # # This allows a new master process to incrementally
  # # phase out the old master process with SIGTTOU to avoid a
  # # thundering herd (especially in the "preload_app false" case)
  # # when doing a transparent upgrade.  The last worker spawned
  # # will then kill off the old master process with a SIGQUIT.
  old_pid = "#{server.config[:pid]}.oldbin"
  if File.exists?(old_pid) && != old_pid
    rescue Errno::ENOENT, Errno::ESRCH
      # someone else did our job for us
  # Throttle the master from forking too quickly by sleeping.  Due
  # to the implementation of standard Unix signal handlers, this
  # helps (but does not completely) prevent identical, repeated signals
  # from being lost when the receiving process is busy.
  # sleep 1

after_fork do |server, worker|
  # per-process listener ports for debugging/admin/migrations
  # addr = "{9293 +}"
  # server.listen(addr, :tries => -1, :delay => 5, :tcp_nopush => true)

  # the following is *required* for Rails + "preload_app true",
  defined?(ActiveRecord::Base) and

  # if preload_app is true, then you may also want to check and
  # restart any other shared sockets/descriptors such as Memcached,
  # and Redis.  TokyoCabinet file handles are safe to reuse
  # between any number of forked children (assuming your kernel
  # correctly implements pread()/pwrite() system calls)

before_exec do |server|
  ENV["BUNDLE_GEMFILE"] = "/var/www/"

Pretty standard, 4 workers.

One pretty neat feature about unicorn is what is called “Zero-downtime deployment”. Unicorn creates a .pid file in your /tmp folder containing the pid of the unicorn master process.

Sending a USR2 signal to this pid has a cool effect :

  • Starts spawning a new unicorn process (with the new code)
  • Once the process is spawned, assign it the shared socket that was previously used by the former unicorn workers
  • Stop the former unicorn workers

This means that your web application should never be down when doing simple deploys, the requests are still sent to the old version while the new one is booting, genius !

To boot unicorn, simply run :

RAILS_ENV=production bundle exec unicorn -c config/unicorn.rb -D #-D detaches the process in a background job

Of course you need unicorn in your gemfile, check log/unicorn.stderr.log to see if something went wrong.


Capistrano is a cool tool used to automate deployments, it works with rails applications but also with symfony and lots of others.

In the mode I’ve chosen (remote cache), capistrano keeps a copy of the 15 last releases of my website. There is a directory called current that is symlinked to the latest copy available. When deploying, capistrano will checkout the git repository in a new release folder and do some actions such as migrations, running bundle install, etc.

Here is an example of a capistrano file I might use :

# RVM bootstrap
require 'rvm/capistrano'
set :rvm_ruby_string, '1.9.3-p327-turbo'
set :rvm_type, :system

# main details
set :application, "your app name"
role :web, ""
role :app, ""
role :db,  "", :primary => true

# server details
default_run_options[:pty] = true
ssh_options[:forward_agent] = true
set :deploy_to, "/var/www/"
set :branch, "master"
set :deploy_via, :remote_cache
set :user, "adrien"
set :use_sudo, false
set :keep_releases, 15
set :test_log, "log/capistrano.test.log"

# repo details
set :scm, :git
#set :scm_username, "intrepidd"
set :repository, ""

set :git_enable_submodules, 1

# runtime dependencies
depend :remote, :gem, "bundler", ">=1.0.0.rc.2"

# tasks
namespace :deploy do

  task :start, :roles => :app do
    run "kill -USR2 `cat /tmp/ `"

  task :stop, :roles => :app do
    # Do nothing.

  desc "Restart Application"
  task :restart, :roles => :app do
    run "kill -USR2 `cat /tmp/ `"

  desc "Symlink shared resources on each release"
  task :symlink_shared, :roles => :app do
    run "ln -nfs #{shared_path}/config/*.yml #{release_path}/config/"
    run "ln -nfs #{shared_path}/config/*.rb #{release_path}/config/"
    run "ln -nfs #{shared_path}/uploads #{release_path}/public/"

  desc "Precompile assets"
  task :assets, :roles => :app do
    run "cd #{release_path} && bundle exec rake assets:precompile"


namespace :bundler do
  desc "Symlink bundled gems on each release"
  task :symlink_bundled_gems, :roles => :app do
    run "mkdir -p #{shared_path}/bundled_gems"
    run "ln -nfs #{shared_path}/bundled_gems #{release_path}/vendor/bundle"

  desc "Install for production"
  task :install, :roles => :app do
    run "cd #{release_path} && bundle install"


after 'deploy:update_code', 'bundler:symlink_bundled_gems'
after 'deploy:update_code', 'bundler:install'

after 'deploy:update_code', 'deploy:symlink_shared'
after 'deploy:update_code', 'deploy:assets'

after "deploy:update", "deploy:cleanup"

This is a simple one, I have one that handles the 3 production environments I explained earlier, and does some more stuff such as calling some tasks after the deployment is finished for restarting some resque workers, sending some mails, or some tasks before such as running the tests before allowing to deploy.

You can run capistrano by launching :

bundle exec cap deploy #use deploy:migrate for running the migrations as well

Good stuff ?

That’s it !

Thanks for reading, see you soon.