1. Support information

1.1. Supported operating systems

Phusion Passenger works on any POSIX-compliant operating system. In other words: practically any operating system on earth, except Microsoft Windows.

Phusion Passenger is confirmed on a large number of operating systems and Linux distributions, including, but not limited to, Ubuntu, Debian, CentOS/Fedora/RHEL, Gentoo, Mac OS X, FreeBSD and Solaris. OpenBSD is supported since version 5.2. Both 32-bit and 64-bit platforms are supported.

Please report a bug or join our discussion forum if it doesn’t work on your POSIX-compliant operating system.

1.2. Where to get support

  • Community discussion forum - post a message here if you’re experiencing problems. Support on this forum is provided by the community on a best-effort basis, so a (timely) response is not guaranteed.

  • Issue tracker - report bugs here.

  • Email support@phusion.nl if you are a Phusion Passenger Enterprise customer. Please mention your order reference. If you are not an Enterprise customer, we kindly redirect you to the community discussion forum instead.

  • Commercial support contracts are also available.

  • Report security vulnerabilities to security@phusion.nl. We will do our best to respond to you as quickly as we can, so please do not disclose the vulnerability until then.

Please consult the Phusion Passenger website for a full list of support resources.

2. Installation

2.1. Synopsis

Because Phusion Passenger is designed to run in a wide variety of operating systems and configurations, there are multiple ways to install it. Most users  — especially first-time users — will prefer OS-specific installation instructions. These are not only the easiest, but also allow Phusion Passenger to integrate into the operating system in the best way possible. Other users should consult the generic installation instructions.

The steps for upgrading or downgrading Phusion Passenger is almost the same as the steps for installing. All the installation guides in this section will also teach you how to upgrade and downgrade.

2.2. Installing or upgrading on Mac OS X with Homebrew

Open source

Every time we release a new Phusion Passenger version, we make it available through Homebrew. Please note that the Homebrew maintainers have to merge our pull requests manually, so it may take a day or two before a new version shows up in the official Homebrew repository.

  1. Update the Homebrew recipes:

    brew update
  2. Run one of the following, and follow the instructions:

    brew install passenger
    -OR-
    brew upgrade passenger
Enterprise

Phusion Passenger Enterprise is currently not available through Homebrew. Please try one of the other installation methods instead.

2.3. Installing or upgrading on Debian or Ubuntu

We provide an official Phusion Passenger APT repository. This APT repository contains Phusion Passenger packages for multiple versions of Debian and Ubuntu. These packages are automatically built by our build server after we push out a source release, and thus are always up to date with the official source releases.

If you use these packages to install Phusion Passenger then you do not need to run passenger-install-apache2-module or passenger-install-nginx-module. These packages contain all the binaries that you need.

Packages are available for the x86 and x86_64 architectures. Our policy is to support all Ubuntu LTS releases that are still supported by Canonical, plus the latest non-LTS Ubuntu release, plus all Debian releases that are still supported by Debian.

2.3.1. Adding our APT repository

  1. Install our PGP key. Packages are signed by "Phusion Automated Software Signing (auto-software-signing@phusion.nl)", fingerprint 1637 8A33 A6EF 1676 2922 526E 561F 9B9C AC40 B2F7.

    sudo apt-key adv --keyserver keyserver.ubuntu.com --recv-keys 561F9B9CAC40B2F7
  2. Add HTTPS support for APT. Our APT repository is stored on an HTTPS server.

    sudo apt-get install apt-transport-https ca-certificates
  3. Create a file /etc/apt/sources.list.d/passenger.list and insert one of the following lines, depending on your distribution.

    Open source
    ##### !!!! Only add ONE of these lines, not all of them !!!! #####
    # Ubuntu 13.10
    deb https://oss-binaries.phusionpassenger.com/apt/passenger saucy main
    # Ubuntu 12.04
    deb https://oss-binaries.phusionpassenger.com/apt/passenger precise main
    # Ubuntu 10.04
    deb https://oss-binaries.phusionpassenger.com/apt/passenger lucid main
    # Debian 7
    deb https://oss-binaries.phusionpassenger.com/apt/passenger wheezy main
    # Debian 6
    deb https://oss-binaries.phusionpassenger.com/apt/passenger squeeze main
    Enterprise
    ##### !!!! Only add ONE of these lines, not all of them !!!! #####
    # Ubuntu 13.10
    deb https://download:YOUR_DOWNLOAD_TOKEN@www.phusionpassenger.com/enterprise_apt saucy main
    # Ubuntu 12.04
    deb https://download:YOUR_DOWNLOAD_TOKEN@www.phusionpassenger.com/enterprise_apt precise main
    # Ubuntu 10.04
    deb https://download:YOUR_DOWNLOAD_TOKEN@www.phusionpassenger.com/enterprise_apt lucid main
    # Debian 7
    deb https://download:YOUR_DOWNLOAD_TOKEN@www.phusionpassenger.com/enterprise_apt wheezy main
    # Debian 6
    deb https://download:YOUR_DOWNLOAD_TOKEN@www.phusionpassenger.com/enterprise_apt squeeze main

    You can find the correct value for YOUR_DOWNLOAD_TOKEN in the Customer Area.

  4. Secure passenger.list and update your APT cache:

    sudo chown root: /etc/apt/sources.list.d/passenger.list
    sudo chmod 600 /etc/apt/sources.list.d/passenger.list
    sudo apt-get update

2.3.2. Installing packages

Open source
  1. Add our APT repository.

  2. Install the package:

    sudo apt-get install passenger
Enterprise
  1. Download your license key from the Customer Area and save it as /etc/passenger-enterprise-license.

  2. Add our APT repository.

  3. Install the packages:

    sudo apt-get install passenger-enterprise

2.4. Installing or upgrading on Red Hat, Fedora, CentOS or ScientificLinux

Warning The RPMs are currently unmaintained. As such, the repository only contains Phusion Passenger 3.x (the latest version is 4.x), which did not support Node.js, Meteor, multiple Rubies, etc. For more recent versions of Phusion Passenger, you are suggested to install from gem or tarball instead.

YUM repositories with RPMs are maintained by Erik Ogan and Stealthy Monkeys Consulting. Only packages for the open source version of Phusion Passenger are provided. Phusion Passenger Enterprise customers should use the generic RubyGems installation method or the generic tarball installation method instead.

If you use YUM to install Phusion Passenger then you do not need to run passenger-install-apache2-module or passenger-install-nginx-module. The YUM packages contain all the binaries that you need. You also don’t need to modify any Apache or Nginx configuration to get them to load Phusion Passenger, the packages provide configuration snippets for you as well.

