For those of you that aren’t ready to take the plunge and get a dedicated server, don’t worry, you are not alone. I pondered about this for a while, but it didn’t make sense financially for me to be spending $50+ on my own space monthly just to run a simple blog. I thought I was in great hands as I had MediaTemple Grid-Service hosting, meaning I had my own Ruby on Rails container that I could modify to my needs. I was wrong, read on.

Deploying Ruby on Rails application

RoR creates a lot buzz because of how it saves the developer time by taking care of most mundane tasks one would normally have to do manually if they were coding in say.. PHP. That is totally true and being a brand new convert (and an old PHP coder), I can see that. In the amount of time I was able to code this blog engine, I would still be figuring out database stuff in PHP.

Deploying those easily built apps is quite another story though. It often takes hours just to get the server setup the way you need it to be. Development setup on a local machine is usually quite different than what web hosting production servers have, especially shared hosting accounts.

I spent about 4-5 hours just trying to get everything working on (mt) hosting, only to realize how horrible their support is in such things. They guide you through setting it a test application and if it works, they won’t lift a finger helping you to setup your own app, which will require a much different setup than a default “hello world” Rails application.

I finally was able to get everything working only to find out how horrific loading speeds were (think 30-40 seconds per page). Also, after 5 minutes of starting the Rails application, I would randomly get proxy errors no matter what.

Goodbye MediaTemple. Hello TextDrive

Following Richard’s suggestion, I checked out TextDrive shared hosting accounts and got sucked in right away primarily by their huge support system that includes extensive help topics, manuals and most importantly, user forums that cover pretty much everything. With such a support system behind me, I knew I’d have no problem setting everything up on TextDrive.

So, $40 later and few more hours of work, Youtilize.com was finally up and running with exceptional speeds, much greater than those you can ever get on (mt)’s Grid-Service (unless you upgrade you Ruby on Rails container: $25 and MySQL container: $20 at which point just get a dedicated!).

Gems on Shared hosting

Ruby uses cool little things called Gems, which is a standard format for distributing Ruby libraries (think plugins). Source

That is all good and well, except that one cannot install those manually on shared accounts. Some hosting companies will install some gems for you as per request and all come with a wide array of pre-installed Gems for your use, but even then, if versions differ from those Gems that you have installed locally, things may (and in my case did) break.

Another solution: extract Gems into your application. Yes! Since a Gem is more or less a system-wide plugin, you can make a local install of this plugin just for your app (/vendor/ directory).

Because Rails itself is a Gem and TextDrive’s Rails versions is 1.1.6 (my app is made with 1.2.3), I simply couldn’t run my application on their server until I found out you can embed the framework you’re running your app on, inside your app. Weird? Yes, but so damn useful. On your local machine, simply run:

rake rails:freeze:gems

This will ‘freeze’ or extract your current Rails version right into your application. After further research, I found out that this a recommended step with any application in production. Since hosts usually like to keep things up-to-date, they may upgrade Gems at their own will and that MAY break your application. Source

Then simply upload directory called /rails/ in your /vendor/ directory to the server and restart Ruby.

Freezing other Gems

Now that you’ve learned how to extract Rails itself from its Gem into your own application, you may want to extract other custom Gems that your app uses and your host doesn’t have.

There are two ways to do so, a RubyGem way (try first) or the custom way by NubyOnRails.

1: RubyGem way: gem unpack

This is the easiest of the two ways and should be tried first.

On your local machine, first go into the /vendor/ directory of your app by running cd vendor and then execute the following to unpack the gem directly into your application:

gem unpack GEM-NAME

Don’t forget to replace GEM-NAME with the Gem you’ll be needing (for example: RedCloth)

This will simply unpack the Gem into your /vendor/ directory and from now on, your application will only use the unpacked Gem unless you delete the folder. Rails is setup to check there first, server second for Gems.

2: Second way

To freeze/unpack the Gem this way, you will need to download a small file called gems.rake (extract this first) and place it into your /lib/tasks/ directory. Source with more info

Then, open the file up in your favorite text editor and edit the following line with those Gems that you need extracted:

libraries = %w(gruff sparklines pdf-writer)

In other words, replace example Gems gruff spakrlines pdf-writer with for example: acts_as_taggable acts_as_ferret if you want those two extracted.

Finally, in console, execute:

rake freeze_other_gems

And it will grab all the specified Gems and throw them into your /lib/ directory. Simply upload the new files and folders and voila, you’re all set.

A note on unpacking/freezing gems

While most Gems can be unpacked directly into your application, not all are. Specifically, those Gems that require native extensions (such as the useful Ferret Gem) cannot be frozen.

Other randoms

If you want to test something out in the Ruby console on the server, don’t forget to run it under production mode!

ruby script/console production

Easy way to setup your database is to first create a schema of your development database on local machine. By executing the following, a file called schema.rb will be created in your /db/ directory:

rake db:schema:dump

Now, upload this file to the same location on your remote production server and execute (this time, on remote server):

rake db:schema:load RAILS_ENV=production

RAILS_ENV=production is super important as that tells the program to use Production database credentials, not Development.

Same goes to migrating database changes on the server. Once you’ve created new Models and thus new database changes, upload new contents of /db/migrate/ folder and run:

rake db:migrate RAILS_ENV=production

You’re all set

Go out there and conquer the world! If you make something cool, please do share.

Next up: Learn how to deploy your new application with Capistrano.