From Stackoverflow: Difference of Apache-Nginx-Mongrel-WEBrick- Phusion passanger – Capistrano


As a newbie to Ruby on rails, i often came across this names and have a huge confusion on knowing all this. But the great article from stackoverflow members, i got a clear cut of all this with difference. Thanks to

Am not taking credits to this article. I feel sharing this which may be useful and i too can have backup.

The word “deployment” can have two meanings depending on the context. You are also confusing the roles of Apache/Nginx with the roles of other components.

Apache vs Nginx

They’re both web servers. They can serve static files but – with the right modules – can also serve dynamic web apps e.g. those written in PHP. Apache is more popular and has more features, Nginx is smaller and faster and has less features.

Neither Apache nor Nginx can serve Rails apps out-of-the-box. To do that you need to use Apache/Nginx in combination with some kind of add-on, described later.

Apache and Nginx can also act as reverse proxies, meaning that they can take an incoming HTTP request and forward it to another server which also speaks HTTP. When that server responds with an HTTP response, Apache/Nginx will forward the response back to the client. You will learn later why this is relevant.

Mongrel vs WEBrick

Mongrel is a Ruby “application server”. In concrete terms this means that Mongrel is an application which:

  1. Loads your Rails app inside its own process space.
  2. Sets up a TCP socket, allowing it to communicate with the outside world (e.g. the Internet). Mongrel listens for HTTP requests on this socket and passes the request data to the Rails app. The Rails app then returns an object which describes how the HTTP response should look like, and Mongrel takes care of converting it to an actual HTTP response (the actual bytes) and sends it back over the socket.

WEBrick does the same thing. Differences with Mongrel:

  • It is written entirely in Ruby. Mongrel is part Ruby part C; mostly Ruby, but its HTTP parser is written in C for performance.
  • WEBrick is slower and less robust. It has some known memory leaks and some known HTTP parsing problems.
  • WEBrick is usually only used as the default server during development because WEBrick is included in Ruby by default. Mongrel needs to be installed separately. Nobody uses WEBrick in production environments.

Another Ruby application server that falls under the same category is Thin. While it’s internally different from both Mongrel and WEBrick it falls under the same category when it comes to usage and its overall role in the server stack.

Mongrel and the world

While Mongrel speaks HTTP, nobody puts Mongrel directly on port 80, i.e. when you visit a Rails site your browser never interfaces directly with Mongrel. Mongrel is always put behind a reverse proxy like Apache or Nginx for several reasons:

  • Each Mongrel-served Rails app can only handle 1 request concurrently. If you want to handle 2 requests concurrently you need to run multiple Mongrel instances, each serving the same Rails app. This set of Mongrel processes is called a Mongrel cluster. You must then setup Apache or Nginx to reverse proxy to this cluster. Apache/Nginx will take care of distributing requests between the instances in the cluster.
  • Mongrel can serve static files, but it’s not particularly good at it. Apache and Nginx can do it faster. People typically set up Apache/Nginx to serve static files directly, but forward requests that don’t correspond with static files to the Mongrel cluster.

You also need to monitor your Mongrel processes. If a process crashes (e.g. because of a bug in your Rails app) then you need to restart it.

Phusion Passenger

Phusion Passenger is also a Ruby application server, but it works differently from Mongrel. Phusion Passenger integrates directly into Apache or Nginx. Instead of starting a Mongrel cluster for your app, and configuring Apache/Nginx to serve static files and/or reverse proxying requests to the Mongrel cluster depending on circumstances, with Phusion you only need to do several things:

  1. You edit the web server config file and specify the location of your Rails app’s ‘public’ directory.
  2. There is no step 2.

With Phusion Passenger you do not need to start a cluster or manage processes – Phusion Passenger takes care of all that for you. With Mongrel your cluster always consists of the same number of processes, but Phusion Passenger can start processes for you when your site becomes busy, and shut down processes for you when your site becomes less busy in order to conserve system resources. If your app crashes Phusion Passenger will automatically restart it for you. Phusion Passenger is, for the most part, written in C++. This makes it very fast.

Phusion Passenger can be compared to mod_php for Apache. Just like mod_php allows Apache to serve PHP apps almost magically, Phusion Passenger allows Apache (and also Nginx!) to serve Ruby apps almost magically. Phusion Passenger’s goal is to make everything Just Work(tm) with as less hassle as possible, in so far it is possible; if the system is broken then obviously Phusion Passenger can’t help you either, but at least it will try to give a descriptive error message so that you know how to fix your system.

At this time Phusion Passenger is the most popular Ruby app server for the above reasons.

Note that Phusion Passenger can also run standalone, that is without needing Apache or Nginx. Phusion Passenger Standalone works a bit like Mongrel: you type passenger start in your Rails app’s directory, and it will launch a Phusion Passenger web server which speaks HTTP and directly serves your web app. Unlike Mongrel, Phusion Passenger Standalone can be directly attached to port 80; it still takes care of starting/stopping/monitoring processes for you, and a single Phusion Passenger Standalone instance can handle multiple concurrent requests.


Capistrano is something completely different. In all the previous sections, “deployment” refers to the act of starting your Rails app in an application server so that it becomes accessible to visitors. But before that can happen one typically needs to do some preparation work, such as:

  • Uploading the Rails app’s code and files to the server machine.
  • Installing libraries that your app depends on.
  • Setting up or migrating the database.
  • Starting and stopping any daemons that your app might rely on, such as DelayedJob workers or whatever.
  • Any other things that need to be done when you’re setting up your application.

In the context of Capistrano, “deployment” refers to doing all this preparation work. Capistrano is not an application server. Instead, it is a tool for automating all that preparation work. You tell Capistrano where your server is and which commands need to be run every time you deploy a new version of your app, and Capistrano will take care of uploading the Rails app to the server for you and running the commands you specified.

Capistrano is always used in combination with an application server. It does not replace application servers. Vice-versa, application servers do not replace Capistrano, they can be used in combination with Capistrano.

Of course you don’t have to use Capistrano. If you prefer to upload your Rails app with FTP and manually running the same steps of commands every time, then you can do that. Other people got tired of it so they automate those steps in Capistrano.