Step 1: Import the Stealthy Monkeys Consulting’s GPG key

rpm --import http://passenger.stealthymonkeys.com/RPM-GPG-KEY-stealthymonkeys.asc

Step 2: Install the release package

Install the passenger-release package from the main repository.

Fedora Core 17:

yum install http://passenger.stealthymonkeys.com/fedora/17/passenger-release.noarch.rpm

Fedora Core 16:

yum install http://passenger.stealthymonkeys.com/fedora/16/passenger-release.noarch.rpm

Fedora Core 15:

yum install http://passenger.stealthymonkeys.com/fedora/15/passenger-release.noarch.rpm

Fedora Core 14:

yum install http://passenger.stealthymonkeys.com/fedora/14/passenger-release.noarch.rpm

RHEL 6 / CentOS 6 / ScientificLinux 6: (Note: these packages depend on EPEL.)

yum install http://passenger.stealthymonkeys.com/rhel/6/passenger-release.noarch.rpm

RHEL 5 / CentOS 5 / ScientificLinux 5: (Note: these packages depend on EPEL.)

rpm -Uvh http://passenger.stealthymonkeys.com/rhel/5/passenger-release.noarch.rpm

Step 3: Install the right Phusion Passenger package

From there you can use YUM to install packages. For example, try one of these:

Phusion Passenger for Apache:

yum install mod_passenger

Phusion Passenger for Nginx:

yum install nginx-passenger

Phusion Passenger Standalone:

yum install passenger-standalone

Building your own packages

There are instructions for building your own packages and Yum repositories in the rpm directory ReadMe within the GitHub repository.

2.5. Generic installation, upgrade and downgrade method: via RubyGems

RubyGems is only used as a method to obtain the Phusion Passenger files, so in case you have multiple Ruby versions it does not matter which Ruby’s RubyGems you use for installation. Once installed, Phusion Passenger can work with all other Ruby versions on your system. This is explained in Phusion Passenger and its relationship with Ruby.

Step 1: figuring out whether your Ruby is installed in the home directory or system-wide

Ruby may either be installed in the home directory, or system-wide. If it’s installed system-wide then we will want to install gems system-wide as well, so you need to switch to a root prompt first. If Ruby is installed in the home directory then we will want to install gems to the home directory as well, as a normal user.

To find out which case applies, run the following command to find out where the ruby command is:

which ruby

Do you see a filename that references /home or /Users? If so then your Ruby interpreter is installed in your home directory and you can proceed to step 2. Otherwise, you need to switch to a root prompt by running one of the following commands:

  • Are you using RVM? Run rvmsudo -s

  • Are you not using RVM, or do you not know what RVM is? Run sudo -s

  • Is sudo not installed on your system? Run su -c bash

You must maintain this root prompt throughout this installation guide.

Step 2: install the gem

Open Source

Install the latest gem to obtain the files for the latest stable version of the open source Phusion Passenger:

gem install passenger
Previous versions and beta versions

Sometimes you will want to obtain the latest beta version of Phusion Passenger. Beta versions are not normally selected by gem install, so to opt-in for beta versions you have to add the --pre argument:

gem install passenger --pre

If you want to obtain a specific version of Phusion Passenger, e.g. because you are downgrading, then specify the version number with --version:

gem install passenger --version 3.0.0

If you want to obtain a specific beta version of Phusion Passenger then you must also pass --pre:

gem install passenger --version 3.9.1.beta --pre
Enterprise

First, download the license key from the Customer Area and save it as /etc/passenger-enterprise-license.

Next, add the Phusion Passenger Enterprise gem server to your RubyGems source list:

gem source --add https://download:YOUR_DOWNLOAD_TOKEN@www.phusionpassenger.com/enterprise_gems/

Substitute YOUR_DOWNLOAD_TOKEN with the one you find in the Customer Area. And notice the trailing slash in the URL! It is very important.

Finally, install the latest gem to obtain the files for the latest stable version of the open source Phusion Passenger:

gem install passenger-enterprise-server
Previous versions and beta versions

Sometimes you will want to obtain the latest beta version of Phusion Passenger Enterprise. Beta versions are not normally selected by gem install, so to opt-in for beta versions you have to add the --pre argument:

gem install passenger-enterprise-server --pre

If you want to obtain a specific version of Phusion Passenger Enterprise, e.g. because you are downgrading, then specify the version number with --version:

gem install passenger-enterprise-server --version 3.0.0

If you want to obtain a specific beta version of Phusion Passenger then you must also pass --pre:

gem install passenger-enterprise-server --version 3.9.1.beta --pre

2.6. Generic installation, upgrade and downgrade method: via tarball

Step 1: installing Ruby

Phusion Passenger supports multiple languages and its core is written in C++, but its installer and administration tools are written in Ruby, so you must install Ruby.

Even though Ruby is required, Ruby will normally not be loaded during normal operation unless you deploy a Ruby web application on Phusion Passenger. Phusion Passenger’s dependency on Ruby is very minimal. See Phusion Passenger and its relationship with Ruby for details.

Debian, Ubuntu

sudo apt-get update
sudo apt-get install ruby rake

Red Hat, CentOS, ScientificLinux, Amazon Linux

Enable EPEL, then run as root:
yum install ruby rubygem-rake

Mac OS X

No action needed. Ruby is installed by default.

Other operating systems

Install Ruby from the Ruby website.

Step 2: download and extract the tarball

Open Source

Download the open source Phusion Passenger tarball from the Phusion Passenger website.

Older versions can be found in the release archive.

Enterprise

Phusion Passenger Enterprise customers can download the Phusion Passenger Enterprise tarball from the Customer Area.

Also be sure to download the license key and save it as /etc/passenger-enterprise-license.

Once you have downloaded the tarball, pick a location to extract it to. You can pick any location. A good location is /opt/passenger. Create this directory and extract the tarball as follows:

mkdir /opt/passenger
cd /opt/passenger
tar xzvf /location-to/passenger-x.x.x.tar.gz
cd /opt/passenger/passenger-x.x.x

Note that passenger-x.x.x should be passenger-enterprise-server-x.x.x if you’re using Phusion Passenger Enterprise.

Step 3: adding the Phusion Passenger tools to PATH

Edit /etc/bashrc (or /etc/bash.bashrc on some systems) and append the following to the end of the file:

export PATH=/opt/passenger/passenger-x.x.x/bin:$PATH

