Deploying on Phusion Passenger

  • published on May 13th, 2008

    A very large number of PHP developers, perhaps even the majority, are building smaller web applications. These applications receive only a moderate amount of traffic and usually have a single database server, often on the same machine.

    Deployment, or moving your application to production for use by real customers, is largely an afterthought for these small PHP applications. In many cases, decent PHP code can just be installed on the server and it runs without much trouble.

    One of the points we stress towards the back of our book is that deploying Rails applications can be more difficult than deploying their PHP counterparts. There are more moving parts and things to you’ll need to learn. Until you get the hang of it, deploying even small Rails applications can be frustrating.

    A recent development has greatly improved this situation.

    Introducing Phusion Passenger

    PHP can be deployed using a variety of server configurations. Some of these can be just as frustrating as traditional Rails deployments. However, the majority of PHP applications are still deployed on Apache using mod_php. PHP’s tight integration with Apache is simple, proven, and just works for many needs.

    Phusion is a small company in the Netherlands that recently released an open source product called Passenger (mod_rails). Passenger aims to take the complexity out of deploying Rails applications by also integrating with Apache.

    Installing Passenger on the average Linux or Mac server is usually simple. It is installed as a gem and contains an automated installer program that compiles and installs the necessary components. Once installed, many Rails applications can be deployed under Apache simply by configuring a VirtualHost for each application. The installer even outputs an example for you to copy and paste.

    Passenger gives a deployment experience closer to what we’ve come to appreciate with PHP. In the background, there’s still more moving parts, but Passenger automatically manages them. It spawns Rails application server processes, proxies to them, and largely eliminates the configuration and glue that other Rails deployment options leave up to you. Passenger has nice documentation for when some configuration is necessary.

    At Maintainable Software, we develop applications in both PHP and Ruby. We’ve been testing Passenger for a few weeks on a dedicated server and recently deployed an application on it. We have been very impressed with its reliability, performance, and easy-of-use compared to previous Rails deployment options. You should give Passenger strong consideration, especially if you’re just starting out.

    Finally, Rails on Shared Hosting

    Traditionally, deploying Rails applications on shared hosts (usually with FastCGI) has been difficult and unreliable. Due to this, many Rails applications are deployed on small VPS plans from providers like Rimuhosting and Slicehost. These run well, typically using small Mongrel cluster behind a frontend proxy balancer. However, VPS plans are usually more expensive and more work to set up and maintain than shared hosting.

    Passenger makes running Rails applications on shared hosting much better. Dreamhost, a major shared hosting provider, recently announced full support for Passenger. We tested a small Rails application on Dreamhost using it and we were impressed. It seemed to run without issues and with reasonable performance.

    Deploying some Rails applications on shared hosting may soon become commonplace.

    Thinking Ahead

    Will better Rails deployment options or Rails on shared hosting mean it’s time to switch from PHP? No. It’s unlikely this blog will switch from WordPress anytime soon and Phusion’s own blog even runs on WordPress. There are many great PHP applications out there. More importantly, sometimes PHP will simply be a more appropriate solution.

    PHP, Ruby, and Rails are all great tools you can choose from. You’ll still need to learn these tools, their relative strengths, and when it’s appropriate to apply each.

    Passenger just means Rails deployment is getting simpler and more mature. It also means deploying PHP and Rails applications together on the same Apache instance is now much easier. These are more reasons to consider adding Rails to your toolbox. It’s certainly a great time to be building web applications.

This entry was posted on Tuesday, May 13th, 2008 at 11:03 pm. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.

4 comments

  • comment by David Thompson 12 Nov 10

    Hi. Do you still feel this way about rails deployment. Are you leaning further away from PHP and towards Rails. I’m asking because I’m trying to decide between the two.

    Thanks.

  • comment by Keil Miller 23 Nov 10

    @David Ruby is a way better language than php. In fact, it’s the easiest and least error prone language I have found so far. Rails makes development easy to set up and understand.

    However, there isn’t enough support (compared to php) to have clients make the switch. I wish php would just die already, but we are in the same predicament as windows. Everyone else uses it. :/

  • comment by PHP Application Development 29 Nov 10

    Hi There,
    commercial supported open source product that enables people to deploy their Ruby on Rails applications useful for developers at deploying even small Rails applications can be frustrating.

    Thanks,
    Mick

  • comment by Michael 23 Dec 11

    what would be a good way to try rails on a small vps? (must be slim and low-latency is a must – must also play nice with an existing site on the same server (mostly php and perl – I would drop the idea quicksmart if I were to be told that i would have to significantly alter configs for php or other critical stuff used by the current site) … maybe a fastcgi daemon? … what sort of memory requirements would I be looking at ?

Post a comment


We welcome your participation but please note we reserve the right to remove any comments that we think are not relevant or do not contribute to the discussion.