Dr. Dobb's is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Channels ▼

Nick Plante

Dr. Dobb's Bloggers

New Rails Deployment Options

April 15, 2009

Deployment options for Ruby on Rails applications have come a long way over the past two years. Although many high-volume production hosts continue to run on a Mongrel-based infrastructure, fronted by a high-speed web server such as Nginx, the release of Phusion's Passenger (mod_rack) Apache module last April was a real game changer for a lot of people, particularly in terms of lowering the barrier to entry for indie developers and small startups.

With deployment of simple Rails or Rack-based web applications reduced to a dependency on a simple Apache module, even low-end commodity webhosts like Dreamhost found themselves capable of offering basic shared hosting for Rails applications, which of course made the whole platform more accessible to new developers. More serious players, including 37 Signals, made the switch as well. In no time at all, it seems, Apache and Passenger has become the defacto deployment strategy for the majority of Rails-based web apps.

Today, on the anniversary of the first release of Passenger, the Phusion guys have announced the availability of a comparable Nginx module (sponsored by Engine Yard, who are also offering this as part of their 'solo' product offering). This is really awesome news if you were one of the folks who really loved Nginx, but moved back to Apache for ease of deployment reasons. The release makes using Nginx with Rails applications just as easy as using Apache, and their updated 2.2.0 installer will even build and install Nginx from source for you! A slick screencast produced by Peepcode demonstrates just how easy this is.

So, with Passenger on Apache now the most common deployment option for Rails, I have to wonder if we'll see a mass-migration back to the once-greener fields of Nginx? The tiny little web server does offer some advantages over Apache, but performance-wise the general consensus seems to be that there isn't really much difference. Of course, the most important differentiator is your own comfort level with the technology in use; so there are certainly developers who will prefer Nginx due to its syntax and simplicity. Either way, it's nice to have options.

Speaking of options, there's also Heroku, a Y-Combinator company focused on making Ruby-based applications still easier to deploy. Heroku provides a cloud deployment platform and an enticing pure-Git workflow. Although it's somewhat constricted environmentally (as any cloud deployment service would be), it's evolving quickly and being used to build some impressive applications. In March, Heroku unveiled support for any Rack-based framework, meaning that Sinatra, Waves, Ramaze and other frameworks can also run on their servers now. It's definitely worth a look, and not entirely dissimilar to the kind of service offered by Google App Engine.

App Engine itself, of course, isn't capable of deploying native Ruby applications. However, Google did recently announce early support for Java (JVM)-based applications. This means that it is now technically possible to run Rails-based apps on it via JRuby. But not easily. At least not yet. This could all of course, change quite quickly.

 So that, in a nutshell, is a quick update on the state of Ruby web application deployment options. We've come a long way, baby. And as mentioned, there's certainly nothing wrong with maintaining clusters of Mongrels either. In fact, many of the largest Rails hosts on the web are sticking with this solid strategy, and it's also been embraced by the EC2 on Rails project, which is one of the projects making it easier to run Rails on Amazon's EC2 infrastructure. I'm happy to see so much innovation continues to be made in this area, and hope that things continue to progress. The easier it becomes to deploy and scale Ruby-based applications the better it'll be for all of us.

Related Reading

More Insights

Currently we allow the following HTML tags in comments:

Single tags

These tags can be used alone and don't need an ending tag.

<br> Defines a single line break

<hr> Defines a horizontal line

Matching tags

These require an ending tag - e.g. <i>italic text</i>

<a> Defines an anchor

<b> Defines bold text

<big> Defines big text

<blockquote> Defines a long quotation

<caption> Defines a table caption

<cite> Defines a citation

<code> Defines computer code text

<em> Defines emphasized text

<fieldset> Defines a border around elements in a form

<h1> This is heading 1

<h2> This is heading 2

<h3> This is heading 3

<h4> This is heading 4

<h5> This is heading 5

<h6> This is heading 6

<i> Defines italic text

<p> Defines a paragraph

<pre> Defines preformatted text

<q> Defines a short quotation

<samp> Defines sample computer code text

<small> Defines small text

<span> Defines a section in a document

<s> Defines strikethrough text

<strike> Defines strikethrough text

<strong> Defines strong text

<sub> Defines subscripted text

<sup> Defines superscripted text

<u> Defines underlined text

Dr. Dobb's encourages readers to engage in spirited, healthy debate, including taking us to task. However, Dr. Dobb's moderates all comments posted to our site, and reserves the right to modify or remove any content that it determines to be derogatory, offensive, inflammatory, vulgar, irrelevant/off-topic, racist or obvious marketing or spam. Dr. Dobb's further reserves the right to disable the profile of any commenter participating in said activities.

Disqus Tips To upload an avatar photo, first complete your Disqus profile. | View the list of supported HTML tags you can use to style comments. | Please read our commenting policy.