Passenger is an open-source web and application server that greatly simplifies the deployment of Ruby, Python, and Node.js applications.
At DreamHost, Passenger integrates with an Apache or Nginx web server. Passenger's website explains it the following way:
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.
Shared servers will kill off a script if it's using too much memory.
Ruby on Rails
Passenger is the preferred way to deploy and host Ruby on Rails applications across all DreamHost servers and is free on every DreamHost hosting plan.
The following are the basic actions that take place once a file is requested from a domain running Passenger and Ruby on Rails:
- When a request is made to a domain/subdomain, the Apache HTTP Server passes the request to Passenger.
- Passenger first looks for an appropriately-named HTML or CGI file in the domain/subdomain's /public subdirectory (example.com/public).
- If no matching file is found, the request is passed to Passenger's Rack interface.
This is the same way Ruby on Rails makes use of the /public subdirectory.
- Rack looks for a file named config.ru in the domain/subdomain's root directory (example.com) in order to generate a response.
Rack requires that you place the appropriate Ruby code into the config.ru file to invoke your desired web framework/application in order to handle the request.
Under normal circumstances, Ruby on Rails (RoR) automatically creates and initializes all of the files and directories needed to interface with Passenger/Rack.
When running a RoR application, the only Rack-related files you are likely to modify are the following:
- Possibly adding GEM_PATH information to config.ru
- Running touch on the restart.txt file to restart the application. For example:
[server]$ touch tmp/restart.txt
Passenger vs. FastCGI
Passenger should only be enabled if you intend to run a Ruby/Python/Node.js-based application as the sole application for the entire domain/subdomain.
Passenger directs all requests for the designated domain/subdomain to the associated Rack-compliant application, so it's best to leave Passenger disabled if you do not need it.
When to enable Passenger
You should only enable Passenger if you want to access your application via the following three URLs:
If you want to access your application in a subdirectory (www.example.com/path-to-myapp), then use FastCGI instead of Passenger.
Output to STDERR for processes run through the Rack interface is automatically directed to the domain/subdomain specific log file.
This article explains how to view your error log via SSH which requires some basic knowledge of a shell terminal. For an easier option using FTP, view the following article instead:
Troubleshooting the error log
This limitation can make debugging initialization errors (in particular syntax errors and gem resolution issues) tricky. Passenger will often produce an error output webpage including a stack traceback, but sometimes it does not.
Contact DreamHost support if you are running into issues with Passenger not producing useful error output. Our Support team will be happy to take a look to see what may be causing the issue.
Once a framework (such as RoR) is up and running, its error output is typically handled by the framework's own error logging mechanism. For example, RoR records its error output in a file named log/production.log.
Activating Passenger on a domain (example.com) breaks the phpMyAdmin interface on any subdomain (blog.example.com) under the domain.
Passenger disables some mod_rewrite functionality. That means it will automatically override an existing dispatch.fcgi configuration you have in place. This is not a problem for your Rails application but it may have other side effects (such as breaking other mod_rewrite rules you have set up). If this causes a problem for your website, try using the FastCGI method instead.
You can use your local gem repository if you use the following in the config/environment.rb file. Make sure to change username to your Shell user and the version of Ruby to the one your site is using.
if ENV['RAILS_ENV'] == 'production' # don't bother on dev ENV['GEM_PATH'] = '/home/username/.gems' #+ ':/usr/lib/ruby/gems/2.5.0' # Need this or Passenger fails to start end require File.join(File.dirname(__FILE__), 'boot')
The same path should be set in your shell's environment variables GEM_HOME and GEM_PATH so you can use the gem program to install/upgrade your own gems. You can reload the config file by running touch tmp/restart.txt in your base directory.
For common troubleshooting solutions, please visit the Passenger Troubleshooting article.
- How do I enable Passenger on my domain?
- Passenger and Python WSGI
- Troubleshooting Passenger
- Passenger documentation
- Passenger at Wikipedia