Finally, restart all your shell sessions in order to activate this change. The installation is now complete.

2.7. Upgrading from open source to Enterprise

Phusion Passenger comes in two variants: an open source version, as well as an Enterprise version which introduces a myriad of useful features that can improve stability and performance and efficiency.

Customers who have bought Phusion Passenger Enterprise can upgrade their open source installation to Enterprise as follows:

  1. Uninstall the open source Phusion Passenger.

  2. Install the Enterprise version by following one of the installation guides in this section (e.g. RubyGems generic installation or tarball generic installation).

The uninstallation is necessary because the Enterprise Ruby gem has a different gem name (passenger-enterprise-server instead of passenger), but the same administration command names (e.g. passenger-status). Uninstalling the open source version avoids any conflicts.

2.8. Cryptographic verification of installation files

2.8.1. Synopsis

We digitally sign various files with our GPG key so that you can check whether they’re legit, i.e. whether they really came from Phusion and haven’t been tampered with by a third party. We apply signing since the open source version 4.0.0 RC 4, or the Enterprise version 4.0.0 RC 1.

2.8.2. Importing the Phusion Software Signing key

Phusion’s GPG key for signing software is as follows:

Phusion Software Signing (software-signing@phusion.nl)
Short key ID: 0x0A212A8C
Long key ID: 0x2AC745A50A212A8C
Fingerprint: D5F0 8514 2693 9232 F437  AB72 2AC7 45A5 0A21 2A8C

This key is stored at the Phusion website and at the key servers sks-keyservers.net and keyserver.ubuntu.com. You can import it to your keyring with one of these command:

gpg --keyserver pool.sks-keyservers.net --search-keys 0x2AC745A50A212A8C
# -OR-
gpg --keyserver keyserver.ubuntu.com --search-keys 0x2AC745A50A212A8C

The Phusion Software Signing key is only used for signing software. It’s never used for signing emails or for encrypting files, so please be suspicious if you encounter usage of this key outside the context of signing software, and alert us at support@phusion.nl. Include "notspam" in the message to bypass our spam filter.

The email address software-signing@phusion.nl redirects to info@phusion.nl so it’s safe to send email there.

2.8.3. Verifying the Phusion Software Signing key

The Phusion Software Signing key is also signed by the Phusion founders. Their keys are as follows:

Hongli Lai (hongli@phusion.nl)
Short key ID: 8C59158F
Long key ID: CD70085E8C59158F
Fingerprint: 218A 7255 83D0 2ECE F3A9 C2A7 CD70 085E 8C59 158F
Ninh Bui (ninh@phusion.nl)
Short key ID: 69481265
Long key ID: AE405F7869481265
Fingerprint: A77C 9CEF 766D 0E7D A95B 8778 AE40 5F78 6948 1265

Both keys are stored at both sks-servers.net and keyserver.ubuntu.com. Import them with:

gpg --keyserver pool.sks-servers.net --search-keys 0xCD70085E8C59158F
gpg --keyserver pool.sks-servers.net --search-keys 0xAE405F7869481265
# -OR-
gpg --keyserver keyserver.ubuntu.com --search-keys 0xCD70085E8C59158F
gpg --keyserver keyserver.ubuntu.com --search-keys 0xAE405F7869481265

2.8.4. Verifying the gem and tarball

You can find the open source version’s gem and tarball GPG signatures at https://www.phusionpassenger.com/file_releases. The Enterprise version’s GPG signatures can be found in the Customer Area. All signatures have the .asc extension. Once you have imported our key, you can verify the validity of a file against its signature as follows:

$ gpg --verify passenger-x.x.x.tar.gz.asc passenger-x.x.x.tar.gz
gpg: Signature made Mon Mar 11 09:45:46 2013 CET using RSA key ID 0A212A8C
gpg: Good signature from "Phusion Software Signing <software-signing@phusion.nl>"

2.8.5. Verifying Git signatures

Tags in the Git repository for the open source version are also tagged. You can verify a Git tag as follows:

$ git tag --verify release-x.x.x
object d886f34b5705e4314feccaf0d77b9a38416e15e0
type commit
tag release-4.0.0.rc5
tagger Hongli Lai (Phusion) <hongli@phusion.nl> 1362993117 +0100

This is a tag message.
gpg: Signature made Mon Mar 11 10:12:02 2013 CET using RSA key ID 0A212A8C
gpg: Good signature from "Phusion Software Signing <software-signing@phusion.nl>"

2.8.6. Verifying DEB and RPM packages

The DEB and RPM packages are signed with the signatures of the respective packagers. They are automatically checked upon installation.

2.8.7. Revocation

In the event our key is compromised, we will revoke the key and upload the revocation information to sks-servers.net and keyserver.ubuntu.com. However your system will not know about the revocation until you update the keys from the keyservers. You should update your keys regularly (e.g. once a week) by invoking:

gpg --refresh-keys --keyserver pool.sks-servers.net
# -OR-
gpg --refresh-keys --keyserver keyserver.ubuntu.com

If you installed Phusion Passenger through our APT repository, then you should update APT’s keyring from time to time as well:

sudo apt-key adv --refresh-keys --keyserver keyserver.ubuntu.com

2.9. Customizing the compilation process

The Phusion Passenger compilation process can be customized with environment variables. You can learn more about environment variables in About environment variables.

2.9.1. Setting the compiler

You can force the Phusion Passenger build system to use a specific C or C++ compiler by setting the CC and CXX environment variables. These may be set to any arbitrary shell commands.

For example, contributors who want to hack on Phusion Passenger may want to use Clang for faster compilation and ccache for faster recompilation, and may want to enable more error-catching compilation flags:

export CC='ccache clang -fcolor-diagnostics -Qunused-arguments -fcatch-undefined-behavior -ftrapv'
export CXX='ccache clang++ -fcolor-diagnostics -Qunused-arguments -fcatch-undefined-behavior -ftrapv'
Note If you run the installer with sudo then environment variables may not be passed properly. Learn more at Environment variables and sudo.

2.9.2. Adding additional compiler or linker flags

On some systems, C/C++ libraries and headers that Phusion Passenger requires may be located in a non-standard directory. You can force the Phusion Passenger build system to look in those locations by injecting compiler and linker flags using the following environment variables:

EXTRA_PRE_CFLAGS

These flags are injected into all C compiler invocations that involve compiling C source files. This also covers compiler invocations that compile and link. The flags are injected at the beginning of the command string, even before EXTRA_PRE_LDFLAGS.

EXTRA_CFLAGS

