Phusion Passenger users guide, Nginx version

During step 3 of the Installing packages subsection, you were instructed to uncomment the passenger_root directive in /etc/nginx/nginx.conf. If there is no commented version in there, then you need to insert it yourself.

First, run the following command and take note of its output:

Next, insert the following snippet into /etc/nginx/nginx.conf, under the http block:

Here is an example:

Once you’re done editing nginx.conf, continue with step 4.

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.

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

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:

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.

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

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

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:

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

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

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:

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

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:

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:

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:

For Camping versions 2.0 and up, using run Blog as the final line will do.

This option may be specified in the http configuration block, a server configuration block, a location configuration block or an if configuration scope, to enable or disable Phusion Passenger for that server or that location.

Phusion Passenger is disabled by default, so you must explicitly enable it for server blocks that you wish to serve through Phusion Passenger. Please see Deploying a Rack-based Ruby application and Deploying a WSGI (Python) application for examples.

Used to specify that the given URI is an distinct application that should be served by Phusion Passenger. Please refer to the following sections for more information:

It is allowed to specify this option multiple times. Do this to deploy multiple applications in different sub-URIs under the same virtual host.

This option may occur in the following places:

Used in sub-URI deployment scenarios to tell Phusion Passenger where it should look for static files. Please refer to the following sections for more information:

This option may occur in the following places:

In each place, it may be specified at most once.

The passenger_ruby option allows one to specify the Ruby interpreter to use. Similarly, the passenger_python and passenger_nodejs options are for specifying the Python interpreter and Node.js commands, respectively.

In versions prior to 4.0.0, only a single Ruby version was supported for the entire Nginx instance, so passenger_ruby may only occur in the global server configuration. Also, the passenger_python/passenger_nodejs options were not supported.

Since version 4.0.0, Phusion Passenger supports multiple Ruby interpreters in the same Nginx instance. And so, since version 4.0.0, this option may occur in the following places:

The passenger_ruby in the http block - that is, the one that passenger-install-nginx-module outputs - is used for invoking certain Phusion Passenger tools that are written in Ruby, e.g. the internal helper script used by passenger_pre_start. It is okay if the value refers to a different Ruby interpreter than the one you originally installed Phusion Passenger with. You can learn more about all this in Phusion Passenger and its relationship with Ruby.

The passenger_ruby directive in the http block is also used as the default Ruby interpreter for Ruby web apps. You don’t have to specify a passenger_ruby in the http block though, because the default is to use the first ruby command found in $PATH.

The passenger_python and passenger_nodejs options work in a similar manner, but apply to Python and Node.js instead.

You can also override passenger_ruby and other directives in specific contexts if you want to use a different interpreter for that web app. For example:

Phusion Passenger provides the passenger-config --ruby-command tool for figuring out the correct command for invoking a specific Ruby interpreter. This is especially useful for RVM users. Suppose that you have both Ruby 1.8.7 and Ruby 1.9.3 installed through RVM, and you want to know the correct commands for each Ruby interpreter.

For this purpose we’ll want to invoke passenger-config using its full path, because each time you rvm use a different Ruby interpreter, RVM changes $PATH. If you did not install Phusion Passenger through the generic tarball installation method, then here’s how you can figure out where passenger-config is:

Now, switch to all the RVM Ruby interpreters you want to use. In each interpreter, invoke passenger-config --ruby-command. For Ruby 1.8.7:

Then, for Ruby 1.9.3:

Introduced in version 4.0.0.

This option allows one to specify the Python interpreter to use. See passenger_ruby for more information. The default value is python, meaning that the Python interpreter will be looked up according to the PATH environment variable.

Introduced in version 4.0.24.

This option allows one to specify the Node.js command to use. See passenger_ruby for more information. The default value is node, meaning that the Node.js command will be looked up according to the PATH environment variable.

This option sets the value of the following environment variables:

Some web frameworks, for example Rails and Connect.js, adjust their behavior according to the value in one of these environment variables.

Phusion Passenger for Nginx sets the default value to production. If you’re developing an Rails application then you should set this to development.

If you want to set other environment variables, please refer to Setting environment variables for Phusion Passenger-served apps.

Setting this option also adds the application environment name to the default application group name, so that you can run multiple versions of your application with different application environment names.

This option may occur in the following places:

In each place, it may be specified at most once. The default value is production.

An alias for passenger_app_env.

An alias for passenger_app_env.

Introduced in version 4.0.0.

By default, Phusion Passenger assumes that the application’s root directory is the parent directory of the public directory. This option allows one to specify the application’s root independently from the Nginx root, which is useful if the public directory lives in a non-standard place.

This option may occur in the following places:

In each place, it may be specified at most once.

Example:

Sets the name of the application group that the current application should belong to. Its default value is the virtual host’s root directory, plus (if it is set), the application environment name.

Phusion Passenger stores and caches most application spawning settings — such as environment variables, process limits, etc — on a per-app-group-name basis. This means that if you want to start two versions of your application, with each version having different environment variables, then you must assign them under different application group names.

For example, consider a situation in which you are running multiple versions of the same app, with each version intended for a different customer. You use the CUSTOMER_NAME environment variable to tell the app which customer that version should serve.

This example doesn’t work, because Phusion Passenger thinks that they are the same application. When a user visits customer1.foo.com, Phusion Passenger will start a process with CUSTOMER_NAME=customer1. When another user visits customer2.foo.com, Phusion Passenger will route the request to the application process that was started earlier. Because environment variables are only set during application process startup, the second user will be served the website for customer 1.

