December 14, 2008

Posted by John

Tagged passenger

Older: When You Don't Know, Test

Newer: Deploying Sinatra on Dreamhost With Passenger

Deploying Rails on Dreamhost with Passenger

When I saw Wanstrath tweet about being impressed with Passenger on Dreamhost, it reminded me that I should post about my experiences. I have a few small Rails apps running on Dreamhost and I have been pretty satisfied with both the results and how easy it is to go from nothing to deployed.

The prerequisite of this article is Git’n Your Shared Host On, as you’ll need to have your code in source control in order to deploy nicely with the Capistrano file I provide below.

There are three steps. Create your site, capify your app and deploy. Once you have done this a few times, it will only take a few minutes to do all of these steps, but if you are new to any of this, don’t get frustrated if it takes you a few hours. Each time it will get a little faster.

1. Create Your Site

The first thing you need to do is create your site using the DH panel. Once logged in, click on “Domains”, then “Manage Domains” and then “Add new domain / sub-domain”. There are two differences between hosting a Rails app on Dreamhost and a PHP app.

  1. Make sure you check the box for “Ruby on Rails Passenger”.
  2. Specify your web directory as

See Figure #1 below for a screenshot of these two highlighted. Note: If you do not set current/public as your web directory you will experience epoch fail (that is epic for programmers).

Add Domain ScreenFigure #1: Adding a Domain in DH’s Panel

There is kind of a third important thing worth mentioning as well. Whether you select an existing user or create a new one, be sure to update the user to shell access in the “Users” area if it does not already have those privileges.

Because you set your web directory to current/public, Dreamhost will automatically create that folder for you. Be sure to ssh into your server and remove the current directory (rm -rf current), so that Capistrano can appropriately use it as a symlink to the current version of your app.

2. Capify Your App

Now that the site is created, it is time to setup and configure Capistrano. cd into your app’s directory and run capify like so:

$ cd yourapp
$ capify .

This adds a Capfile in the root of your project and deploy.rb in config/. Open up config/deploy.rb and you can use the following deploy file that I’ve used on several DH Rails apps.

default_run_options[:pty] = true

# be sure to change these
set :user, 'username'
set :domain, ''
set :application, 'yourapp'

# the rest should be good
set :repository,  "#{user}@#{domain}:git/#{application}.git"
set :deploy_to, "/home/#{user}/#{domain}"
set :deploy_via, :remote_cache
set :scm, 'git'
set :branch, 'master'
set :git_shallow_clone, 1
set :scm_verbose, true
set :use_sudo, false

server domain, :app, :web
role :db, domain, :primary => true

namespace :deploy do
  task :restart do
    run "touch #{current_path}/tmp/restart.txt"

This deploy file works with the git setup I mentioned previously. See how simple that cap file is? Just configure your user, the app’s domain, and your application name and you are good to go. The key to making this work on DH is the redefinition of the deploy:restart task to touch the restart.txt file.

3. Setup and Deploy

Once you have the site created in DH’s panel and capified your app, all you have to do is run Capistrano’s setup and deploy commands.

$ cap deploy:setup
$ cap deploy:migrations # to deploy and run migrations