Similar to EXTRA_PRE_CFLAGS, but injected at the end of the command string, before EXTRA_LDFLAGS.

EXTRA_PRE_CXXFLAGS

Similar to EXTRA_PRE_CFLAGS, but for C++ compiler invocations.

EXTRA_CXXFLAGS

Similar to EXTRA_CFLAGS, but for C++ compiler invocations.

EXTRA_PRE_LDFLAGS

These flags are injected into all C/C++ compiler invocations that involve linking. This includes compiler invocations that compile and link. The flags are injected at the beginning of the command string, but after EXTRA_PRE_CFLAGS/EXTRA_PRE_CXXFLAGS.

EXTRA_PRE_C_LDFLAGS

These flags are injected into all C compiler invocations that involve linking, right after EXTRA_PRE_LDFLAGS.

EXTRA_PRE_CXX_LDFLAGS

Similar to EXTRA_PRE_CXX_LDFLAGS, but for C++ compiler invocations.

EXTRA_LDFLAGS

Similar to EXTRA_PRE_LDFLAGS, but injected at the very end of the command string, even after EXTRA_CFLAGS and EXTRA_CXXFLAGS.

EXTRA_C_LDFLAGS

Similar to EXTRA_LDFLAGS, but only injected for C executable linking commands. Injected right after EXTRA_LDFLAGS.

EXTRA_CXX_LDFLAGS

Similar to EXTRA_LDFLAGS, but only injected for C++ executable linking commands. Injected right after EXTRA_LDFLAGS.

PASSENGER_THREAD_LOCAL_STORAGE

Setting this to 1 will enable the PASSENGER_THREAD_LOCAL_STORAGE macro, which forcefully disables the use of thread-local storage inside the Phusion Passenger codebase. Setting this environment variable is useful on systems that have broken support for thread-local storage, despite passing our build system’s check for proper thread-local storage support. At the time of writing, one user has reported that Ubuntu 12.04 32-bit has broken thread-local storage report although neither the reporter nor us were able to reproduce the problem on any other systems running Ubuntu 12.04 32-bit. Note that this flag has no effect on non-Phusion Passenger code.

Note If you run the installer with sudo then environment variables may not be passed properly. Learn more at Environment variables and sudo.

2.9.3. Forcing location of command line tools and dependencies

The Phusion Passenger build system attempts to autodetect many things by locating relevant helper tools. For example, to find out which compiler flags it should use for compiling Apache modules, it locates the apxs2 command and queries it. To find out which compiler flags it should use for libcurl, it queries the curl-config command. These commands may not be in $PATH, or even when they are you may want to use a different one.

You can force the build to find certain command line tools at certain locations by using the following environment variables:

HTTPD

The location of the httpd executable (the Apache server executable).

APXS2

The location of the apxs2 executable (the Apache module developer tool). Only used by passenger-install-apache2-module.

This environment variable, together with HTTPD, are what you need to customize if you have multiple Apache installations on your system, or if your Apache is located in a non-standard location which Phusion Passenger cannot detect. By setting APXS2 and HTTP to the right paths, you can force Phusion Passenger to be compiled against that specific Apache installation.

For example, if your Apache installation is located in /opt/lamp/apache2, then you can run the installer as follows:

$ sudo bash
# export HTTPD=/opt/lampp/apache2/bin/apache
# export APXS2=/opt/lampp/apache2/bin/apxs
# passenger-install-apache2-module
APR_CONFIG

The location of the apr-config executable (the Apache Portable Runtime developer tool).

APU_CONFIG

The location of the apu-config executable (the Apache Portable Runtime Utility developer tool).

MAKE

The location of a make tool. It does not matter which implementation of make this is.

GMAKE

The location of the GNU-compatible make tool.

Tip If you do not know what environment variables are, or how to use them, then please read Environment variables and sudo.
Note If you run the installer with sudo then environment variables may not be passed properly. Learn more at Environment variables and sudo.

2.10. Uninstalling

  • If you installed Phusion Passenger via a Ruby gem, then run gem uninstall passenger (or, if you’re a Phusion Passenger Enterprise user, gem uninstall passenger-enterprise-server). You might have to run this as root.

  • If you installed Phusion Passenger via a source tarball, then remove the directory in which you placed the extracted Phusion Passenger files. This directory is the same as the one pointed to the by PassengerRoot/passenger_root configuration directive.

  • If you installed Phusion Passenger through APT or YUM, then use them to uninstall Phusion Passenger.

  • If you installed Phusion Passenger through Homebrew, then run brew uninstall passenger.

2.11. Moving to a different directory

If you installed Phusion Passenger through a tarball then you can move the Phusion Passenger directory to another location. This is not possible if you used any of the other installation methods.

First, move the directory to whereever you like:

mv /opt/passenger/passenger-4.0.0 /usr/local/passenger-4.0.0

If you used the tarball installation method and you added Phusion Passenger’s bin subdirectory to PATH, then you must update your PATH with the new location. Open /etc/bashrc (or /etc/bash.bashrc on some systems) and change:

export PATH=/opt/passenger/passenger-4.0.0/bin:$PATH

to:

export PATH=/usr/local/passenger-4.0.0/bin:$PATH

Finally, restart all your shell sessions to activate the PATH change.

3. Usage

Go to your application’s root directory, and run:

passenger start

4. Configuration

4.1. Command line options

Most configuration is done by customizing the arguments passed to the passenger command. The most important ones are:

--port NUMBER

The port number that Phusion Passenger Standalone should listen on. If not given, port 3000 is assumed.

--environment NAME

Customizes the value of the RAILS_ENV, RACK_ENV, WSGI_ENV, NODE_ENV and PASSENGER_APP_ENV environment variables. Some web frameworks, for example Rails and Connect.js, adjust their behavior according to the environment. The default value is development.

--max-pool-size NUMBER

The maximum number of application processes to run. The maximum number that you can run depends on the amount of memory your server has. The article Tuning Phusion Passenger’s concurrency settings explains how you can infer a good number for this option.

--min-instances NUMBER

If you don’t want the number of application processes to scale dynamically, then use this option to set it to a value equal to --max-pool-size.

--spawn-method NAME

When set to "smart" (the default), Phusion Passenger preloads your app and utilizes copy-on-write in order to save memory. You can disable this by setting this option to "direct". Preloading is only supported for Ruby apps. For apps written in other languages, it is as if "direct" is always used.

--no-friendly-error-pages

If your app fails to start, Phusion Passenger will tell you by showing a friendly error page in the browser. This option disables it.

--ssl