To make this work, assign unique application group names:

Note that it is not necessary to set passenger_app_group_name if you want to run two versions of your application under different application environment names, because the application environment name is included in the default application group name. For example, consider a situation in which you want to run a production and a staging version of your application. The following configuration will work fine:

This option may occur in the following places:

In each place, it may be specified at most once.

Introduced in version 4.0.25.

By default, Phusion Passenger autodetects the type of the application, e.g. whether it’s a Ruby, Python, Node.js or Meteor app. If it’s unable to autodetect the type of the application (e.g. because you’ve specified a custom passenger_startup_file) then you can use this option to force Phusion Passenger to recognize the application as a specific type.

Allowed values are:

This option may occur in the following places:

In each place, it may be specified at most once.

Example:

Introduced in version 4.0.25.

This option specifies the startup file that Phusion Passenger should use when loading the application.

Every application has a startup file or entry point file: a file where the application begins execution. Some languages have widely accepted conventions about how such a file should be called (e.g. Ruby, with its config.ru). Other languages have somewhat-accepted conventions (e.g. Node.js, with its app.js). In these cases, Phusion Passenger reuses these conventions, and executes applications through those files.

Other languages have no conventions at all, and so Phusion Passenger invents one (e.g. Python WSGI with passenger_wsgi.py).

Here’s a list of the language-specific conventions that Phusion Passenger accepts:

But sometimes you might not want to adhere to the convention that Phusion Passenger accepts. For example, on Node.js, you might want to use server.js as the startup file instead of the default app.js. With this option, you can customize the startup file to any file you like.

Notes:

This option may occur in the following places:

In each place, it may be specified at most once.

Example:

Internally, Phusion Passenger spawns multiple Ruby application processes in order to handle requests. But there are multiple ways with which processes can be spawned, each having its own set of pros and cons. Supported spawn methods are:

This option may occur in the following places:

In each place, it may be specified at most once. The default value is smart.

Introduced in version 5.0.0.

Sets environment variables to pass to the application. Environment variables are only set during application loading.

Example:

This option may occur in the following places:

In each place, it may be specified multiple times.

Introduced in version 4.0.20.

Enables or disables the loading of shell environment variables before spawning the application.

If this option is turned on, and the user’s shell is bash, then applications are loaded by running them with bash -l -c. Otherwise, they are loaded by running them directly from the PassengerHelperAgent process.

This option may occur in the following places:

In each place, it may be specified at most once. The default value is on.

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

Enables or disables support for rolling restarts through restart.txt. Normally when you restart an application by touching restart.txt, Phusion Passenger would shut down all application processes and spawn a new one. The spawning of a new application process could take a while, and any requests that come in during this time will be blocked until this first application process has spawned.

But when rolling restarts are enabled, Phusion Passenger Enterprise will:

This way, visitors will not experience any delays when you are restarting your application. This allows you to, for example, upgrade your application often without degrading user experience.

Rolling restarts have a few caveat however that you should be aware of:

If Passenger Enterprise could not rolling restart a process (let’s call it A) because it is unable to spawn a new process (let’s call it B), then Passenger Enterprise will give up trying to rolling restart that particular process A. What happens next depends on whether deployment error resistance is enabled:

Please note that passenger_rolling_restarts is completely unrelated to the passenger-config restart-app command. That command always initiates a blocking restart, unless --rolling-restart is given.

This option may occur in the following places:

In each place, it may be specified at most once. The default value is off.

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

Enables or disables resistance against deployment errors.

Suppose you’ve upgraded your application and you’ve issued a command to restart it (e.g. by touching restart.txt), but the application code contains an error that prevents Phusion Passenger from successfully spawning a process (e.g. a syntax error). Phusion Passenger would normally display an error message in response to this.

By enabling deployment error resistance, Phusion Passenger Enterprise would instead do this:

This way, visitors will suffer minimally from deployment errors. Phusion Passenger will attempt to restart the application again next time restart.txt is touched, or when you issue the passenger-config restart-app command.

Enabling deployment error resistance only works if rolling restart is also enabled.

This option may occur in the following places:

In each place, it may be specified at most once. The default value is off.

Whether to enable user switching support.

This option may only occur once, in the http configuration block. The default value is on.

If user switching support is enabled, then Phusion Passenger will by default run the web application as the owner of the file config/environment.rb (for Rails apps) or config.ru (for Rack apps). This option allows you to override that behavior and explicitly set a user to run the web application as, regardless of the ownership of environment.rb/config.ru.

This option may occur in the following places:

In each place, it may be specified at most once.

If user switching support is enabled, then Phusion Passenger will by default run the web application as the primary group of the owner of the file config/environment.rb (for Rails apps) or config.ru (for Rack apps). This option allows you to override that behavior and explicitly set a group to run the web application as, regardless of the ownership of environment.rb/config.ru.

<group name> may also be set to the special value !STARTUP_FILE!, in which case the web application’s group will be set to environment.rb/config.ru's group.

This option may occur in the following places:

In each place, it may be specified at most once.

Phusion Passenger enables user switching support by default. This configuration option allows one to specify the user that applications must run as, if user switching fails or is disabled.

This option may only occur once, in the http configuration block. The default value is nobody.

Phusion Passenger enables user switching support by default. This configuration option allows one to specify the group that applications must run as, if user switching fails or is disabled.

