After awhile, I figured out that my problem was due to the fact that the permissions were not set properly when I FTP’d the app over. So, I deleted the app and ran “rails appname” to generate the basic rails structure. Then I copied over my app, config, and vendor/plugins directories and the relevant portions of the public directory. After that I was up and running. Make sure not to copy the entire public directory, but only the files you’ve created or edited so that you do not change the permissions of the dispatch scripts. You could also copy everything and run “chmod 755″ afterwards to reset the permissions. If you’re getting a similar error and the steps I described did not help then I recommend checking out this page at Hoopla!

At this point I was up and running, but my app was sloooowwww. The solution I found was to modify the .htaccess file to ensure that fcgi was being used instead of cgi. Makes sense since the f in fcgi stands for fast. So, go to the public directory of your app and change “RewriteRule ^(.*)$ dispatch.cgi [QSA,L]” to “RewriteRule ^(.*)$ dispatch.fcgi [QSA,L]“. At this point, when I visited the site, I was shown the script source instead of having it execute. Turns out that FastDomain uses a different fcgi handler so change the first line of the script (“AddHandler fastcgi-script .fcgi”) to “AddHandler fcgid-script .fcgi” and your app will be blazing fast.

The most frustrating problem I experienced is that all of my Rails pages were being cached and static content was not.  This made updates to the site very difficult.  For example, if I updated a Rails page and a JavaScript file on that page then the two would be out of sync.  I haven’t found an easy way to clear the Ruby on Rails cache at BlueHost/FastDomain.  The answer I came up with was to run “ps -ef | grep ruby”, to find the Rails process that was running.  Then look at the pid and use it to kill the process such as “kill 24018″.