Enables SSL support. If this is set, you must also set --ssl-certificate and --ssl-certificate-key to the SSL certificate and key files, respectively.

--ssl-port

If --ssl is given, and you set this option, then Phusion Passenger Standalone will listen for HTTP on the regular --port number, as well as listen for HTTPS on the port you specified with this option. For example:

# Listen for HTTP on port 3000, HTTPS on port 3001.
passenger start --ssl --ssl-certificate ... --ssl-certificate-key ... --ssl-port 3001
--nginx-config-template

Specifies the Nginx configuration template file to use. See Advanced configuration.

See --help for all available options.

4.2. Configuration file

Introduced in version 4.0.24.

It is possible to store some options in a configuration file passenger-standalone.json in the application directory. Configuration in this file overrides command line options. The configuration file format is JSON.

In case Passenger Standalone is in mass deployment mode, such a configuration file allows customizing options on a per-application basis.

The following configuration options are supported:

port

Equivalent to the --port command line option.

environment

Equivalent to the --environment command line option.

max_pool_size

Equivalent to the --max-pool-size command line option. But when in mass deployment mode, this option in the configuration file has no effect; the command line option should be used to customize this.

min_instances

Equivalent to the --min-instances command line option.

spawn_method

Equivalent to the --spawn-method command line option.

ssl

Equivalent to the --ssl command line option. When given, you must also set ssl_certificate and ssl_certificate_key in the configuration file.

ssl_port

Equivalent to the --ssl-port command line option.

When in mass deployment mode, you will probably want to set a different port too. If you don’t, and you end up in a situation in which a port is used for both HTTP and HTTPS traffic, then the builtin Nginx core will abort with an error.

nginx_config_template

Equivalent to the --nginx-config-template command line option.

Here is an example configuration file:

{
        "port": 8000,
        "environment": "production",
        "ssl": true,
        "ssl_certificate": "/path-to-cert.crt",
        "ssl_certificate_key": "/path-to-cert.key"
}

4.3. Advanced configuration

Introduced in version 4.0.39.

Phusion Passenger Standalone is built on the same technology that powers Phusion Passenger for Nginx, so any configuration option supported by Phusion Passenger for Nginx can be applied to Standalone as well. You can do this by editing the Standalone configuration template directly.

First, create a copy of the default Phusion Passenger Nginx configuration template file:

cp $(passenger-config about resourcesdir)/templates/standalone/config.erb nginx.conf.erb

Then open nginx.conf.erb and modify it as you see fit. The file is a normal Nginx configuration file, in the ERB template format.

Every time you start Standalone, you must pass the --nginx-config-template parameter, which tells Standalone to use your specific Nginx configuration template file. For example:

passenger start --nginx-config-template nginx.config.erb

Alternatively, if you don’t want to pass this parameter every time, you can also set the nginx_config_template option in passenger-standalone.json.

Note The original configuration template file may change from time to time, e.g. because new features are introduced into Phusion Passenger. If your configuration template file does not contain the required changes, then these new features may not work properly. In the worst case, Standalone might even malfunction. Therefore, every time you upgrade Phusion Passenger, you should check whether the original configuration template file has changed, and merge back any changes into your own file.

5. Using Passenger Standalone in production

5.1. Starting Passenger Standalone at system boot

The easiest way to have Passenger Standalone started during system boot is add it to the file /etc/rc.local. This script is called during system boot.

Here’s an example of what you may want to add to /etc/rc.local. If there is an exit command in rc.local, make sure you add these before the exit command.

# If you installed Phusion Passenger from tarball, add its `bin` directory to PATH.
#export PATH=/path-to-passenger/bin:$PATH

# Change working directory to your webapp.
cd /path-to-your-webapp

# Start Passenger Standalone in daemonized mode. Passenger will be started as
# root when run from this file, so we also tell it to drop its privileges to a
# normal user. Replace 'someusername' with the user you want to run your
# application under.
passenger start --daemonize --port 80 --user someusername

To stop Passenger Standalone, run:

cd /path-to-your-webapp

# If you use RVM, use 'rvmsudo' instead of 'sudo'
sudo passenger stop

5.2. Sharing the same port between multiple Passenger Standalone instances

If you have multiple applications on your server then it is desirable to have all of them listen on the same port (e.g. port 80), with the HTTP request’s host name determining which Passenger Standalone instance should handle the request. There are three ways to achieve this.

  1. The first way is to use the Mass deployment feature, which allows Passenger Standalone to directly host multiple applications at the same time. Please refer to that section to learn more.

  2. The second way is to run multiple Passenger Standalone instances — one for each application — and to put all of them behind a reverse proxy or load balancer. The reverse proxy/load balancer can for example be Nginx, Apache or HAProxy. The reverse proxy/load balancer listens on port 80, determines which Passenger Standalone instance should handle the request, and forwards the request to that instance.

  3. The third way is to use Phusion Passenger for Nginx or Phusion Passenger for Apache. These are two modes of Phusion Passenger that are distinct from the Standalone mode, which this document describes. In the Nginx and Apache modes, Phusion Passenger integrates directly into Nginx and Apache, and makes it very easy to host multiple applications directly on Nginx or Apache.

    Compared method 2 — putting Passenger Standalone behind a reverse proxy or load balancer — the Nginx or Apache modes are easier to use and require less configuration. On the other hand, the Nginx modes requires reinstalling or recompiling Nginx, while the Apache mode requires that the Phusion Passenger Apache module is installed.

The rest of this subsection describes method 2.

Step 1: starting all applications

Putting Passenger Standalone behind a reverse proxy requires three steps. First, you must start all Passenger Standalone instances that you want. Each one must be listening on a different port, because two applications can’t listen on the same port. Suppose that you have two applications, /webapps/foo and /webapps/bar. Here’s how you may start them:

# Start foo on port 4000
cd /webapps/foo
passenger start --daemonize --address 127.0.0.1 --port 4000

# Start bar on port 4010
cd /webapps/bar
passenger start --daemonize --address 127.0.0.1 --port 4010

Notice the fact that we pass --address 127.0.0.1, which tells Passenger Standalone to only listen for requests that originate from the local machine. This is because the reverse proxy/load balancer, not Passenger Standalone, is supposed to be responsible for receiving external HTTP requests. The reverse proxy/load balancer will be running on the same machine only, so limiting Passenger Standalone in this manner improves security.

Step 2: install and configure the reverse proxy/load balancer

The next step is to install a reverse proxy/load balancer, and to configure it to do the following:

  • To listen on port 80.

  • To forward requests to either foo or bar, depending on the request’s HTTP host name.

