Background: I have viewed this question as well as this one - sadly, to no avail.

Error Message (Passenger): You have already activated rack 1.1.0, but your Gemfile requires rack 1.2.1. Consider using bundle exec.

my Gemfile:

source 'http://rubygems.org'

gem 'rails', '3.0.0.rc'
gem 'nifty-generators' 
gem 'nokogiri'
group :after_initialize do
 gem 'feedzirra'

my Gemfile.lock has this line:

rack (1.2.1)

my environment.rb has this line at the top:

ENV['GEM_PATH'] = File.expand_path('~/.gems') + ':/usr/lib/ruby/gems/1.8'

my boot.rb has this line at the top:


I have rack (1.2.1) installed correctly locally - my app runs fine on my local host and version 1.2.1 shows up following a "gem list" in the terminal.

I have packaged my gems with a "bundle package" before pushing my app to my production server.

I have run the following command (on my production server, from the root of the app) before deployment:

bundle install --path vendor/bundle --local

Following the install command above, a "bundle check" returns this:

The Gemfile's dependencies are satisfied

And this is the backtrace provided by passenger (along with the Error Message mentioned above):

0   /home/bbahry/.gems/gems/bundler-1.0.0/lib/bundler/runtime.rb   27   in `setup'
1  /home/bbahry/.gems/gems/bundler-1.0.0/lib/bundler/spec_set.rb  12  in `each'
2  /home/bbahry/.gems/gems/bundler-1.0.0/lib/bundler/spec_set.rb  12  in `each'
3  /home/bbahry/.gems/gems/bundler-1.0.0/lib/bundler/runtime.rb  17  in `setup'
4  /home/bbahry/.gems/gems/bundler-1.0.0/lib/bundler.rb  100  in `setup'
5  /home/bbahry/gseeds.brentbahry.com/releases/20100927012812/config/boot.rb  9  
6  /usr/lib/ruby/1.8/rubygems/custom_require.rb  31  in `gem_original_require'
7  /usr/lib/ruby/1.8/rubygems/custom_require.rb  31  in `require'
8  /home/bbahry/gseeds.brentbahry.com/releases/20100927012812/config/application.rb  1  
9  /usr/lib/ruby/1.8/rubygems/custom_require.rb  31  in `gem_original_require'
10  /usr/lib/ruby/1.8/rubygems/custom_require.rb  31  in `require'
11  /home/bbahry/gseeds.brentbahry.com/releases/20100927012812/config/environment.rb  7  
12  /usr/lib/ruby/1.8/rubygems/custom_require.rb  31  in `gem_original_require'
13  /usr/lib/ruby/1.8/rubygems/custom_require.rb  31  in `require'
14  config.ru  3  
15  /usr/lib/ruby/gems/1.8/gems/rack-1.1.0/lib/rack/builder.rb  46  in `instance_eval'
16  /usr/lib/ruby/gems/1.8/gems/rack-1.1.0/lib/rack/builder.rb  46  in `initialize'
17  config.ru  1  in `new'
18  config.ru  1 

I'm wondering if anyone has come up with a solution to this?

Something that should be noted is that a sample rails app - aka, running a rails new appName and straight ftp'ing that to the production server on DreamHost - will run fine. This perturbs me as I imagine both my real app and the sample app have the rack (1.2.1) dependency; which implies to me that, in an effort to bypass the DreamHost server gems, I am somehow messing with rack's implementation in my real app.

I have my sample rails app running on a separate subdomain on DreamHost while getting this error for the subdomains of both the real apps I'm attempting to deploy.

Also, I originally attempted to install the gems locally in my DreamHost user directory before taking the vendor/cache approach. Maybe this doesn't affect anything..

Thanks for suffering through this messy/long question


DreamHost does not support Rails 3. In the sense that they have not updated some of the necessary gem versions to run a Rails 3 app and you don't really have the ability to allow your own gems to supersede the ones DreamHost has installed.

In this case, my test app was not using any conflicting gems (merely displaying the default index.html page), however any real app will and that's why none of my other rails 3 apps worked.

(I submitted a problem ticket and DreamHost told me it would be a while before Rails 3 is supported.)

A solution is to either go with a VPS (I recommend Linode) or try out Heroku. There is a chance you could find a good shared host that also supports rails 3 apps - a chance.

A VPS guarantees full control and the avoidance of scenarios like I had with DreamHost. Whereas Heroku makes deployment a fucking breeze, yet you could run into a problem later if they do not support a gem/service your app needs. Also, Heroku is expensive for what they give you in terms of server resources. I'm currently running on Linode.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.