That is it. Your app should be up and running now. Don’t be afraid if something doesn’t work perfect the first time. The best thing you can do is really dig in and attempt to figure out why it isn’t working. Deployment is really easy with Rails, Dreamhost and Passenger, but it might take you a few times to really understand and learn how to troubleshoot.


  1. Sure it is easy to deploy but how often do the mongrels mysteriously stop?

    I ditched a different shared host because every couple of days they would kill off all my processes and then give me some mumble jumble excuses about making server changes that didn’t change the fact that they kept taking my site down.

    Switched to a slice and now I control it all.

  2. Firstly, it doesn’t use mongrel at all. It uses Phusion’s Passenger. Secondly, I wouldn’t recommend it, if I hadn’t already had luck with it.

    Shared hosts are obviously no match for virtual and dedicated hosting, but if you are looking for something on the cheap side, Dreamhost is actually pretty good, and by far the best I have found.

    At the time of this comment, Railstips itself is actually running on Passenger and Dreamhost if you need direct evidence that it works just fine.

  3. @srb did you read the title of this post? He’s using Passenger, not mongrel…

  4. Yeah, I’m a dork. I meant to type processes but since I mostly use mongrel that’s what I typed instead.

    I just had such an awful experience with a different, but recommended, shared host that I was wondering if dreamhost & passenger was actually worthwhile or if passenger on dreamhost was a just a way to make the best of bad option.

    I really haven’t looked into passenger but after reading the “criticism” that it was (only) good for running multiple low traffic sites at once (and the phusion rebuttal) I was considering looking into it since that fits some of my needs.

  5. Fadhli Rahim Fadhli Rahim

    Dec 14, 2008

    Cool stuff. How’s the site running? Did you had any hiccups on dreamhost?

  6. @srb – Now worries. Previously, you probably had fcgi on a shared host. I will be the first to jump on the wagon to say that fcgi on a shared host was hell. Passenger is pretty click and kudos to Dreamhost for supporting it. It’s not just the best of an awful option, it is actually pretty decent.

    @Fadhli – All the sites I’m using have been working just fine. There is some obvious slowness as passenger spins up your app on the first hit after a cool down but after that it is fast enough.

  7. Thanks for this writeup John! Being a DreamHost customer for 2+ years, I wanted to try this out ever since passenger came out – I have no excuses now I guess :)

  8. An important step that made things a little easier for me is to make sure you’re freezing rails and any other gems you need in your app, that way you don’t have to depend on DH to supply it.

  9. Oh my, you posted this just as I needed it. Thank you so much!

  10. This is a great write-up. Followed it and things are working fine, except I don’t seem to have any logs. In the current dir ‘log’ is a symlink to ../shared/log , but nothing gets written there. In fact the file doesn’t exist.

    Any thoughts? Do I have to turn logging on for a production app?

  11. Fixed my problem – I needed to create a log directory in the shared directory and give it appropriate permissions. Then I uncommented the line

      # config.log_level = :debug

    in environment.rb to increase the level of logging for the production environment (I’m using DH as a staging server)

    Apologies for the double post.

  12. @Chris – Yep, you have to have the log directory. Note for others: you don’t need to change the log level unless you just want it to be more verbose like Chris.

  13. Hi John,

    Thanks for this post, I’m looking forward to Capistrano bliss. I’m a bit hung up on a problem here. When I attempt to deploy:migrations I get the error “host key verification failed.” Here’s the output:

      * executing "if [ -d /home/akahn/ ]; then cd /home/akahn/ && git fetch  origin && git reset  --hard dacbccce8cafaaae242e852828c58efb88fe9660; else git clone  --depth 1 /home/akahn/ && cd /home/akahn/ && git checkout  -b deploy dacbccce8cafaaae242e852828c58efb88fe9660; fi"
        servers: [""]
        [] executing command
     ** [ :: out] Initialized empty Git repository in /home/akahn/
     ** [ :: err] Host key verification failed.
     ** [ :: err] fatal: The remote end hung up unexpectedly
     ** [ :: err] fetch-pack from '' failed.
        command finished
    failed: "sh -c \"if [ -d /home/akahn/ ]; then cd /home/akahn/ && git fetch  origin && git reset  --hard dacbccce8cafaaae242e852828c58efb88fe9660; else git clone  --depth 1 /home/akahn/ && cd /home/akahn/ && git checkout  -b deploy dacbccce8cafaaae242e852828c58efb88fe9660; fi\"" on

    Any guess as to what the problem could be here?

    Thanks again,

  14. @akahn – you probably just need to ssh to the server and answer yes to the question when it is asked. Either that or remove the host from your ~/.ssh/known_hosts file.

  15. Hey John, I deleted that entry from known_hosts and that made the Capistrano deploy script ask me yes/no to add the host. I said yes, but still got the same error. What else should I try looking into?

    One thing that catches my eye is that in the last line of the messages I posted above is that git is fetching from origin. But what is origin for this repository? It’s fetching from another repo on the DreamHost server, right?

    Thanks again,

  16. Hi,

    First of all Thank’s a lot for your tutorial, it’s very clear and consise; I’m having the same problem as akahn. Did what’s recomended about removing known_hosts and still is not working.

    I’m using ubuntu 8.04 as a particular configuration (I Guess?)

    I would appreciate any more help about the problem.

    Sorry about the other blank message !


  17. Hi,

    I’m glad to let you know that my application is working(well, at least the initial deployment). What I did i that I compile an updated version of Git and installed in my /home/username/bin directory.
    The version that was installed is the
    Make sure to change the PATH for getting the version that you updated running in your process.

    Saludos y Gracias !


  18. @akahn It is possible that you have an older version of git on your server as @untaldouglas mentioned. I get this:

    $ git --version
    git version

    I’ve had to ssh to the server and remove the cached copy before.

    rm -r /home/akahn/

    Also, if nothing above helps, try doing a simple git clone into your shared directory to see if that works.

Sorry, comments are closed for this article to ease the burden of pruning spam.


Authored by John Nunemaker (Noo-neh-maker), a programmer who has fallen deeply in love with Ruby. Learn More.


Release your software more often with fewer problems.
Flip your features.