I recently signed up on a shared hosting plan for playing around with Ruby on Rails apps. I finally had an app roughly together, and I wanted to test out my deployment using Capistrano. I was able to configure my deploy.rb file so everything uploaded correctly, and figured that was the hardest bit. Little did I know that my biggest challenge was getting gems to work. Now to be fair, I haven’t been doing Rails day in and day out like ASP.NET, so it could just be me being naive, but that didn’t seem to be the case.

The Problem

So after the deploy, I went to start up the application using cPanel. I hit the big Run button and got the “The following Ruby on Rails application was started: myapp” message, but when I went back to the Rails section of the cPanel, of course myapp wasn’t running.

Off to the logs where mongrel.log gave me the error “Missing these required gems.”  Duh. I had specified the gems I needed in the environment.rb file using the config.gem method, so I could just do a rake gems:install to fix that. Awesome… err…  not so much. Went to start the application again in cPanel, same deal. The real annoying bit was I got the same “Missing these required gems” message as before. Commence with beating ones head against the wall…

Research (a.k.a Bang, Bang, Bang)

So off to Google I went typing in just about every combination of terms that I could think of and I kept coming up with the same forum posts over and over. The theme, exactly my issue. Lots and lots of trouble with shared hosting, cPanel, and gem issues. There were some reoccurring themes in all of them:

  1. Set the ENV['GEM_PATH'] in the environment.rb file (more on this in a minute)
  2. Set the GEM\_HOME and GEM\_PATH environment variables in .bashrc.

Basically, with shared hosting you have your own local instance of your gems (while some are shared by all, like Rails itself). So it would make sense to tell Rails where the gems are located. Well I tried setting both of these over and over, in different places, no go… back to Google :(


After going through just about every thing I could find on the web, I came across a blog post on the Phusion Passenger blog. Lucky too, because I almost didn’t look at it since my host uses Mongrel for Rails hosting. I was simply missing one line. One line in environment.rb caused me a ton of grief. Of course, now that I know what to look for, I came across other things on the net. Long story short, I’m not sure what pieces you actually need, but I know the one line that fixed it…  Gem.clear_paths.

The Solution

Well the first thing that helped me out (probably the best since all the information is in one place), is an article on the A2 Hosting Wiki. Another helpful link was on stackoverflow. Again, I’m not sure how much of this you actually need. And finally the link that ended my search (about a quarter of the way down the page under Setting GEM_PATH, the RubyGems search path). Here’s what did it… I added a config/preinitializer.rb file with the contents:

# NOTE: /home/[username]/ruby/gems is the path for my host, but it may be different for you
ENV['GEM_PATH'] = '/home/[username]/ruby/gems:/usr/lib/ruby/gems/1.8'

You could also add those lines to your environment.rb file, but preinitializer.rb worked better for me since it was host/environment specific. If I wanted to deploy my site to production somewhere else , then I wouldn’t have to change the actual environment file each time. With this approach, I can just not deploy the preinitializer.rb file if I don’t need it. I don’t believe this setting works within the environment specific files (e.g. development.rb, production.rb, etc) since these run after the environment.rb files where all my config.gem lines are. That said preinitializer.rb runs before the environment.rb file so it just seemed win-win for me.


If you’re running into the same issue with your host, I would start with those two “magical” lines above before digging into any .bash_profile or .bashrc, or even the .gemrc files. I would be interested to know if you really need any of the .bash* file settings at all, but they’re not hurting anything, so I don’t really feel like stripping all of that out in my instance.