This option may only occur once, in the http configuration block. The default value is the primary group of the user specifified by passenger_default_user.

When turned on, Phusion Passenger will output its version number in the Server and X-Powered-By header in all Phusion Passenger-served requests:

When turned off, the version number will be hidden:

This option may only occur once, in the http configuration block. The default value is on.

Phusion Passenger can display friendly error pages whenever an application fails to start. This friendly error page presents the startup error message, some suggestions for solving the problem, a backtrace and a dump of the environment variables. This feature is very useful during application development and useful for less experienced system administrators, but the page might reveal potentially sensitive information, depending on the application. For this reason, friendly error pages are turned off by default when passenger_app_env (and its aliases such as rails_env and rack_env) is set to staging or production, but enabled by default otherwise. You can use this option to explicitly enable or disable this feature.

This option may occur in the following places:

In each place, it may be specified at most once. The default value depends on passenger_app_env (and its aliases such as rails_env and rack_env), as documented above.

The maximum number of application processes that may simultanously exist. A larger number results in higher memory usage, but improves the ability to handle concurrent HTTP requests.

The optimal value depends on your system’s hardware and your workload. You can learn more at the Phusion article Tuning Phusion Passenger’s concurrency settings.

If you find that your server is running out of memory then you should lower this value.

This option may only occur once, in the http configuration block. The default value is 6.

This specifies the minimum number of application processes that should exist for a given application. You should set this option to a non-zero value if you want to avoid potentially long startup times after a website has been idle for an extended period.

Please note that this option does not pre-start application processes during Nginx startup. It just makes sure that when the application is first accessed:

If you want to pre-start application processes during Nginx startup, then you should use the passenger_pre_start directive, possibly in combination with passenger_min_instances. This behavior might seem counter-intuitive at first sight, but passenger_pre_start explains the rationale behind it.

For example, suppose that you have the following configuration:

When you start Nginx, there are 0 application processes for foobar.com. Things will stay that way until someone visits foobar.com. Suppose that there is only 1 visitor. 1 application process will be started immediately to serve the visitor, while 2 will be spawned in the background. After 10 seconds, when the idle timeout has been reached, these 3 application processes will not be cleaned up.

Now suppose that there’s a sudden spike of traffic, and 100 users visit foobar.com simultanously. Phusion Passenger will start 12 more application processes. After the idle timeout of 10 seconds have passed, Phusion Passenger will clean up 12 application processes, keeping 3 processes around.

The passenger_min_instances option may occur in the following places:

In each place, it may be specified at most once. The default value is 1.

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

The maximum number of application processes that may simultaneously exist for an application. This helps to make sure that a single application will not occupy all available slots in the application pool.

This value must be less than passenger_max_pool_size. A value of 0 means that there is no limit placed on the number of processes a single application may spawn, i.e. only the global limit of passenger_max_pool_size will be enforced.

This option may occur in the following places:

In each place, it may be specified at most once. The default value is 0.

The maximum number of application processes that may simultaneously exist for a single application. This helps to make sure that a single application will not occupy all available slots in the application pool.

This value must be less than passenger_max_pool_size. A value of 0 means that there is no limit placed on the number of processes a single application may use, i.e. only the global limit of passenger_max_pool_size will be enforced.

This option may only occur once, in the http configuration block. The default value is 0.

The maximum number of seconds that an application process may be idle. That is, if an application process hasn’t received any traffic after the given number of seconds, then it will be shutdown in order to conserve memory.

Decreasing this value means that applications will have to be spawned more often. Since spawning is a relatively slow operation, some visitors may notice a small delay when they visit your Rails/Rack website. However, it will also free up resources used by applications more quickly.

The optimal value depends on the average time that a visitor spends on a single Rails/Rack web page. We recommend a value of 2 * x, where x is the average number of seconds that a visitor spends on a single Rails/Rack web page. But your mileage may vary.

When this value is set to 0, application processes will not be shutdown unless it’s really necessary, i.e. when Phusion Passenger is out of worker processes for a given application and one of the inactive application processes needs to make place for another application process. Setting the value to 0 is recommended if you’re on a non-shared host that’s only running a few applications, each which must be available at all times.

This option may only occur once, in the http configuration block. The default value is 300.

The preloader process (explained in Spawning methods explained) has an idle timeout, just like the backend processes spawned by Phusion Passenger do. That is, it will automatically shutdown if it hasn’t done anything for a given period.

This option allows you to set the prealoader’s idle timeout, in seconds. A value of 0 means that it should never idle timeout.

Setting a higher value will mean that the preloader is kept around longer, which may slightly increase memory usage. But as long as the preloader is running, the time to spawn a Ruby on Rails backend process only takes about 10% of the time that is normally needed, assuming that you’re using the smart spawning method. So if your system has enough memory, is it recommended that you set this option to a high value or to 0.

This option may occur in the following places:

In each place, it may be specified at most once. The default value is 300 (5 minutes).

Introduced in version 4.0.15.

Specifies a timeout for the startup of application processes. If an application process fails to start within the timeout period then it will be forcefully killed with SIGKILL, and the error will be logged.

This option may occur in the following places:

In each place, it may be specified at most once. The default value is 90.

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

Specifies the I/O concurrency model that should be used for Ruby application processes. Phusion Passenger supports two concurrency models:

This option has no effect on non-Ruby applications.

This option may occur in the following places:

