We give you a basic understanding of what Passenger is. We also explain how Passenger fits in the stack and how it compares to other software that you may use.
Table of contents
In a nutshell
Phusion Passenger is an open source web application server. It handles HTTP requests, manages processes and resources, and enables administration, monitoring and problem diagnosis.
Passenger is very easy to use, makes deploying in production much easier and is scalable. If you aren't already familiar with the benefits, you can learn more about them.
Passenger supports multiple programming languages, of which Ruby is one. Passenger can also serve multiple applications at the same time (it is multitenant).
Passenger and "rails server"
The Ruby on Rails framework provides a builtin server tool, which you can access with the
rails server command. The "rails server" is not an application server by itself, but just a small wrapper that launches your application in an application server. This is why people do not use "rails server" in production. They use an application server – such as Passenger – directly.
"rails server" uses Puma by default as of Rails 5.
If you add Passenger to your Gemfile, then "rails server" will launch Passenger instead of Puma. You can also choose to launch Passenger directly.
How Passenger fits in the stack
When you deploy your web app to production, there are all sorts of components involved. You may have heard of Unicorn, Puma, Nginx, Apache and Capistrano. Passenger replaces some components, while collaborating with other components.
In a typical production stack, one would use Nginx or Apache as the web server, Passenger as application server, and Capistrano as release automation tool. Passenger integrates with Nginx or Apache and manages the application and its resources.
Nginx and Apache
Nginx and Apache are web servers. They provide HTTP transaction handling and serve static files. However, they are not Ruby application servers and cannot run Ruby applications directly. That is why Nginx and Apache are used in combination with an application server, such as Passenger.
Application servers make it possible for Ruby apps to speak HTTP. Ruby apps (and frameworks like Rails) can't do that by themselves. On the other hand, application servers typically aren't as good as Nginx and Apache at handling HTTP requests. The devil is in the details: Nginx and Apache are better at handling I/O security, HTTP concurrency management, connection timeouts, etc. That's why, in production environments, application servers are used in combination with Nginx or Apache.
Capistrano is an application release automation tool. When releasing a new version of your web application, there are actions that need to be performed, such as uploading your application code to your servers, running a command to install your gem bundle, restarting processes, etc. Capistrano allows you to automate these actions.
Capistrano is not a server that provides HTTP transaction handling, so it does not replace application servers or web servers. Instead, you are supposed to use Capistrano in combination with them. For example, Capistrano scripts typically contain instructions to restart the application server after a new application version has been released.
Unicorn and Puma
Unicorn and Puma are alternative application servers. Passenger replaces Unicorn and Puma.
Passenger's feature set is very different from those of Unicorn and Puma. In particular, Passenger has a stronger focus on ease of use, integration with other components, automatic management and enabling problem diagnosis. For example, Passenger can integrate with Nginx and Apache in order to reduce setup work, and provides tools for easy problem diagnosis.
Multiple integration modes
As you've read earlier, Passenger collaborates with other components. This is why Passenger supports multiple integration modes. Each integration mode is designed for easy collaboration with a different component.
Throughout the rest of this basics tutorial, we will cover the Standalone mode only. The Nginx and Apache integration modes are covered in the deployment tutorial.
The supported integration modes are:
The Standalone mode is what you've experienced in the Quickstart tutorial. You start Passenger through the
passenger startcommand. In this mode, Passenger behaves somewhat like "rails server".
In this mode, Passenger doesn't automatically collaborate with other components, hence the name. Because of this, you do not need to setup any other components besides Passenger, which makes the Standalone mode the easiest mode to get started with. We recommend this mode for use during development. That said, this mode is also fit for production.
In the Nginx and Apache integration mode, Passenger takes care of glueing Nginx/Apache together with Passenger. In the Standalone mode, you are expected to do that yourself, e.g. using reverse proxies, init scripts, etc.
Nginx integration mode
The Nginx integration mode provides easy integration with Nginx. Passenger operates as an Nginx module. You operate Passenger mostly through Nginx and through Nginx configuration files. So instead of worrying about Passenger and Nginx seperately, you treat the both of them as a whole.
This mode is mainly meant for production use, not for development use.
Apache integration mode
The Apache integration mode provides easy integration with Apache. Passenger operates as an Apache module. You operate Passenger mostly through Apache and through Apache configuration files. So instead of worrying about Passenger and Apache seperately, you treat the both of them as a whole.
This mode is mainly meant for production use, not for development use.
All modes provide roughly the same feature sets. The main differences lie in…
- …performance. Standalone and Nginx are slightly faster than Apache.
- …usability. Standalone is easier during development, but Nginx and Apache are easier during production.
- …multitenancy. The Nginx and Apache integration modes can host multiple apps at the same time.
- …flexibility and control. If your production cluster has an advanced architecture, or if you need deep control over every aspect of the system, then Standalone is the best choice during production.
Please refer to the in-depth section if you wish to learn more about integration modes.
What Passenger does not do
Passenger does many things, but some things are currently out of scope.
- Setting up a server with an operating system
Passenger assumes that you already have a server with a working operating system on it. Passenger is not a hosting service. It is software that is to be installed on a server.
However, the Passenger Library contains excellent documentation on setting up a server.
- Installing Ruby
To run Ruby apps on Passenger, you must already have Ruby installed. Passenger does not do that for you. Passenger does not care how you install Ruby though; you sometimes just need to tell Passenger where Ruby is.
Having said that, the Passenger Library contains excellent documentation on installing Ruby during a production deployment.
- Transferring the application code and files to the server
Passenger does not transfer the application code and files to the server for you. To do this, you should use something like Capistrano. Passenger assumes that the application code and files are already on the server, and does not care which tool you use to make that so.
The Passenger Library contains documentation on automating releases using shell scripts.
- Installing application dependencies
Passenger does not install your application's dependencies for you. That job belongs to Capistrano and Bundler.
- Managing the database
If your application requires a database, then Passenger does not install that database for you, nor does it sets up database accounts and tables for you. They must already be set up by the time you deploy your application to Passenger.
You now have a solid understanding of Passenger's fundamental concepts. Let us go through installing Passenger next.