It's a blog.
This is what I am using to run ruby 1.9.3 on DreamHost shared hosting, regardless of the fact that by default it’s still stuck on 1.8.7. It’s based based on DreamHost’s own instructions for running a Rails 3 app, but with some improvements to isolate the DreamHost-specific parts and make it easier to figure out what’s wrong if there are errors. My application uses Sinatra rather than Rails, but I don’t see any reason why a Rails 3 app wouldn’t work with this as well. As long as it’s a Rack app that has a
config.ru like one might use with
rackup, and as long as it uses Bundler, this setup should work.
My setup has the following differences from DreamHost’s example:
error.logfile in your DreamHost
~/logsfolder will just say “Premature end of script headers: dispatch.fcgi.”) This is useful for figuring out what is wrong with a setup like this, when the code ran fine and passed all its tests on your home machine.
Rack::PathInfoRewritercode–I found that if you delete the
SCRIPT_NAMEkey from the Rack
envobject then some Rack middleware will crash. I set it to blank instead.
Before I get to the gory details, a word of warning: the code below is not what I’m actually running–I removed some extra stuff that is specific to my own app and wouldn’t be relevant here. I might have introduced some mistakes in trying to clean it up for the general public, and I haven’t tested this version. Comments or corrections are welcome (put them on the GitHub gist).
All the files below should go in your project root directory, which should also be configured as your web directory in the DreamHost panel. Usually that means if your site was
example.com and your user was
sampleuser then you’d be putting these files, along with your Rack app, into
First off, the script that will do the initial setup. Run these commands in an SSH session, after you
cd to your project root directory:
Next, set up
dispatch.fcgi. I use a shell script for
dispatch.fcgi that handles all the DreamHost-specific environment cleanup and then executes the ruby script
dispatch_fcgi.rb, which is based on DreamHost’s recommended
dispatch.fcgi. This allows me to keep the DreamHost bits out of my ruby code altogether.
Don’t forget to make your
dispatch.fcgi world-executable but not world-writable by executing
chmod 755 dispatch.fcgi.
The last part is to install the
.htaccess file that will route all the requests through
dispatch.fcgi. This was taken verbatim from DreamHost’s wiki page and is fairly uninteresting:
A word on performance: DreamHost will kill your app when it becomes idle for a while, and the next request it gets after it gets killed has to wait for it to start up. This startup penalty, for my app, was somewhere between seven and ten seconds. Once the app was started up it took between 200 and 500 msec per request, which I deemed to be good enough.