In each place, it may be specified at most once. The default value is process.

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

Specifies the number of threads that Phusion Passenger should spawn per Ruby application process. This option only has effect if passenger_concurrency_model is thread.

This option has no effect on non-Ruby applications.

This option may occur in the following places:

In each place, it may be specified at most once. The default value is 1.

The maximum number of requests an application process will process. After serving that many requests, the application process will be shut down and Phusion Passenger will restart it. A value of 0 means that there is no maximum: an application process will thus be shut down when its idle timeout has been reached.

This option is useful if your application is leaking memory. By shutting it down after a certain number of requests, all of its memory is guaranteed to be freed by the operating system.

This option may occur in the following places:

In each place, it may be specified at most once. The default value is 0.

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

The maximum amount of time, in seconds, that an application process may take to process a request. If the request takes longer than this amount of time, then the application process will be forcefully shut down, and possibly restarted upon the next request. A value of 0 means that there is no time limit.

This option is useful for preventing your application from freezing for an indefinite period of time.

This option may occur in the following places:

In each place, it may be specified at most once. The default value is 0.

Suppose that most of your requests are known to finish within 2 seconds. However, there is one URI, /expensive_computation, which is known to take up to 10 seconds. You can then configure Phusion Passenger as follows:

If a request to /expensive_computation takes more than 10 seconds, or if a request to any other URI takes more than 2 seconds, then the corresponding application process will be forced to shutdown.

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

The maximum amount of memory that an application process may use, in megabytes. Once an application process has surpassed its memory limit, it will process all the requests currently present in its queue and then shut down. A value of 0 means that there is no maximum: the application’s memory usage will not be checked.

This option is useful if your application is leaking memory. By shutting it down, all of its memory is guaranteed to be freed by the operating system.

This option may occur in the following places:

In each place, it may be specified at most once. The default value is 0.

By default, Phusion Passenger performs several filesystem checks (or, in programmers jargon, stat() calls) each time a request is processed:

On some systems where disk I/O is expensive, e.g. systems where the harddisk is already being heavily loaded, or systems where applications are stored on NFS shares, these filesystem checks can incur a lot of overhead.

You can decrease or almost entirely eliminate this overhead by setting PassengerStatThrottleRate. Setting this option to a value of x means that the above list of filesystem checks will be performed at most once every x seconds. Setting it to a value of 0 means that no throttling will take place, or in other words, that the above list of filesystem checks will be performed on every request.

This option may be specified once, in the http configuration block. The default value is 10.

By default, Phusion Passenger does not start any application processes until said web application is first accessed. The result is that the first visitor of said web application might experience a small delay as Phusion Passenger is starting the web application on demand. If that is undesirable, then this directive can be used to pre-started application processes during Nginx startup.

A few things to be careful of:

This option may only occur in the http configuration block. It may be specified any number of times.

Sets additional HTTP headers to pass to the web application. This is comparable to ngx_http_proxy_module’s proxy_set_header option. Nginx variables in the value are interpolated.

Example:

This option may occur in the following places:

In each place, it may be specified multiple times.

Introduced in version 4.0.15.

When all application processes are already handling their maximum number of concurrent requests, Phusion Passenger will queue all incoming requests. This option specifies the maximum size for that queue. If the queue is already at this specified limit, then Phusion Passenger will immediately send a "503 Service Unavailable" error to any incoming requests. You may use passenger_request_queue_overflow_status_code to customize the response status.

A value of 0 means that the queue is unbounded.

This article on StackOverflow explains how the request queue works, what it means for the queue to grow or become full, why that is bad, and what you can do about it.

You may combine this option with passenger_intercept_errors and error_page to set a custom error page whenever the queue is full. In the following example, Nginx will serve /error503.html whenever the queue is full:

This option may occur in the following places:

In each place, it may be specified at most once. The default value is 100.

Introduced in version 4.0.15.

This option allows you to customize the HTTP status code that is sent back when the request queue is full. See passenger_max_request_queue_size for more information.

This option may occur in the following places:

In each place, it may be specified at most once. The default value is 503.

Introduced in version 4.0.45.

When sticky sessions are enabled, all requests that a client sends will be routed to the same originating application process, whenever possible. When sticky sessions are disabled, requests may be distributed over multiple processes, and may not necessarily be routed to the originating process, in order to balance traffic over multiple CPU cores. Because of this, sticky sessions should only be enabled in specific circumstances.

For applications that store important state inside the process’s own memory — that is, as opposed to storing state in a distributed data store, such as the database or Redis — sticky sessions should be enabled. This is because otherwise, some requests could be routed to a different process, which stores different state data. Because processes don’t share memory with each other, there’s no way for one process to know about the state in another process, and then things can go wrong.

One prominent example is the popular SockJS library, which is capable of emulating WebSockets through long polling. This is implemented through two HTTP endpoints, /SESSION_ID/xhr_stream (a long polling end point which sends data from the server to the client), and /SESSION_ID/xhr_send (a normal POST endpoint which is used for sending data from the client to the server). SockJS correlates the two requests with each other through a session identifier. At the same time, in its default configuration, it stores all known session identifiers in an in-memory data structure. It is therefore important that a particular /SESSION_ID/xhr_send request is sent to the same process where the corresponding /SESSION_ID/xhr_stream request originates from; otherwise, SockJS cannot correlate the two requests, and an error occurs.

So prominent examples where sticky sessions should (or even must) be enabled, include:

Sticky sessions work through the use of a special cookie, whose name can be customized with passenger_sticky_sessions_cookie_name. Phusion Passenger puts an identifier in this cookie, which tells Phusion Passenger what the originating process is. Next time the client sends a request, Phusion Passenger reads this cookie and uses the value in the cookie to route the request back to the originating process. If the originating process no longer exists (e.g. because it has crashed or restarted) then Phusion Passenger will route the request to some other process, and reset the cookie.

If you have a load balancer in front end of Phusion Passenger + Nginx, then you must configure sticky sessions on that load balancer too. Otherwise, the load balancer could route the request to a different server.

This option may occur in the following places:

In each place, it may be specified at most once. The default value is off.

Introduced in version 4.0.45.

Sets the name of the sticky sessions cookie.

This option may occur in the following places:

In each place, it may be specified at most once. The default value is _passenger_route.

Normally, when the HTTP client aborts the connection (e.g. when the user clicked on "Stop" in the browser), the connection with the application process will be closed too. If the application process continues to send its response, then that will result in EPIPE errors in the application, which will be printed in the error log if the application doesn’t handle them gracefully.

If this option is turned on then upon client abort Phusion Passenger will continue to read the application process’s response while discarding all the read data. This prevents EPIPE errors but it’ll also mean the backend process will be unavailable for new requests until it is done sending its response.

This option may occur in the following places:

In each place, it may be specified at most once. The default value is off.

Introduced in version 4.0.15.

Decides if Nginx will intercept responses with HTTP status codes of 400 and higher.

By default, all responses are sent as-is from the application or from the Phusion Passenger core. If you turn this option on then Nginx will be able to handle such responses using the Nginx error_page option. Responses with status codes that do not match an error_page option are sent as-is.

This option may occur in the following places:

In each place, it may be specified at most once. The default value is off.

Some headers generated by backend applications are not forwarded to the HTTP client, e.g. X-Accel-Redirect which is directly processed by Nginx and then discarded from the final response. This directive allows one to force Nginx to pass those headers anyway, similar to how proxy_pass_header works.

For example:

This option may occur in the following places:

Disables processing of certain response header fields from the application, similar to how proxy_ignore_headers works.

This option may occur in the following places:

Sets the bucket size of the hash tables used by the passenger_set_header directive. The details of setting up hash tables are can be found in the Nginx documentation.

This option may occur in the following places:

In each place, it may be specified at most once. The default value is 64.

Sets the maximum size of the hash tables used by the passenger_set_header directive. The details of setting up hash tables are can be found in the Nginx documentation.

This option may occur in the following places:

In each place, it may be specified at most once. The default value is 512.

When turned on, application-generated responses are buffered by Nginx. Buffering will happen in memory and also on disk if the response is larger than a certain threshold.

Before we proceed with explaining this configuration option, we want to state the following to avoid confusion. If you use Phusion Passenger for Nginx, there are in fact two response buffering systems active:

Response buffering is useful because it protects against slow HTTP clients that do not read responses immediately or quickly enough. Buffering prevents such slow clients from blocking web applications that have limited concurrency. Because Phusion Passenger’s response buffering is always turned on, you are always protected. Therefore, passenger_buffer_response is off by default, and you never should have to turn it on.

If for whatever reason you want to turn Nginx-level response buffering on, you can do so with this option.

Nginx’s response buffering works differently from Phusion Passenger’s. Nginx’s buffering system buffers the entire response before attempting to send it to the client, while Phusion Passenger’s attempts to send the data to the client immediately. Therefore, if you turn on passenger_buffer_response, you may interfere with applications that want to stream responses to the client.

How does response buffering - whether it’s done by Nginx or by Phusion Passenger - exactly protect against slow clients? Consider an HTTP client that’s on a dial-up modem link, and your application process generates a 2 MB response. If the response is not buffered then your application process will be blocked until the entire 2 MB has been sent out to the HTTP client. This disallows your application process to do any useful work in the mean time. By buffering responses, Phusion Passenger or Nginx will read the application response as quickly as possible and will take care of forwarding the data to slow clients.

So keep in mind that enabling passenger_buffering_response will make streaming responses impossible. Consider for example this piece of Rails code:

…or this piece of Rack code:

When passenger_buffer_response is turned on, Nginx will wait until the application is done sending the entire response before forwarding it to the client. The client will not receive anything for 10 seconds, after which it receives the entire response at once. When passenger_buffer_response is turned off, it works as expected: the client receives an "entry X" message every second for 10 seconds.

This option may occur in the following places:

In each place, it may be specified at most once. The default value is off.

These options have the same effect as proxy_module’s similarly named options. They can be used to modify the maximum allowed HTTP header size.

This option allows one to specify how much information Phusion Passenger should write to the Nginx error log file. A higher log level value means that more information will be logged.

Possible values are:

This option may only occur once, in the http configuration block. The default is 3.

By default Phusion Passenger debugging and error messages are written to the global web server error log. This option allows one to specify the file that debugging and error messages should be written to instead.

This option may only occur once, in the http configuration block.

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

Turns support for application debugging on or off. In case of Ruby applications, turning this option on will cause them to load the ruby-debug gem (when on Ruby 1.8), the debugger gem (when on Ruby 1.9) or the byebug gem (when on Ruby 2.0). If you’re using Bundler, you should add this to your Gemfile:

Once debugging is turned on, you can use the command passenger-irb --debug <PID> to attach an rdebug console to the application process with the given PID. Attaching will succeed once the application process executes a debugger command.

This option may occur in the following places:

In each place, it may be specified at most once. The default value is off.

Introduced in version 5.0.0.

Specifies the directory that Phusion Passenger should use for registering its current instance.

When Phusion Passenger starts up, it creates a temporary directory inside the instance registry directory. This temporary directory is called the instance directory. It contains all sorts of files that are important to that specific running Phusion Passenger instance, such as Unix domain socket files so that all the different Phusion Passenger processes can communicate with each other. Command line tools such as passenger-status use the files in this directory in order to query Phusion Passenger’s status.

It is therefore important that, while Phusion Passenger is working, the instance directory is never removed or tampered with. However, the default path for the instance registry directory is the system’s temporary directory, and some systems may run background jobs that periodically clean this directory. If this happens, and the files inside the instance directory are removed, then it will cause Phusion Passenger to malfunction: Phusion Passenger won’t be able to communicate with its own processes, and you will see all kinds of connection errors in the log files. This malfunction can only be recovered from by restarting Nginx. You can prevent such cleaning background jobs from interfering by setting this option to a different directory.

This option is also useful if the partition that the temporary directory lives on doesn’t have enough disk space.

The instance directory is automatically removed when Nginx shuts down.

This option may be specified once, in the http configuration block. The default value is the value of the $TMPDIR environment variable. Or, if $TMPDIR is not set, /tmp.

Some Phusion Passenger command line administration tools, such as passenger-status, must know what Phusion Passenger’s instance registry directory is in order to function properly. You can pass the directory through the PASSENGER_INSTANCE_REGISTRY_DIR environment variable or the TMPDIR environment variable.

For example, if you set passenger_instance_registry_dir to /my_temp_dir, then invoke passenger-status after you’ve set the PASSENGER_INSTANCE_REGISTRY_DIR, like this:

Notes regarding the above example:

Introduced in version 5.0.0.

By default, Phusion Passenger buffers large web application responses. This prevents slow HTTP clients from blocking web applications by reading responses very slowly. This feature is also known as real-time disk-backed response buffering.

By default, such buffers are stored in the directory given by the $TMPDIR environment variable, or (if $TMPDIR is not set) the /tmp directory. This configuration directive allows you to specify a different directory.

Changing this option is especially useful if the partition that the default directory lives on doesn’t have enough disk space.

If you’ve specified such a directory (as opposed to using Phusion Passenger’s default) then you must ensure that this directory exists.

This option may be specified once, in the http configuration block.

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

Enables Flying Passenger mode, and configures Nginx to connect to the Flying Passenger daemon that’s listening on the given socket filename.

This option may only occur once, in the http configuration block. When not set, Flying Passenger is not enabled.

Deprecated in favor of passenger_spawn_method.

The "About your application’s environment" link only works if the application is started in the development environment. Phusion Passenger starts the application in the production environment by default. Please use rails_env to change it.

Please check whether your Rails application’s folder has the correct permissions. By default, Rails applications are started as the owner of the file config.ru, except if the file is owned by root. If the file is owned by root, then the Rails application will be started as nobody (or as the user specify by RailsDefaultUser, if that’s specified).

Please read User switching (security) for details.

There are a couple things that you should be aware of:

If you’re using a RedHat-derived Linux distribution (such as Fedora or CentOS) then it is possible that SELinux is interfering. RedHat’s SELinux policy only allows Apache to read/write directories that have the httpd_sys_content_t security context. Please run the following command to give your Rails application folder that context:

User switching is only enabled when all of the following conditions are met:

When not using Flying Passenger, the following table illustrates the effect for different combinations of the requirements.

When using Flying Passenger, the effect is as follows:

When user switching is enabled, the following rules are followed to determine what user an application should be run as. The first matching rule is the rule that will be followed.

If your application regularly encounters permission errors or fails to find certain files, then this is an indication that your application is started as a user that you did not intent it to be run as. Other symptoms include:

To check whether it is indeed the case that your application is started as a different user than you intended to, see Finding out what user an application is running as.

The most likely reason why your application is started as nobody is probably because your startup file is owned by root, by nobody or by an unknown user. To fix this, change the owner of the startup file to the owner that you want to run the application as.

Whatever user your application runs as, it must have read access to the application root, and read/write access to the application’s logs directory.

To find our what user an application is started as, first access its URL in your browser so that Phusion Passenger starts the application. For example:

The application will now either successfully start or fail to start. If it fails to start then you will see an error page that tells you what user the application was being started as. If you do not see the error page in the browser then set passenger_friendly_error_pages on.

If the application successfully started, then run passenger-status to find the process’s PID:

In the above example we see that the PID is 16915. Next, use ps to find out the user that it is running as:

As you can see, the application in this example is being run as user phusion.

It is never necessary to add Phusion Passenger to the application’s Gemfile. In case of Phusion Passenger Standalone, it is not necessary to execute the passenger command through bundle exec. The reason for this is because Phusion Passenger automatically loads the Gemfile environment. Most other Ruby application servers do not automatically load the Gemfile environment, which is why they must be added to the Gemfile and be executed with bundle exec.

Even when your application uses any of the Phusion Passenger APIs, you still do not need to add Phusion Passenger to the Gemfile. The only thing you need to do is to put Phusion Passenger API calls inside if blocks that check whether Phusion Passenger is active, by checking whether the PhusionPassenger namespace is defined:

