Rails Cookbook

Chapter 13. Hosting and Deployment

Introduction

In the past, actually deploying a Rails application has been something of a challenge. One of the reasons that deploying Rails was so much more difficult than developing with Rails is that the Rails framework has never claimed responsibility for the details of deployment. Another reason is that there wasn’t a really good way to deploy a Rails application with Apache, by far the most common web server (especially in GNU/Linux environments). The problems with FastCGI, and the lack of support for it in Apache (especially the 1.3 branch) only made a prickly problem worse.

Rails’ delay in getting an easy, reliable process for deployment hasn’t stopped it from experiencing tremendous growth and popularity, but this has undoubtedly caused a lot of frustration and hampered the efforts of many Rails beginners to bring their projects to fruition.

Finally Rails got the care that it desperately needed to make the whole situation less of a pain in the neck. For a while there, everyone was hanging on the edge of their seats, hoping that Apache developers would fix the Apache FastCGI interface that had fallen out of maintenance. While waiting for that, many people flocked to LightTPD as a promising faster/lighter alternative to Apache that also seemed to have its FastCGI interface under control.

Yet although LightTPD was a lot less painful to use with FastCGI, it was still FastCGI, and FastCGI still has problems. FastCGI processes, whether running under ...