I have the need to deploy Rails 3 apps, using RVM and gemsets, and am expecting “public” traffic (i.e. this is not an internal-only app). I also must use Apache as the public interface to my app.

I understand that Passenger Standalone can help accomplish the rails/RVM end, and I have successfully set it up in my development environment.

My question is how viable this setup is for a production deployment. Is deploying via Apache configured to ReverseProxy to my passenger-powered Rails app going to create problems? Since I'm designing the production deployment now, I want to understand if I should spend the additional time to set up Passenger connected to Apache and have that Passenger communicate with Passenger Standalone instance running my Rails app.

So, I'm looking for one of I guess three answers:

Apache Reverse Proxy to Passenger Standalone will be generally fine

You should not use the Apache/Passenger Standalone configuration, but set up Passenger on the Apache side as well

Your entire setup is just Wrong, please RTFM (and include link to "FM")

1 Answer
1

I haven't used that specific setup in production, though I've used Apache's reverse proxy for a lightly loaded site (no a different non-Passenger backend).

The only (mild) downside I found to Apache's reverse proxy was that if it detected the backend being down, it would take a short while after the backend was restarted before Apache would start forwarding requests to it again.

If you have the ability to configure the Apache server for Passenger, it's not difficult to do, and once configured you don't need to administer Apache any more than before (other than for Passenger updates). When you update your Rails app, simply touching the tmp/restart.txt file will restart the Passenger instance.