A couple of months ago, I had to scramble to find a new hosting company for my wife’s ecommerce site that I had built on Rails.
My former hosting company performed a rather disastrous major upgrade and “move to the cloud” with no workable back-out plan and little expertise in Rails. The end result was that they were forced to officially drop support for Rails apps after three days worth of failed attempts to make it work.
Although Rails is arguably one of the easier platforms to develop on, it is apparently much more difficult to deal with from a hosting perspective.
It didn’t help matters that I was the only customer they had who was actually using Rails (I didn’t find this out until the end). It’s little wonder that they had no expertise in the area and little financial incentive to remedy the situation.
When I set out to find a new hosting company, my first order of business was to find someone with lots of experience hosting Rails apps.
With over 58,000 apps in production (at least according to the marketing hype), Heroku.com definitely met my criteria. Of course, it didn’t hurt that they host sites with simple configuration needs like my own for free.
After several months of using it, I’ve got nothing but positive things to report.
While low cost and high expertise are definitely still huge selling points for me, I think I am most impressed with the deployment story.
Thanks to a nifty heroku gem, I can now deploy my application by simply issuing a few commands after doing a commit to my git repository.
To deploy code, I use the heroku gem in combination with a simple git push.

For database changes, I use the gem to execute my newly committed migration files against my remote database.
1: C:\> heroku rake db:migrate
I love that I can now do a full deployment without ever leaving my command window.
My old hosting site required me to open an ftp program and a browser and then spend dozens of clicks in order to manually select what I want to upload and execute.
Besides being incredibly tedious, the chance for error was significant.
I have to admit that it is occasionally disconcerting not to have direct access to view the files or data (although plugins and commands exist to download the current version of both). However, this streamlined deployment process makes it totally worth it. It’s a perfect case of appropriately optimizing for the 95% usage scenario.
The only heroku requirement that ended up costing me any work during the migration process was on the database side, since Heroku requires PostgreSQL and my app was running on MySQL.
I have to admit that I almost abandoned my plans when I first found out that it would require switching databases, but I was pleasantly surprised at how little work was actually involved thanks to the level of abstraction offered by ActiveRecord and Migrations.
I think I only ended up making about a dozen code changes to my various queries and it turned out that all of those could have been avoided if I had been smarter about how I formed the queries (not embedding boolean values directly into the condition parameters).
The only other stumbling block for me was learning to use git, but up until recently I got by with only learning a handful of commands and still relying on svn to be my central repository. It wasn’t ideal, but it helped me to smooth out the up front learning curve.
In summary, if you are looking for a new home for your Rails app, then I highly recommend checking out heroku.com.
Popularity: 1% [?]