You can use any reverse proxy/load balancer you want, but we’re going to show an example using Nginx because it’s a pretty popular choice. Install Nginx as follows:

Debian, Ubuntu

sudo apt-get update
sudo apt-get install nginx-extras

Red Hat, CentOS, ScientificLinux, Amazon Linux

Enable EPEL, then run as root:
yum install nginx

Mac OS X (Homebrew)

brew install nginx

Other operating systems

Install Nginx from the Nginx website.

Open the Nginx configuration file:

Debian, Ubuntu

/etc/nginx/nginx.conf

Red Hat, CentOS, ScientificLinux, Amazon Linux

/etc/nginx/nginx.conf

Mac OS X (Homebrew)

/usr/local/etc/nginx/nginx.conf

Other operating systems

It depends on how you installed Nginx, but it’s usually $PREFIX/conf/nginx.conf, where $PREFIX is the prefix you installed Nginx to.

Add virtual host entries for your applications foo and bar. While making the virtual host entries, you must determine what host names foo and bar should respond to. Let’s say that foo should respond to www.foo.com and bar should respond to www.bar.com. Then the following entries will tell Nginx to listen on port 80, and to handle requests for the domains www.foo.com and www.bar.com differently.

http {
    ...

    # These are some "magic" Nginx configuration options that aid in making
    # WebSockets work properly with Passenger Standalone. Please learn more
    # at http://nginx.org/en/docs/http/websocket.html
    map $http_upgrade $connection_upgrade {
        default upgrade;
        ''      close;
    }

    server {
        listen 80;
        server_name www.foo.com;

        # Tells Nginx to serve static assets from this directory.
        root /webapps/foo/public;

        location / {
            # Tells Nginx to forward all requests for www.foo.com
            # to the Passenger Standalone instance listening on port 4000.
            proxy_pass http://127.0.0.1:4000;

            # These are "magic" Nginx configuration options that
            # should be present in order to make the reverse proxying
            # work properly. Also contains some options that make WebSockets
            # work properly with Passenger Standalone. Please learn more at
            # http://nginx.org/en/docs/http/ngx_http_proxy_module.html
            proxy_http_version 1.1;
            proxy_set_header Host $http_host;
            proxy_set_header Upgrade $http_upgrade;
            proxy_set_header Connection $connection_upgrade;
            proxy_buffering off;
        }
    }

    # We handle bar in a similar manner.
    server {
        listen 80;
        server_name www.bar.com;

        root /webapps/bar/public;

        location / {
            # bar is listening on port 4010 instead of 4000, we
            # change the URL here.
            proxy_pass http://127.0.0.1:4010;

            proxy_http_version 1.1;
            proxy_set_header Host $http_host;
            proxy_set_header Upgrade $http_upgrade;
            proxy_set_header Connection $connection_upgrade;
            proxy_buffering off;
        }
    }
}

Once you’re done editing the Nginx configuration file, restart Nginx:

Debian, Ubuntu

sudo /etc/init.d/nginx restart

Red Hat, CentOS, ScientificLinux, Amazon Linux

sudo service nginx restart

Mac OS X (Homebrew)

1. Run sudo kill $(cat /usr/local/var/run/nginx.pid)
2. You you installed the Nginx launchd plist that Homebrew provides (see brew info nginx to learn more), then you don’t have to do anything, and launchd will automatically restart Nginx. Otherwise, you have to manually start Nginx again: sudo /usr/local/bin/nginx.

Other operating systems

It depends on how you installed Nginx, but it’s usually as follows:

1. Lookup the PID of the Nginx master process using ps aux.
2. Run sudo kill <PID>
3. Start Nginx again: sudo $PREFIX/sbin/nginx, where $PREFIX is the prefix you installed Nginx to.

Step 3: testing

Nginx should now be listening on port 80, and should forward requests to foo and bar respectively. Let’s test it out by accessing http://www.foo.com and http://www.bar.com. But first, we need to ensure that any requests to www.foo.com and www.bar.com, that originate from the local machine, actually end up at the local host, and not at the IP address specified in the DNS records. To do this, edit /etc/hosts and add:

127.0.0.1  www.foo.com www.bar.com

Now visit http://www.foo.com and http://www.bar.com, and verify that it works.

Step 4: making all apps start at system boot

Once you restart the server, the reverse proxy/load balancer will no longer be able to serve www.foo.com or www.bar.com because the Passenger Standalone instances that host them are no longer running. You must therefore configure the system to start Passenger Standalone at system boot. Please refer to Starting Passenger Standalone at system boot for more information.

For example, you can put this in /etc/rc.local to make the system start foo and bar at system boot:

# If you installed Phusion Passenger from tarball, add its `bin` directory to PATH.
#export PATH=/path-to-passenger/bin:$PATH

cd /webapps/foo
passenger start --daemonize --port 4000 --user someusername1

cd /webapps/bar
passenger start --daemonize --port 4010 --user someusername2

Step 5: wrapping up

Edit /etc/hosts and remove the entry that you added in step 3.

5.3. Installing Passenger Standalone behind Nginx

6. Mass deployment

This feature is only available in Phusion Passenger Enterprise. It was introduced in version 3.0.0. Buy Phusion Passenger Enterprise here.

Mass deployment is a special mode in Phusion Passenger Standalone that allows you to deploy multiple web applications without having to create configuration entries for each one of them. Given a directory with multiple web applications, Passenger Standalone will automatically give each web application its own virtual host entry, and serve all of them from a single server. The virtual host’s server name is equal to the web application’s directory name. Whenever a new web application is added or removed, Passenger Standalone automatically reconfigures itself without administrator intervention. This makes the mass deployment mode especially useful when there are a large number of web applications.

For example, suppose we have a directory /webapps with three web applications: Ruby app, a Python app and a Node.js app.

/webapps
  |
  +-- rubyapp.com
  |    |
  |    +-- config.ru
  |
  +-- pythonapp.com
  |    |
  |    +-- passenger_wsgi.py
  |
  +-- nodeapp.com
       |
       +-- app.js

You can activate Passenger Standalone in mass deployment mode by changing the working directory to /webapps and running passenger start:

$ cd /webapps
$ passenger start
=============== Phusion Passenger Standalone web server started ===============
PID file: /webapps/passenger.3000.pid
Log file: /webapps/passenger.3000.log
Environment: development

Serving these applications on 0.0.0.0 port 3000:
 Host name                     Directory
