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.