steve.blog

We've been developing client applications with Rails for a few years now. We're not really a hosting company, but our love of Rails meant that it was easier to host client apps ourselves than faff around trying to get them running on their own ISP's servers. Hosting in house took that pain away.

It's worked well, but now we're running quite a few, it's getting pretty cumbersome to manage. We still manually set up mongrels for each one, define the proxy requests in apache, restart - rinse and repeat.

This is one of the reasons that I got so excited about Passenger (mod_rails).

Passenger has been getting a fair bit of press in it's short life out in the public so far and it's easy to see why. While it's not the answer to all the scaling issues that come with a web app, it's a fantastic way to simplify the deployment and hosting process, especially for shared hosts.

In the same way that we set up mongrels to fire up our rails apps and keep them running while apache sends requests between them, Passenger loads up the rails framework and our application code when a request is made.

The framework and application code are kept loaded and are shared by separate worker processes. These worker processes are started up and shutdown based on the load on the app.

The best thing about this is that it happens behind the scenes with very little configuration. Restarting your application is a 'touch tmp/restart.txt' away and the rest is done for you.

We've already started trial this with our internal applications and it'll be interesting to see how it pans out. If this means that our lives are made easier and more hosting companies consider rails, this is looks to be a very important development.