Welcome Guest | Login

Overview of Common Ruby on Rails Deployment Mistakes



This is a wiki article created by HostingRails users. Please login or signup to make edits.


We've noticed that deployment problems usually occur because of one or more of the following reasons:  

The whole application is uploaded

This usually renders the Shebang line of the dispatchers incorrect.  Check out this thread to learn how to identify and fix it.  Essentially, make sure the basic app shell is created on your production box.  

Incorrect database configurations

Either the database user not assigned to the Database, or the database.yml does not accurately report the database name and/or username.  Often because of a lack of the [AccountUsername]_ that our system automatically adds as a prefix to usernames and database names to keep things organized on a shared server.

Incompatibility of Rails versions

If you developed on 1.1.x and the server is at 1.1.y, for example, you need to download your needed Rails version and freeze it. Click here to learn how to do this - or here for more troubleshooting help.  

A specific gem is needed or not required correctly

 This can cause 500 internal server errors.  Click here to learn about proper gem installations and to find more troubleshooting aid.

Permissions issues

  Usually if app is uploaded in a non-'regular' fashion (i.e. with a non-optimized capistrano or something).  Click here to learn what the permissions should be...  

A typo occurred along the way

Usually somewhere in environment.rb or database.yml

Essentially, if someone emails in with a "My app doesn't work - help" sort of question and they cannot produce any error messages, we'll ask for the following files to be passed along:  

  1. The environment.rb file (passwords and such removed)

      We check for Rails version discrepancies or bizarre includes.

  2. dispatch.fcgi
  3. dispatch.rb

      Essentially just check the shebang line to make sure an obvious c:\ruby... or something isn't there and that the file was indeed generated by the server and not by the client's local machine.

  4. .htaccess

    To make sure the dispatch.fcgi rewrite is in there, the rewritebase is over the rails rewrite rules (if used), and no other bizarre rewrites or anything are preventing requests from being sent to Rails.  

  5. database.yml (passwords and such removed)

    To make sure that the production database actually exists and the user is assigned to that database.

lingering puts

Make sure you don't have any puts in your rails code that you might have used during development:
  • $stderr.puts 'here i am' works, but a plain
  • puts 'here i am' will give you a 500 error.
  • print 'here i am' will make the page being rendered be displayed as raw html.
Having 'Rails application failed to start properly'

You still have this message instead of your site? Nothing in the rails log? Only a '... started' followed by a '... terminated' in the errors log?

Yes this may happen, it is certainly a startup problem on your site. To track it down open a shell, go to your public folder and type:

  ruby dispatch.fcgi

This will manually run your site and will show you what goes wrong (an exception somewhere in the code). Read carefully what is printed here and go debug it ;-)

Note that this only bootstraps your site but WILL fail with 'Error 500' and an entry in your log with something like 'no downcase method for NilClass'. This is because you are not in a fastcgi context.


This information covers about 99% of Ruby on Rails deployment troubles.  You can browse through specific error resolution threads using this portal page .



Hello Guest! In order to edit this article you must be an active client with us, please log in or sign up today!





Contributing Author(s):
William
Jazzhermit
Jeremedia
Pascal