.-----------------------------------------------------------
 rubyapp.com                   /webapps/rubyapp.com
 pythonapp.com                 /webapps/pythonapp.com
 nodeapp.com                   /webapps/nodeapp.com
.-----------------------------------------------------------

If you for example remove /webapps/rubyapp.com, Passenger Standalone will reconfigure itself without that web application. Or if you add a new web applications /webapps/newapp.org, Passenger Standalone will reconfigure itself with that web application.

Any options that you pass to the passenger command will affect all deployed web applications. It is also possible to change options on a per-application basis through the use of a passenger-standalone.json file inside each application’s directory.

7. Troubleshooting

7.1. Generic troubleshooting tips

One of the first things you should do upon encountering a problem, is to check Phusion Passenger Standalone log file. This is typically located in log/passenger.[PORT NUMBER].log. Most problems are logged to this log file.

If neither the logs nor this troubleshooting guide can help you, then please check out our support resources.

7.2. Upon uploading a file, Phusion Passenger reports "client_body_temp/00000000xx failed (2: No such file or directory)"

Symptoms

When performing an HTTP POST call, the request sometimes fails, with Phusion Passenger reporting an error along the lines of:

/tmp/passenger-standalone.8583/client_body_temp/0000000022" failed (2: No such
file or directory), client: 127.0.0.1, server: www.foo.com
Cause

Phusion Passenger buffers HTTP POST bodies (file uploads) to a temporary directory, by default /tmp/passenger-standalone.xxx. This error means that Phusion Passenger that that directory has been removed, probably by some other program.

Solution

Tell Phusion Passenger to use a different directory to store its temporary files passing the --temp-dir command line option. For example:

mkdir $HOME/tmp
cd /path-to-your-app
passenger start --temp-dir=$HOME/tmp

8. Appendix: About environment variables

The Phusion Passenger compilation process can be customized with environment variables.

Environment variables are named values that affect how the system works. For example they tell the system where to look for commands (the PATH variable) or where to look for libraries (LD_LIBRARY_PATH). Their names are often in all-uppercase. Sometimes people refer to an environment variable with a dollar sign $ in front, but that’s the same thing: when people say "the $PATH environment variable" they mean "the PATH environment variable". This is because the dollar sign $ is a shell syntax for refering to an environment variable, as you will learn later.

Environment variables are set on a per-process basis, but they are inherited by child processes. This means that if you set environment variables in process A, another already running process B will not see these new environment variables. But if A spawns a child process C, then C will have all environment variables that A had. If you once again change the environment variables in A, then C will not see the changes.

The per-process nature of environment variables some implications. When you set environment variables in your bashrc or other bash startup files…

  • …only newly spawned bash shells see them.

  • …the web server usually does not see them, because the web server tends to be started from init scripts, not from bash.

  • …cron jobs do not see them, because cron jobs' environment variables are entirely dictated by their crontabs.

Note Because this chapter is meant for beginners, it assumes that the reader uses the bash shell. This chapter does not describe instructions for zsh, csh or other shells. We assume that users of other shells are familiar with the Bourne shell syntax, and know how to apply the instructions in this chapter in their shells' native syntaxes.

8.1. Working with environment variables

You can see all environment variables in your shell by running the following command:

env

You can set an evironment variable with the syntax export <NAME>=<VALUE>. For example, to set the APXS2 variable to the value /usr/sbin/apxs2:

export APXS2=/usr/sbin/apxs2

Any process that you run from your shell from that point on will have said environment variable:

export APXS2=/usr/sbin/apxs2
ruby -e 'p ENV["APXS2"]'
# => "/usr/sbin/apxs2"
Note
The "export" keyword is important

You must set the export keyword. If you omit the export keyword then the environment variable will not be visible to other processes:

APXS2=/usr/sbin/apxs2
ruby -e 'p ENV["APXS2"]'
# => nil

You can reference an environment variable in your shell by typing the $ sign followed by the environment variable’s name. For example, to see the value of the PATH variable:

echo $PATH

You can also use this trick to extend the value of an environment variable:

export PATH=/usr/bin

# Prepends '/opt/local/bin', so that it becomes /opt/local/bin:/usr/bin
export PATH=/opt/local/bin:$PATH
# Appends '/usr/local/bin', so that it becomes /opt/local/bin:/usr/bin:/usr/local/bin
export PATH=$PATH:/usr/local/bin

8.2. The PATH environment variable

The PATH environment variable dictates where the system looks for command. It is a colon-separated list of directories. If you get a "command not found" error while you know that the command is installed, then setting PATH will help. For example suppose that the command frobnicator is in /opt/local/bin:

user@localhost bash$ frobnicator
bash: frobnicator: command not found

We verify that /opt/local/bin is not in PATH:

user@localhost bash$ echo $PATH
/bin:/usr/bin:/usr/local/bin

We can run frobnicator through it’s full path…

user@localhost bash$ /opt/local/bin/frobnicator
# => success!

…or we can add /opt/local/bin to PATH.

user@localhost bash$ export PATH=$PATH:/opt/local/bin
user@localhost bash$ frobnicator
# => success!

8.2.1. Adding Phusion Passenger’s administration tools to PATH

