Rails And Shared Hosting

January 12th, 2008

Just found and read David Heinemeier Hansson’s post on The deal with shared hosts, and Dallas’ from Dreamhost posts on How Rails Could Be Better and his riposte. All interesting.

And, it turns out, pertinent to my own situation, as I’m currently using Dreamhost’s shared hosting, and trying to run Rails on it. This blog is the only “real” Rails app I’m running, and I didn’t write any part of it. I’ve started doing my development on my own local machine (as it seems to make a lot more sense to do it that way), but I’m obviously going to want to eventually deploy what I write to the server.

Now, with only one real exception, I’ve had little trouble with Rails on Dreamhost. Everything has mostly “just worked”. This blog stopped working for a bit, but it turned out that all I probably really should have done is re-run dispatch.fcgi.

So on the one hand, we have a group saying “Rails should be easier to run on shared hosting.” On the other hand, we have a group seeming to say, “Real Rails developers don’t use shared hosting.” (To be fair, what Hansson really said was that he’d love to see Rails run well on shared hosting and that the Rails team would happily cooperate with anyone wishing to work on that challenge.)

I’m reminded of a quote that stuck with me; it’s from Hansson’s keynote at RailsConf 2006. (emphasis added)

I don’t really think Rails currently is in a position where it should bend to the outside world. I think we’re actually working very well at bending the outside world to us.

I’m not going to try to defend or condemn that statement. Rather, I’m going to suggest that an “opinionated” framework, like Rails, would not be possible without that sort of attitude. Like it or not, I’m not sure Rails would be what it is without it.

So yes. Let’s have people who are interested and capable looking into the issue of improving the performance of Rails in shared hosting. The hosting companies will like it, and from Hansson’s post it’s clear that the Rails core team will welcome such improvements as well.

But let’s not think that Rails developers should drop everything and work on a problem which is not really “their” problem.

If you want to be able to install gems locally on a Dreamhost shared hosting plan, you should be able to do it. You’ll need to set some environment variables; here’s what I’ve done.

If you try to install a gem in your dreamhost shared hosting account, you’ll get a permission denied error. That’s because rubygems is trying to put the gem in /usr/local/lib/ruby/gems/1.8/ and, I’m sorry, but you can’t write to there. Now, you can do this:

[your-DH-server]$ mkdir ~/mygems
[your-DH-server]$ gem install some_gem --install-dir ~/mygems

This will let you install a gem, but there’s still a problem: rubygems is not going to be able to find the gems you install in that directory. You could change the GEM_HOME environment variable to point to ~/mygems (or whatever you want to call your gem directory), but that would be a bad idea: rubygems would no longer be able to find the gems that are already on the Dreamhost server (and there are quite a few). Also, GEM_HOME (as I understand it) should only point to one gem repository. However, there is another environment variable, GEM_PATH, which can have multiple directories in it. So, we’ll do this:

[your-DH-server]$ echo "export GEM_HOME=/usr/local/lib/ruby/gems/1.8/" >> ~/.bashrc
[your-DH-server]$ echo "export GEM_PATH=$GEM_HOME:~/mygems" >> ~/.bashrc
[your-DH-server]$ echo "source ~/.bashrc" >> ~/.bash_profile
[your-DH-server]$ source ~/.bashrc #just so you don't need to log out and back in for ENV to change

Basically, what you just did is tell bash to set a couple environment variables as soon as you start a new shell, ie, any time you log in with ssh, for example. By setting GEM_HOME first, and adding it to GEM_PATH, you make sure that all Dreamhosts gems will still be findable. So will yours.

Now, other than to confirm that this all seems to work, I haven’t tested this extensively, yet. Use at your own risk.

I believe you can also put libraries which would normally be installed as gems into your vendor/ directory in your Rails project — Mephisto does this, for example. Presumably, this is to make Mephisto easier to install — they don’t need to have a long “howto” about installing various plugins or gems before Mephisto will work.

I started out wanting to talk about Rails on shared hosting in general, but I’ll save that for another post. If this post was helpful or interesting, please consider leaving some feedback in the comments. Also, if I have anything wrong, or if what I’ve suggested could cause some other problem that I haven’t considered, please let me know!