The hook system is best demonstrated with a simple example. In the following example we will hook into the attached_process event. This event is called whenever Phusion Passenger has successfully spawned an application processes and added it to the process pool. We print the process’s PID and application root.

First, let’s create a script /home/phusion/attached.sh which is to be called during the hook.

Then we make it executable:

And we define the hook in the configuration file:

Now restart the web server and access a web app hosted by Phusion Passenger. You should see our message in the web server error log:

A lot of information is passed to hook scripts in the form of environment variables. They are all uppercase and begin with PASSENGER_. Some environment variables are passed to all hook scripts, others are passed depending on the hook.

Here are some of the environment variables which are passed to all hooks, unless documented otherwise:

Except when otherwise documented, all hooks block in the background. That is, while your hook command is running, Phusion Passenger can still handle web requests, but the background thread which is running your hook will be blocked and won’t be able to perform any further operations. For example, if you wrote a hook script for the attached_process event, then Phusion Passenger won’t be able to attach further processes until your hook script finishes. You should therefore be careful when writing hook scripts.

If you have a bug in your script and it blocks, then you will be able to see that using the command passenger-status --show=backtraces which prints the backtraces of all threads in the Phusion Passenger HelperAgent. Look for the runSingleHookScript function in the backtrace. The following example shows at line 2 that Phusion Passenger is waiting for the hook script /home/phusion/badscript.sh.

Hooks may be called concurrently, because Phusion Passenger sometimes uses multiple background threads. For example, while the attached_process hook is being called, a detached_process hook may be called, perhaps even for the same application. It is your responsibility to ensure that your hook scripts are concurrency-safe, e.g. by employing locks and other concurrency control techniques.

If a hook script fails — that is, if it exits with anything other than exit code 0 — then the error handling depends on the hook. Some hooks will abort, other hooks will ignore the error. In all cases, the result of the hook script is printed to the log.

Because hooks are inherently tied to the implementation of Phusion Passenger, there is no guarantee that hooks that currently work will continue to be available in the future versions of Phusion Passenger. The availability of hooks is very much tied to the specific version of Phusion Passenger.

Before you can use the Flying Passenger feature, you must have Phusion Passenger for Nginx properly installed.

Start the Flying Passenger daemon by invoking the flying-passenger command. The only required option is --socket-file. Depending on whether you wish to enable User Switching, you have to start flying-passenger with root privileges or not.

Now configure the web server to make use of the Flying Passenger daemon, by setting the passenger_fly_with option to the socket filename:

After (re)starting Nginx, Nginx + Flying Passenger is fully operational:

Flying Passenger is fully operational:

You can test it by adding a virtual host for a web app:

Verify that it works by making an HTTP request to it:

Now let’s verify that restarting the web server does not restart the just-spawned application process. Run passenger-status to obtain the PID of the application process:

As you can see, the PID of the application process is 77283. Now let’s see what happens if we restart the web server:

The application process should remain there, unchanged:

Flying Passenger gets some configuration from the web server, but not all. In particular, most web server directives that are only valid in the http context, e.g. passenger_log_level, have no effect when using Flying Passenger. Instead, you are supposed to pass these configuration directives through command line options to the Flying Passenger daemon. Configuration directives that have no effect on Flying Passenger are documented as such. You can assume that configuration directives that are not documented as such, work fine on Flying Passenger.

For example, to achieve the same effect as setting passenger_log_level to 2, run the Flying Passenger daemon as follows:

Currently, not all configuration directives have a Flying Passenger equivalent. Run the following command to see an overview of available options:

The Flying Passenger daemon runs in the foreground by default. This is undesirable on server environments. You can make it go into the background by passing --daemonize, --log-file and --pid-file:

You can shut down a Flying Passenger daemon by sending SIGINT or SIGTERM to it:

We recommend using daemontools or runit for managing the Flying Passenger daemon. These tools will allow automatically starting the Flying Passenger daemon at boot, and will automatically restart the daemon if it crashes. You can create and enable a daemontools/runit service as folows:

Immediately after creating the run file, daemontools/runit automatically runs it to start the daemon. Note that the location (/etc/service) depends on the OS or Linux distros. Sometimes it’s /service. Also note that we start the Flying Passenger daemon without --daemonize.

To shut down a daemontools/runit-managed daemon, you need to use svc -d /etc/service/flying-passenger (daemontools) or sv stop /etc/service/flying-passenger (runit) instead of sending a signal to the process.

Using Flying Passenger in combination with MRI Ruby 1.8 or with JRuby requires special attention. This is because the Flying Passenger daemon is written in Ruby, and requires proper Process.spawn support, which neither MRI 1.8 nor JRuby support.

It is however possible to use Flying Passenger with MRI Ruby 1.8 and JRuby. You can’t run the Flying Passenger daemon in MRI 1.8 or JRuby, but you can still run the web applications - hosted under Flying Passenger - in MRI 1.8 or JRuby.

First, edit your web server configuration file and specify a Ruby interpreter for your web applications. For example:

Then you need to install a Ruby 1.9-compatible Ruby interpreter with POSIX spawn support, alongside JRuby/MRI 1.8. Ruby interpreters which can be used for running the Flying Passenger daemon include:

The following example demonstrates how you can install MRI Ruby 1.9 in parallel with your MRI Ruby 1.8 or JRuby installation.

Example for Debian/Ubuntu users:

Example for RVM users:

The Flying Passenger daemon will now be run on Ruby 1.9, while the web application www.foo.com will be run on JRuby.

Beware of the following caveats and limitations when using Flying Passenger:

Phusion Passenger’s core is written in C++ for performance and memory efficiency. It supports web applications written in any language. Phusion Passenger requires Ruby, its usage of Ruby is minimal in order to maximize performance and to minimize memory usage.

Other than the aforementioned aspects, Phusion Passenger does not use Ruby during normal operation. For example, if you run Python WSGI web applications on Phusion Passenger, then there will be (almost) no Ruby code running on the system.

Phusion Passenger may be installed with any Ruby interpreter. Once installed, you can run Phusion Passenger’s Ruby parts under any Ruby interpreter you want, even if that Ruby interpreter was not the one you originally installed Phusion Passenger with.

The reason for this is that Phusion Passenger does not dynamically link to Ruby: Phusion Passenger uses Ruby entirely out-of-process. Thus you can switch to any Ruby interpreter you want during runtime, without recompiling Phusion Passenger, and without worrying about what Ruby you used to install Phusion Passenger.

Phusion Passenger is also capable of running Ruby web applications under any Ruby interpreter you want. So it is not important which Ruby you use to install Phusion Passenger: it will work regardless. Please refer to the documentation for the passenger_ruby directive to learn how run different web applications under different Ruby interpreters.

There is however one caveat if you happen to be using RVM or RVM gemsets. When you gem install Phusion Passenger using RVM, then RVM will install Phusion Passenger into the currently active RVM Ruby and gemset. This means that Phusion Passenger commands - such as passenger, passenger-install-xxx-module and passenger-status - are available in that same RVM Ruby and gemset only. When you switch Ruby interpreter, or when you switch gemset, the Phusion Passenger commands will no longer be available, and you will get a command not found error. Here’s an example which demonstrates the problem.

There are several ways to solve this problem:

When the smart spawn method is being used, Phusion Passenger will first create a so-called preloader process. This process loads the entire Rails application along with the Rails framework, by evaluating config.ru. Then, whenever Phusion Passenger needs a new application process, it will instruct the preloader to create one. The preloader then then spawns a child process, which is an exact virtual copy of itself. This child process therefore already has the application code and the Rails framework code in memory.

Creating a process like this is very fast, about 10 times faster than loading the Rails application/framework from scratch. On top of that, the OS also applies an optimization called copy-on-write. This means that all memory that the child process hasn’t modified, is shared with the parent process.

Figure: Application processes and the smart spawn method. All processes, as well as the preloader, share the same application code and Rails framework code.

However, Ruby can only leverage this copy-on-write optimization if its garbage collector is friendly. This is only the case starting from Ruby 2.0.0. Earlier versions cannot leverage copy-on-write optimizations.

Note that preloader processes have an idle timeout just like application processes. If a preloader hasn’t been instructed to do anything for a while, it will be shutdown in order to conserve memory. This idle timeout is configurable.

Suppose that Phusion Passenger needs a process for an application that uses Rails 4.1.0.

If the smart spawning method is used, and a preloader for this application is already running, then process creation time is about 10 times faster than direct spawning. This process will also share application and Rails framework code memory with the preloader, as well as with other processes that have been spawned by the same preloader.

In practice, the smart spawning method could mean a memory saving of about 33%, assuming that your Ruby interpreter is copy-on-write friendly.

Of course, smart spawning is not without caveats. But if you understand the caveats you can easily reap the benefits of smart spawning.

Suppose we have a Rails application that connects to a Memcached server in environment.rb. This causes the preloader to have a socket connection (file descriptor) to the Memcached server, as shown in the following figure:

Phusion Passenger then proceeds with creating a new Rails application process, which is to process incoming HTTP requests. The result will look like this:

Since a fork() makes a (virtual) complete copy of a process, all its file descriptors will be copied as well. What we see here is that Preloader and App process 1 both share the same connection to Memcached.

Now supposed that your site gets a sudden large surge of traffic, and Phusion Passenger needs to spawn another process. It does so by forking Preloader. The result is now as follows:

As you can see, App process 1 and App process 2 have the same Memcached connection.

Suppose that users Joe and Jane visit your website at the same time. Joe’s request is handled by App process 1, and Jane’s request is handled by App process 2. Both application processes want to fetch something from Memcached. Suppose that in order to do that, both handlers need to send a "FETCH" command to Memcached.

But suppose that, after App process 1 having only sent "FE", a context switch occurs, and App process 2 starts sending a "FETCH" command to Memcached as well. If App process 2 succeeds in sending only one bye, F, then Memcached will receive a command which begins with "FEF", a command that it does not recognize. In other words: the data from both handlers get interleaved. And thus Memcached is forced to handle this as an error.

This problem can be solved by reestablishing the connection to Memcached after forking:

App process 2 now has its own, separate communication channel with Memcached. The code in environment.rb looks like this:

There are also cases in which unintentional file descriptor sharing is not harmful. One such case is log file file descriptor sharing. Even if two processes write to the log file at the same time, the worst thing that can happen is that the data in the log file is interleaved.

To guarantee that the data written to the log file is never interleaved, you must synchronize write access via an inter-process synchronization mechanism, such as file locks. Reopening the log file, like you would have done in the Memcached example, doesn’t help.

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.

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

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

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.

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 the Nginx init script described earlier in this manual, 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.

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.

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