If you get a "command not found" error when invoking one of the Phusion Passenger administration tools (e.g. passenger-status or passenger-memory-stats then that means the tools are not in PATH, so you need to add them.

  • If you installed Phusion Passenger with RubyGems, then the tools are in your RubyGems executable path. You can view the gem path using the command gem env:

    $ gem env
    RubyGems Environment:
      - RUBYGEMS VERSION: 1.8.15
      - RUBY VERSION: 1.8.7 (2011-12-28 patchlevel 357) [i686-darwin10.8.0]
      - INSTALLATION DIRECTORY: /opt/ruby-enterprise-1.8.7-2010.01/lib/ruby/gems/1.8
      - RUBY EXECUTABLE: /opt/ruby-enterprise-1.8.7-2010.01/bin/ruby
      - EXECUTABLE DIRECTORY: /opt/ruby-enterprise-1.8.7-2010.01/bin    <--------- !!
      - RUBYGEMS PLATFORMS:
        - ruby
        - x86-darwin-10
      - GEM PATHS:
         - /opt/ruby-enterprise-1.8.7-2010.01/lib/ruby/gems/1.8
         - /Users/hongli/.gem/ruby/1.8
      - GEM CONFIGURATION:
         - :update_sources => true
         - :verbose => true
         - :benchmark => false
         - :backtrace => false
         - :bulk_threshold => 1000
         - "gem" => "--no-ri --no-rdoc"
      - REMOTE SOURCES:
         - http://rubygems.org/

    As you can see, the RubyGems executable path in the example happens to be /opt/ruby-enterprise-1.8.7-2010.01/bin. So that directory must be added to PATH.

  • If you installed Phusion Passenger using the tarball, then the tools are in the bin subdirectory of the Phusion Passenger tarball directory that you extracted. For example, if you extracted passenger-4.9.0.tar.gz inside /opt, then the tools are located in /opt/passenger-4.0.9/bin. In that case, you need to add /opt/passenger-4.0.9/bin to your PATH.

  • If you installed Phusion Passenger using native OS packages, then some Phusion Passenger administration tools are in /usr/bin, while others are in /usr/sbin. If you are not logged in as root, then /usr/sbin may not be in PATH, which would explain why you get a "command not found" when trying to invoke some of the tools. You should /usr/sbin to PATH.

  • If you are unsure where your Phusion Passenger directory is then you can use the find command to look them up. Go to the root directory and invoke find with sudo:

    $ cd /
    $ sudo find . -name passenger-status
    /usr/local/passenger/bin/passenger-status

    In this example, the administration tools happen to be in /usr/local/passenger/bin, so you must add that to PATH.

Note You may still get a "command not found" when invoking the tools through sudo, even after you’ve added the relevant directory to PATH. Please read Environment variables and sudo to learn more.

8.3. Making environment variables permanent

When you exit your shell, the evironment variable changes are lost. There is no standard method to set environment variables system-wide, so you have to set them in different configuration files for different services.

8.3.1. bash

To make environment variables permanent for future bash sessions for the current user, add them to your ~/.bashrc:

echo 'export FOO=bar' >> ~/.bashrc
echo 'export PATH=/usr/local/bin:$PATH' >> ~/.bashrc

To make them permanent for future bash sessions for all users, add them to /etc/bashrc.

Note Depending on the system, the bashrc file may have a different filename. On Debian and Ubuntu, it’s /etc/bash.bashrc.

8.3.2. Apache

Note This subsection describes how to set environment variables on Apache itself, not on apps served through Phusion Passenger for Apache. The environment variables you set here will be passed to all apps, but you cannot customize them on a per-app basis. See also Setting environment variables on Phusion Passenger-served apps.

On Debian and Ubuntu, with an Apache installed through apt, Apache environment variables are defined in the file /etc/apache2/envvars. This is a shell script so environment variables must be specified with the shell syntax.

On Red Hat, Fedora, CentOS and ScientificLinux, with an Apache installed through YUM, Apache environment variables are defined in /etc/sysconfig/httpd.

On OS X they are defined in /System/Library/LaunchDaemons/org.apache.httpd.plist, as explained here on Stack Overflow.

On other systems, or if you did not install Apache through the system’s package manager, the configuration file for environment variables is specific to the vendor that supplied Apache. There may not even be such a configuration file. You should contact the vendor for support.

8.3.3. Nginx

Note This subsection describes how to set environment variables on Nginx itself, not on apps served through Phusion Passenger for Nginx. The environment variables you set here will be passed to all apps, but you cannot customize them on a per-app basis. See also Setting environment variables on Phusion Passenger-served apps.

If you installed Nginx through the Debian or Ubuntu packages, then you can define environment variables in /etc/default/nginx. This is a shell script so you must use the export FOO=bar syntax.

Otherwise, environment variables are best set through the script which starts Nginx. For example, if you installed Nginx from source and you used then you should edit that script to define the environment variables. Those init scripts are regular shell scripts, so use the export FOO=bar syntax. Just make sure your set your environment variables before the script starts Nginx.

Note Setting environment variables on Nginx has no effect on the Flying Passenger daemon because the daemon is started seperately. You should set the environment variables in the shell right before starting the daemon.

8.3.4. cron

To make environment variables permanent for cron jobs, add those variables to the relevant crontab. But note that inside crontabs you cannot refer to existing environment variables with the $ syntax because crontabs are not shell scripts. You have to specify the entire value.

What to put in "crontab -e"
# Environment variable definitions
FOO=bar
APXS2=/usr/sbin/apxs2

# **WRONG!** You cannot refer to existing variables with the `$` syntax!
PATH=/usr/bin:$PATH
# **WRONG!** You cannot use the 'export' keyword!
export PATH=/usr/bin:/usr/local/bin
# Correct:
PATH=/usr/bin:/usr/local/bin

# Jobs:
# m h  dom mon dow   command
  * *  *   *   *     frobnicator

8.3.5. Phusion Passenger-served apps

You can pass environment variables to Phusion Passenger-served apps through various methods:

  • When running Apache, use the PassEnv and SetEnv directives of mod_env. This is supported starting from Phusion Passenger 4.0.

  • When running Nginx, use the passenger_set_cgi_param directive.

  • Through your bashrc. Starting from version 4.0, Phusion Passenger 4.0 spawns applications through bash and inherit all bash environment variables. Phusion Passenger Standalone tends to be started from the shell and thus inherits all environment variables set by the shell.

  • Through Apache and Nginx, as described earlier in this chapter. Any environment variables that you set on Apache and Nginx itself are inherited by Phusion Passenger, and thus by Phusion Passenger-served apps as well.

  • Through the application itself. Most programming languages provide APIs for setting environment variables. For example in Ruby you can write:

    ENV['FOO'] = 'bar'

    In Python you can write:

    import os
    os.environ['FOO'] = 'bar'

8.4. Environment variables and sudo

Note RVM users should always use the rvmsudo command instead of sudo. However all information in this section apply to rvmsudo as well.

The sudo command resets all environment variables before running the specified command, for security reasons. So if you set environment variables before running sudo passenger-install-xxx-module, sudo passenger-status or any other commands, then the environment variables are not correctly passed to the command. You can solve this by running sudo with -E (preserve environment variables):

user@localhost bash$ export APXS2=/usr/sbin/apxs2
user@localhost bash$ sudo -E passenger-install-apache2-module

Alternatively, you can obtain a root prompt with sudo first, and then set the environment variables, before running any further commands:

user@localhost bash$ sudo -s
Password: ...
root@localhost bash# export APXS2=/usr/sbin/apxs2
root@localhost bash# passenger-install-apache2-module

Note that for security reasons, sudo always resets the PATH environment variable, even if you pass -E! You can get around this problem by obtaining a root prompt first, and then set the environment variables:

user@localhost bash$ sudo -s
Password: ...
root@localhost bash# export PATH=$PATH:/opt/myruby/bin
root@localhost bash# passenger-install-apache2-module