= Phusion Passenger users guide, Nginx version = image:images/phusion_banner.png[link="http://www.phusion.nl/"] Phusion Passenger is an application server which can directly integrate into Nginx. It is designed to be easy to use, fast, stable and reliable and is used by link:http://trends.builtwith.com/Web-Server/Phusion-Passenger[hundreds of thousands of websites] all over the world. Phusion Passenger is a so-called polyglot application server because it supports applications written in multiple programming languages. At this time, Ruby and Python are supported. This users guide will teach you: - How to install Nginx with Phusion Passenger support. - How to configure Phusion Passenger. - How to deploy Ruby and Python applications. - How to solve common problems. This guide assumes that the reader is somewhat familiar with Nginx and with using the command line. == Support information include::users_guide_snippets/support_information.txt[] == Installation include::users_guide_snippets/installation.txt[] [[deploying_a_ror_app]] == Deploying a Ruby on Rails 1.x or 2.x (but NOT Rails >= 3) application == Suppose you have a Ruby on Rails application in '/webapps/mycook', and you own the domain 'www.mycook.com'. You can either deploy your application to the virtual host's root (i.e. the application will be accessible from the root URL, 'http://www.mycook.com/'), or in a sub URI (i.e. the application will be accessible from a sub URL, such as 'http://www.mycook.com/railsapplication'). NOTE: The default `RAILS_ENV` environment in which deployed Rails applications are run, is ``production''. You can change this by changing the <> configuration option. === Deploying to a virtual host's root === Add a 'server' virtual host entry to your Nginx configuration file. The virtual host's root must point to your Ruby on Rails application's 'public' folder. Inside the 'server' block, set 'passenger_enabled on'. For example: ------------------------------------------- http { ... server { listen 80; server_name www.mycook.com; root /webapps/mycook/public; passenger_enabled on; } ... } ------------------------------------------- Then restart Nginx. The application has now been deployed. [[deploying_rails_to_sub_uri]] === Deploying to a sub URI === Suppose that you already have a 'server' virtual host entry: ------------------------------------------- http { ... server { listen 80; server_name www.phusion.nl; root /websites/phusion; } ... } ------------------------------------------- And you want your Ruby on Rails application to be accessible from the URL 'http://www.phusion.nl/rails'. To do this, make a symlink in the virtual host's document root, and have it point to your Ruby on Rails application's 'public' folder. For example: ------------------------------------------- ln -s /webapps/mycook/public /websites/phusion/rails ------------------------------------------- Next, set 'passenger_enabled on' and add a <> option to the 'server' block: ------------------------------------------- http { ... server { listen 80; server_name www.phusion.nl; root /websites/phusion; passenger_enabled on; # <--- These lines have passenger_base_uri /rails; # <--- been added. } ... } ------------------------------------------- Then restart Nginx. The application has now been deployed. [TIP] ====================================== You can deploy multiple Rails applications under a virtual host, by specifying <> multiple times. For example: --------------------------------- server { ... passenger_base_uri /app1; passenger_base_uri /app2; passenger_base_uri /app3; } --------------------------------- ====================================== === Redeploying (restarting the Ruby on Rails application) === Deploying a new version of a Ruby on Rails application is as simple as re-uploading the application files, and restarting the application. There are two ways to restart the application: 1. By restarting Nginx. 2. By creating or modifying the file 'tmp/restart.txt' in the Rails application's <>. Phusion Passenger will automatically restart the application during the next request. For example, to restart our example MyCook application, we type this in the command line: ------------------------------------------- touch /webapps/mycook/tmp/restart.txt ------------------------------------------- Please note that, unlike earlier versions of Phusion Passenger, 'restart.txt' is not automatically deleted. Phusion Passenger checks whether the timestamp of this file has changed in order to determine whether the application should be restarted. === Migrations === Phusion Passenger is not related to Ruby on Rails migrations in any way. To run migrations on your deployment server, please login to your deployment server (e.g. with 'ssh') and type `rake db:migrate RAILS_ENV=production` in a shell console, just like one would normally run migrations. === Capistrano integration === See <>. [[deploying_a_rack_app]] == Deploying a Rack-based Ruby application (including Rails >= 3) == Phusion Passenger supports arbitrary Ruby web applications that follow the link:http://rack.rubyforge.org/[Rack] interface. Phusion Passenger assumes that Rack application directories have a certain layout. Suppose that you have a Rack application in '/webapps/rackapp'. Then that folder must contain at least three entries: - 'config.ru', a Rackup file for starting the Rack application. This file must contain the complete logic for initializing the application. - 'public/', a folder containing public static web assets, like images and stylesheets. - 'tmp/', used for 'restart.txt' (our application restart mechanism). This will be explained in a following subsection. So '/webapps/rackapp' must, at minimum, look like this: ---------------------- /webapps/rackapp | +-- config.ru | +-- public/ | +-- tmp/ ---------------------- Suppose you own the domain 'www.rackapp.com'. You can either deploy your application to the virtual host's root (i.e. the application will be accessible from the root URL, 'http://www.rackapp.com/'), or in a sub URI (i.e. the application will be accessible from a sub URL, such as 'http://www.rackapp.com/rackapp'). NOTE: The default `RACK_ENV` environment in which deployed Rack applications are run, is ``production''. You can change this by changing the <> configuration option. === Tutorial/example: writing and deploying a Hello World Rack application === First we create a Phusion Passenger-compliant Rack directory structure: ------------------------------------------- $ mkdir /webapps/rack_example $ mkdir /webapps/rack_example/public $ mkdir /webapps/rack_example/tmp ------------------------------------------- Next, we write a minimal "hello world" Rack application: ------------------------------------------- $ cd /webapps/rack_example $ some_awesome_editor config.ru ...type in some source code... $ cat config.ru app = proc do |env| [200, { "Content-Type" => "text/html" }, ["hello world"]] end run app ------------------------------------------- Finally, we deploy it by adding the following configuration options to the Nginx configuration file: ------------------------------------------- http { ... server { listen 80; server_name www.rackexample.com; root /webapps/rack_example/public; passenger_enabled on; } ... } ------------------------------------------- And we're done! After an Nginx restart, the above Rack application will be available under the URL 'http://www.rackexample.com/'. === Deploying to a virtual host's root === Add a 'server' virtual host entry to your Nginx configuration file. The virtual host's root must point to your Rack application's 'public' folder. You must also set 'passenger_enabled on' in the 'server' block. For example: ------------------------------------------- http { ... server { listen 80; server_name www.rackapp.com; root /webapps/rackapp/public; passenger_enabled on; } ... } ------------------------------------------- Then restart Nginx. The application has now been deployed. [[deploying_rack_to_sub_uri]] === Deploying to a sub URI === Suppose that you already have a virtual host: ------------------------------------------- http { ... server { listen 80; server_name www.phusion.nl; root /websites/phusion; passenger_enabled on; } ... } ------------------------------------------- And you want your Rack application to be accessible from the URL 'http://www.phusion.nl/rack'. To do this, make a symlink in the virtual host's document root, and have it point to your Rack application's 'public' folder. For example: ------------------------------------------- ln -s /webapps/rackapp/public /websites/phusion/rack ------------------------------------------- Next, set 'passenger_enabled on' and add a <> option to the 'server' block: ------------------------------------------- http { ... server { listen 80; server_name www.phusion.nl; root /websites/phusion; passenger_enabled on; # <--- These lines have passenger_base_uri /rack; # <--- been added. } ... } ------------------------------------------- Then restart Nginx. The application has now been deployed. [TIP] ====================================== You can deploy multiple Rack applications under a virtual host, by specifying <> multiple times. For example: --------------------------------- server { ... passenger_base_uri /app1; passenger_base_uri /app2; passenger_base_uri /app3; } --------------------------------- ====================================== === Redeploying (restarting the Rack application) === Deploying a new version of a Rack application is as simple as re-uploading the application files, and restarting the application. There are two ways to restart the application: 1. By restarting Nginx. 2. By creating or modifying the file 'tmp/restart.txt' in the Rack application's <>. Phusion Passenger will automatically restart the application. For example, to restart our example application, we type this in the command line: ------------------------------------------- touch /webapps/rackapp/tmp/restart.txt ------------------------------------------- === Rackup specifications for various web frameworks === include::users_guide_snippets/rackup_specifications.txt[] == Deploying a WSGI (Python) application Phusion Passenger supports all WSGI-compliant Python web applications. Suppose that you have a WSGI application in '/webapps/wsgiapp'. Then that folder must contain at least three entries: - 'passenger_wsgi.py', which Phusion Passenger will use as the main entry point for your application. This file must export a WSGI object called `application`. - 'public/', a folder containing public static web assets, like images and stylesheets. - 'tmp/', used for 'restart.txt' (our application restart mechanism). This will be explained in a following subsection. So '/webapps/wsgiapp' must, at minimum, look like this: ---------------------- /webapps/wsgiapp | +-- config.ru | +-- public/ | +-- tmp/ ---------------------- === Tutorial/example: writing and deploying a Hello World WSGI application === First we create a Phusion Passenger-compliant WSGI directory structure: ------------------------------------------- $ mkdir /webapps/wsgi_example $ mkdir /webapps/wsgi_example/public $ mkdir /webapps/wsgi_example/tmp ------------------------------------------- Next, we write a minimal "hello world" WSGI application: ------------------------------------------- $ cd /webapps/wsgi_example $ some_awesome_editor passenger_wsgi.py ...type in some source code... $ cat passenger_wsgi.py def application(environ, start_response): start_response('200 OK', [('Content-Type', 'text/plain')]) return [b"hello world!\n"] ------------------------------------------- Finally, we deploy it by adding the following configuration options to the Nginx configuration file: ------------------------------------------- http { ... server { listen 80; server_name www.wsgiexample.com; root /webapps/wsgi_example/public; passenger_enabled on; } ... } ------------------------------------------- And we're done! After an Nginx restart, the above WSGI application will be available under the URL 'http://www.wsgiexample.com/'. === Deploying to a virtual host's root === Add a 'server' virtual host entry to your Nginx configuration file. The virtual host's root must point to your WSGI application's 'public' folder. You must also set 'passenger_enabled on' in the 'server' block. For example: ------------------------------------------- http { ... server { listen 80; server_name www.wsgiapp.com; root /webapps/wsgiapp/public; passenger_enabled on; } ... } ------------------------------------------- Then restart Nginx. The application has now been deployed. === Redeploying (restarting the WSGI application) === Deploying a new version of a WSGI application is as simple as re-uploading the application files, and restarting the application. There are two ways to restart the application: 1. By restarting Nginx. 2. By creating or modifying the file 'tmp/restart.txt' in the WSGI application's <>. Phusion Passenger will automatically restart the application. For example, to restart our example application, we type this in the command line: ------------------------------------------- touch /webapps/wsgiapp/tmp/restart.txt ------------------------------------------- == Configuring Phusion Passenger == After installation, Phusion Passenger does not need any further configurations. Nevertheless, the system administrator may be interested in changing Phusion Passenger's behavior. Phusion Passenger supports the following configuration options in the Nginx configuration file: === passenger_root === The location to the Phusion Passenger root directory. This configuration option is essential to Phusion Passenger, and allows Phusion Passenger to locate its own data files. The correct value is given by the installer. If you've moved Phusion Passenger to a different directory then you need to update this option as well. Please read <> for more information. This required option may only occur once, in the 'http' configuration block. NOTE: This option has no effect when you are using <>. [[PassengerRuby]] === passenger_ruby === The `passenger_ruby` option allows one to specify the Ruby interpreter to use. Similarly, the `passenger_python` option is for specifying the Python interpreter. 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` option was not supported. Since version 4.0.0, the `passenger_python` option was added. Also, Phusion Passenger supports multiple Ruby or Python interpreters in the same Nginx instance. And so, since version 4.0.0, this option may occur in the following places: * In the 'http' configuration block. * In a 'server' configuration block. * In a 'location' configuration block. * In an 'if' configuration scope. 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 <>. It 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` option works in a similar manner, but applies to Python instead. You can also override `passenger_ruby` or `passenger_python` in specific contexts if you want to use a different Ruby/Python interpreter for that web app. For example: ------------------------------ http { passenger_root ...; # Use Ruby 1.8.7 by default. passenger_ruby /usr/bin/ruby1.8; # Use Python 2.6 by default. passenger_python /usr/bin/python2.6; server { # This Rails web app will use Ruby 1.8.7 listen 80; server_name www.foo.com; root /webapps/foo/public; } server { # This Rails web app will use Ruby 1.9.3, as installed by RVM passenger_ruby /usr/local/rvm/wrappers/ruby-1.9.3/ruby; listen 80; server_name www.bar.com; root /webapps/bar/public; # If you have a web app deployed in a sub-URI, customize # passenger_ruby/passenger_python inside a `location` block. # The web app under www.bar.com/blog will use JRuby 1.7.1 passenger_base_uri /blog; location /blog { passenger_ruby /usr/local/rvm/wrappers/jruby-1.7.1/ruby; } } server { # This Flask web app will use Python 3.0 passenger_python /usr/bin/python3.0; listen 80; server_name www.baz.com; root /webapps/baz/public; } } ------------------------------ include::users_guide_snippets/rvm_helper_tool.txt[] === passenger_python === :version: 4.0.0 include::users_guide_snippets/since_version.txt[] This option allows one to specify the Python interpreter to use. See <> for more information. The default value is 'python', meaning that the Python interpreter will be looked up according to the `PATH` environment variable. [[PassengerAppRoot]] === passenger_app_root === :version: 4.0.0 include::users_guide_snippets/since_version.txt[] 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 the 'http' configuration block. * In a 'server' configuration block. * In a 'location' configuration block. * In an 'if' configuration scope. In each place, it may be specified at most once. Example: ----------------------------- server { server_name test.host; root /var/rails/zena/sites/example.com/public; # normally Phusion Passenger would # have assumed that the application # root is "/var/rails/zena/sites/example.com" passenger_app_root /var/rails/zena; } ----------------------------- [[PassengerSpawnMethod]] === passenger_spawn_method === [TIP] ."What spawn method should I use?" ========================================================= This subsection attempts to describe spawn methods, but it's okay if you don't (want to) understand it, as it's mostly a technical detail. You can basically follow this rule of thumb: ************************************************ If your application works on Mongrel, but not on Phusion Passenger, then set `passenger_spawn_method` to 'direct'. Otherwise, leave it at 'smart' (the default). ************************************************ However, we do recommend you to try to understand it. The 'smart' spawn method brings many benefits. ========================================================= include::users_guide_snippets/passenger_spawn_method.txt[] This option may occur in the following places: * In the 'http' configuration block. * In a 'server' configuration block. * In a 'location' configuration block. * In an 'if' configuration scope. In each place, it may be specified at most once. The default value is 'smart'. [[PassengerRollingRestarts]] === passenger_rolling_restarts === :version: 3.0.0 include::users_guide_snippets/enterprise_only.txt[] Enables or disables support for rolling restarts. 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: 1. Spawn a new process in the background. 2. When it's done spawning, Phusion Passenger Enterprise will replace one of the old processes with this newly spawned one. 3. Step 1 and 2 are repeated until all processes have been replaced. 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: - Upgrading an application sometimes involves upgrading the database schema. With rolling restarts, there may be a point in time during which processes belonging to the previous version and processes belonging to the new version both exist at the same time. Any database schema upgrades you perform must therefore be backwards-compatible with the old application version. - Because there's no telling which process will serve a request, users may not see changes brought about by the new version until all processes have been restarted. It is for this reason that you should not use rolling restarts in development, only in production. This option may occur in the following places: * In the 'http' configuration block. * In a 'server' configuration block. * In a 'location' configuration block. * In an 'if' configuration scope. In each place, it may be specified at most once. The default value is 'off'. === passenger_resist_deployment_errors === :version: 3.0.0 include::users_guide_snippets/enterprise_only.txt[] Enables or disables resistance against deployment errors. Suppose you've upgraded your application and you've issues a command to restart it (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: - It passes the request to one of the existing application processes (that belong to the previous version of the application). The visitor will not see a Phusion Passenger process spawning error message. - It logs the error to the global web server error log file. - It sets an internal flag so that no processes for this application will be spawned (even when the current traffic would normally result in more processes being spawned) and no processes will be idle cleaned. Processes *could* still be shutdown because of other events, e.g. because their <> have been reached. This way, visitors will suffer minimally from deployment errors. Phusion Passenger will attempt to restart the application again next time restart.txt is touched. Enabling deployment error resistance only works if <> is also enabled. This option may occur in the following places: * In the 'http' configuration block. * In a 'server' configuration block. * In a 'location' configuration block. * In an 'if' configuration scope. In each place, it may be specified at most once. The default value is 'off'. [[PassengerTempDir]] === passenger_temp_dir === Specifies the directory that Phusion Passenger should use for storing temporary files. This includes things such as Unix socket files. This option may only be specified in the 'http' configuration block. The default temp directory that Phusion Passenger uses is '/tmp'. This option is especially useful if Nginx is not allowed to write to /tmp (which is the case on some systems with strict SELinux policies) or if the partition that /tmp lives on doesn't have enough disk space. .Command line tools Some Phusion Passenger command line administration tools, such as `passenger-status`, must know what Phusion Passenger's temp directory is in order to function properly. You can pass the directory through the `PASSENGER_TMPDIR` environment variable, or the `TMPDIR` environment variable (the former will be used if both are specified). For example, if you set 'passenger_temp_dir' to '/my_temp_dir', then invoke `passenger-status` after you've set the `PASSENGER_TMPDIR` or `TMPDIR` environment variable, like this: ---------------------------------------------------------- export PASSENGER_TMPDIR=/my_temp-dir sudo -E passenger-status # The -E option tells 'sudo' to preserve environment variables. ---------------------------------------------------------- :option: `--temp-dir` include::users_guide_snippets/alternative_for_flying_passenger.txt[] === passenger_fly_with :version: 4.1.0 include::users_guide_snippets/enterprise_only.txt[] Enables <> 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. === Important deployment options === ==== passenger_enabled ==== 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 <> and <> for examples. [[PassengerBaseURI]] ==== passenger_base_uri ==== Used to specify that the given URI is an distinct application that should be served by Phusion Passenger. This option can be used for both Rails and Rack applications. See <> for an example. 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: * In the 'http' configuration block. * In a 'server' configuration block. * In a 'location' configuration block. * In an 'if' configuration scope. === Connection handling options === ==== passenger_ignore_client_abort ==== 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 the 'http' configuration block. * In a 'server' configuration block. * In a 'location' configuration block. * In an 'if' configuration scope. In each place, it may be specified at most once. The default value is 'off'. ==== passenger_set_cgi_param ==== Allows one to define additional CGI environment variables to pass to the backend application. This is equivalent to ngx_http_fastcgi_module's 'fastcgi_param' directive, and is comparable to ngx_http_proxy_module's 'proxy_set_header' option. Nginx variables in the value are interpolated. For example: ------------------------------ # Application will see a CGI environment "APP_NAME" with value "my super blog". passenger_set_cgi_param APP_NAME "my super blog"; # Nginx variables are interpolated. passenger_set_cgi_param EXTRA_REQUEST_METHOD method=$request_method; ------------------------------ If you want to set an HTTP header, then you must set it in the CGI environment name format, i.e. 'HTTP_*': ------------------------------ # !!!THIS IS WRONG!!! Don't do this! passenger_set_cgi_param X-Forwarded-For 127.0.0.2; # Instead, write it like this: passenger_set_cgi_param HTTP_X_FORWARDED_FOR 127.0.0.2; ------------------------------ This option may occur in the following places: * In the 'http' configuration block. * In a 'server' configuration block. * In a 'location' configuration block. * In an 'if' configuration scope. ==== passenger_pass_header
==== 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: ------------------------------ location / { passenger_pass_header X-Accel-Redirect; } ------------------------------ This option may occur in the following places: * In the 'http' configuration block. * In a 'server' configuration block. * In a 'location' configuration block. * In an 'if' configuration scope. ==== passenger_buffer_response ==== 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: 1. The Nginx response buffering system. `passenger_buffer_response` turns this on or off. 2. The Phusion Passenger response buffering system, a.k.a. 'real-time disk-backed response buffering'. This buffering system is always on, regardless of the value of `passenger_buffer_response`. 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 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: -------------------------------- render :text => lambda { |response, output| 10.times do |i| output.write("entry #{i}\n") output.flush sleep 1 end } -------------------------------- ...or this piece of Rack code: -------------------------------- class Response def each 10.times do |i| yield("entry #{i}\n") sleep 1 end end end app = lambda do |env| [200, { "Content-Type" => "text/plain" }, Response.new] end -------------------------------- 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 the 'http' configuration block. * In a 'server' configuration block. * In a 'location' configuration block. * In an 'if' configuration scope. In each place, it may be specified at most once. The default value is 'off'. ==== passenger_buffer_size ==== ==== passenger_buffers ==== ==== passenger_busy_buffer_size ==== 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. === Security options === [[PassengerUserSwitching]] ==== passenger_user_switching ==== Whether to enable <>. This option may only occur once, in the 'http' configuration block. The default value is 'on'. NOTE: This option has no effect when you are using <>. You can disable user switching for Flying Passenger by starting the Flying Passenger daemon as a non-root user. [[PassengerUser]] ==== passenger_user ==== If <> 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 the 'http' configuration block. * In a 'server' configuration block. * In a 'location' configuration block. * In an 'if' configuration scope. In each place, it may be specified at most once. [[PassengerGroup]] ==== passenger_group ==== If <> 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'. '' 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 the 'http' configuration block. * In a 'server' configuration block. * In a 'location' configuration block. * In an 'if' configuration scope. In each place, it may be specified at most once. [[PassengerDefaultUser]] ==== passenger_default_user ==== Phusion Passenger enables <> 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'. NOTE: This option has no effect when you are using <>. There is currently no way to set this option when using Flying Passenger, but if you want to disable user switching for Flying Passenger then you can do so by starting the Flying Passenger daemon as a non-root user. [[PassengerDefaultGroup]] ==== Passenger_default_group ==== Phusion Passenger enables <> 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 <>. NOTE: This option has no effect when you are using <>. There is currently no way to set this option when using Flying Passenger, but if you want to disable user switching for Flying Passenger then you can do so by starting the Flying Passenger daemon as a non-root user. ==== passenger_show_version_in_header ==== When turned on, Phusion Passenger will output its version number in the `Server` and `X-Powered-By` header in all Phusion Passenger-served requests: ---------------------------------------------------- Server: nginx/1.3.11 + Phusion Passenger 4.0.0 X-Powered-By: Phusion Passenger 4.0.0 ---------------------------------------------------- When turned off, the version number will be hidden: ---------------------------------------------------- Server: nginx/1.3.11 + Phusion Passenger X-Powered-By: Phusion Passenger ---------------------------------------------------- This option may occur in the following places: * In the 'http' configuration block. * In a 'server' configuration block. * In a 'location' configuration block. * In an 'if' configuration scope. In each place, it may be specified at most once. The default value is 'on'. [[PassengerFriendlyErrorPages]] ==== passenger_friendly_error_pages ==== 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, and a backtrace. 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. Experienced system administrators who are using Phusion Passenger on serious production servers should consider turning this feature off. This option may occur in the following places: * In the 'http' configuration block. * In a 'server' configuration block. * In a 'location' configuration block. * In an 'if' configuration scope. In each place, it may be specified at most once. The default value is 'on'. === Resource control and optimization options === [[PassengerMaxPoolSize]] ==== passenger_max_pool_size ==== The maximum number of <> 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 link:http://blog.phusion.nl/2013/03/12/tuning-phusion-passengers-concurrency-settings/[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'. :option: `--max-pool-size` include::users_guide_snippets/alternative_for_flying_passenger.txt[] [[PassengerMinInstances]] ==== passenger_min_instances ==== 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 <> 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: 1. at least the given number of processes will be spawned. 2. the given number of processes will be kept around even when processes are being idle cleaned (see <>). If you want to pre-start application processes during Nginx startup, then you should use the <> directive, possibly in combination with 'passenger_min_instances'. This behavior might seem counter-intuitive at first sight, but <> explains the rationale behind it. For example, suppose that you have the following configuration: --------------------------------- http { ... passenger_max_pool_size 15; passenger_pool_idle_time 10; server { listen 80; server_name foobar.com; root /webapps/foobar/public; passenger_min_instances 3; } } --------------------------------- 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 the 'http' configuration block. * In a 'server' configuration block. * In a 'location' configuration block. * In an 'if' configuration scope. In each place, it may be specified at most once. The default value is '1'. ==== passenger_max_instances ==== :version: 3.0.0 include::users_guide_snippets/enterprise_only.txt[] 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 <>. 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 <> will be enforced. This option may occur in the following places: * In the 'http' configuration block. * In a 'server' configuration block. * In a 'location' configuration block. * In an 'if' configuration scope. In each place, it may be specified at most once. The default value is '0'. .Practical usage example [TIP] =========================================================================== Suppose that you're hosting two web applications on your server, a personal blog and an e-commerce website. You've set <> to 10. The e-commerce website is more important to you. You can then set 'passenger_max_instances' to 3 for your blog, so that it will never spawn more than 3 processes, even if it suddenly gets a lot of traffic. Your e-commerce website on the other hand will be free to spawn up to 10 processes if it gets a lot of traffic. =========================================================================== ==== passenger_max_instances_per_app ==== 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 <>. 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 <> will be enforced. This option may only occur once, in the 'http' configuration block. The default value is '0'. [[PassengerPoolIdleTime]] ==== passenger_pool_idle_time ==== 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 <> 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'. :option: `--pool-idle-time` include::users_guide_snippets/alternative_for_flying_passenger.txt[] ==== passenger_max_preloader_idle_time ==== The ApplicationSpawner server (explained in <>) 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 ApplicationSpawner server's idle timeout, in seconds. A value of '0' means that it should never idle timeout. Setting a higher value will mean that the ApplicationSpawner server is kept around longer, which may slightly increase memory usage. But as long as the ApplicationSpawner server 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' or 'smart-lv2' <>. 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 the 'http' configuration block. * In a 'server' configuration block. * In a 'location' configuration block. * In an 'if' configuration scope. In each place, it may be specified at most once. The default value is '300' (5 minutes). :option: `--max-preloader-idle-time` include::users_guide_snippets/alternative_for_flying_passenger.txt[] [[PassengerConcurrencyModel]] ==== passenger_concurrency_model ==== :version: 4.0.0 include::users_guide_snippets/enterprise_only.txt[] Specifies the I/O concurrency model that should be used for application processes. Phusion Passenger supports two concurrency models: * 'process' - single-threaded, multi-processed I/O concurrency. Each application process only has a single thread and can only handle 1 request at a time. This is the concurrency model that Ruby applications traditionally used. It has excellent compatiblity (can work with applications that are not designed to be thread-safe) but is unsuitable workloads in which the application has to wait for a lot of external I/O (e.g. HTTP API calls), and uses more memory because each process has a large memory overhead. * 'thread' - multi-threaded, multi-processed I/O concurrency. Each application process has multiple threads (customizable via <>). This model provides much better I/O concurrency and uses less memory because threads share memory with each other within the same process. However, using this model may cause compatibility problems if the application is not designed to be thread-safe. This option may occur in the following places: * In the 'http' configuration block. * In a 'server' configuration block. * In a 'location' configuration block. * In an 'if' configuration scope. In each place, it may be specified at most once. The default value is 'process'. [[PassengerThreadCount]] ==== passenger_thread_count ==== :version: 4.0.0 include::users_guide_snippets/enterprise_only.txt[] Specifies the number of threads that Phusion Passenger should spawn per application process. This option only has effect if <> is 'thread'. This option may occur in the following places: * In the 'http' configuration block. * In a 'server' configuration block. * In a 'location' configuration block. * In an 'if' configuration scope. In each place, it may be specified at most once. The default value is '1'. [[PassengerMaxRequests]] ==== passenger_max_requests ==== 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 the 'http' configuration block. * In a 'server' configuration block. * In a 'location' configuration block. * In an 'if' configuration scope. In each place, it may be specified at most once. The default value is '0'. [CAUTION] ===================================================== The <> directive should be considered as a workaround for misbehaving applications. It is advised that you fix the problem in your application rather than relying on these directives as a measure to avoid memory leaks. ===================================================== [[PassengerMaxRequestTime]] ==== passenger_max_request_time ==== :version: 3.0.0 include::users_guide_snippets/enterprise_only.txt[] 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 the 'http' configuration block. * In a 'server' configuration block. * In a 'location' configuration block. * In an 'if' configuration scope. In each place, it may be specified at most once. The default value is '0'. .Example 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: ---------------------------------------------- server { listen 80; server_name www.example.com; root /webapps/my_app/public; passenger_enabled on; passenger_max_request_time 2; location /expensive_compuation { passenger_enabled on; passenger_max_request_time 10; } } ---------------------------------------------- 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. [CAUTION] ===================================================== The <> directive should be considered as a workaround for misbehaving applications. It is advised that you fix the problem in your application rather than relying on these directives as a measure to avoid freezing applications. ===================================================== [NOTE] ===================================================== This option is currently only available for Ruby apps. It is not yet available for Python and Node.js. ===================================================== [[PassengerMemoryLimit]] ==== passenger_memory_limit ==== :version: 3.0.0 include::users_guide_snippets/enterprise_only.txt[] 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 the 'http' configuration block. * In a 'server' configuration block. * In a 'location' configuration block. * In an 'if' configuration scope. In each place, it may be specified at most once. The default value is '0'. [NOTE] .A word about permissions ===================================================== The <> directive uses the `ps` command to query memory usage information. On Linux, it further queries `/proc` to obtain additional memory usage information that's not obtainable through `ps`. You should ensure that the `ps` works correctly and that the `/proc` filesystem is accessible by the `PassengerHelperAgent` process. ===================================================== [CAUTION] ===================================================== The <> and <> directives should be considered as workarounds for misbehaving applications. It is advised that you fix the problem in your application rather than relying on these directives as a measure to avoid memory leaks. ===================================================== [[PassengerPreStart]] ==== passenger_pre_start ==== 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 directive accepts the *URL* of the web application you want to pre-start, not a on/off value! This might seem a bit weird, but read on for rationale. As for the specifics of the URL: * The domain part of the URL must be equal to the value of the 'server_name' directive of the server block that defines the web application. * Unless the web application is deployed on port 80, the URL should contain the web application's port number too. * The path part of the URL must point to some URI that the web application handles. - You will probably want to combine this option with <> because application processes started with 'passenger_pre_start' are subject to the usual idle timeout rules. See the example below for an explanation. This option may only occur in the 'http' configuration block. It may be specified any number of times. NOTE: This option is currently not available when using <>. ===== Example 1: basic usage ===== Suppose that you have the following web applications. --------------------------- server { listen 80; server_name foo.com; root /webapps/foo/public; passenger_enabled on; } server { listen 3500; server_name bar.com; root /webapps/bar/public; passenger_enabled on; } --------------------------- You want both of them to be pre-started during Nginx startup. The URL for foo.com is 'http://foo.com/' (or, equivalently, 'http://foo.com:80/') and the URL for bar.com is 'http://bar.com:3500/'. So we add two passenger_pre_start directives, like this: --------------------------- server { listen 80; server_name foo.com; root /webapps/foo/public; passenger_enabled on; } server { listen 3500; server_name bar.com; root /webapps/bar/public; passenger_enabled on; } passenger_pre_start http://foo.com/; # <--- added passenger_pre_start http://bar.com:3500/; # <--- added --------------------------- ===== Example 2: pre-starting apps that are deployed in sub-URIs ===== Suppose that you have a web application deployed in a sub-URI '/store', like this: --------------------------- server { listen 80; server_name myblog.com; root /webapps/wordpress; passenger_base_uri /store; } --------------------------- Then specify the 'server_name' value followed by the sub-URI, like this: --------------------------- server { listen 80; server_name myblog.com; root /webapps/wordpress; passenger_base_uri /store; } passenger_pre_start http://myblog.com/store; # <----- added --------------------------- The sub-URI *must* be included; if you don't then the directive will have no effect. The following example is wrong and won't pre-start the store web application: --------------------------- passenger_pre_start http://myblog.com/; # <----- WRONG! Missing "/store" part. --------------------------- ===== Example 3: combining with passenger_min_instances ===== Application processes started with passenger_pre_start are also subject to the idle timeout rules as specified by <>! That means that by default, the pre-started application processes for foo.com are bar.com are shut down after a few minutes of inactivity. If you don't want that to happen, then you should combine passenger_pre_start with <>, like this: --------------------------- server { listen 80; server_name foo.com; root /webapps/foo/public; passenger_enabled on; passenger_min_instances 1; # <--- added } server { listen 3500; server_name bar.com; root /webapps/bar/public; passenger_enabled on; passenger_min_instances 1; # <--- added } passenger_pre_start http://foo.com/; passenger_pre_start http://bar.com:3500/; --------------------------- ===== So why a URL? Why not just an on/off flag? ===== A directive that accepts a simple on/off flag is definitely more intuitive, but due technical difficulties w.r.t. the way Nginx works, it's very hard to implement it like that: It is very hard to obtain a full list of web applications defined in the Nginx configuration file(s). In other words, it's hard for Phusion Passenger to know which web applications are deployed on Nginx until a web application is first accessed, and without such a list Phusion Passenger wouldn't know which web applications to pre-start. So as a compromise, we made it accept a URL. ===== What does Phusion Passenger do with the URL? ===== During Nginx startup, Phusion Passenger will send a dummy HEAD request to the given URL and discard the result. In other words, Phusion Passenger simulates a web access at the given URL. However this simulated request is always sent to localhost, *not* to the IP that the domain resolves to. Suppose that bar.com in example 1 resolves to 209.85.227.99; Phusion Passenger will send the following HTTP request to 127.0.0.1 port 3500 (and not to 209.85.227.99 port 3500): ---------------------- HEAD / HTTP/1.1 Host: bar.com Connection: close ---------------------- Similarly, for example 2, Phusion Passenger will send the following HTTP request to 127.0.0.1 port 80: ---------------------- HEAD /store HTTP/1.1 Host: myblog.com Connection: close ---------------------- ===== Do I need to edit /etc/hosts and point the domain in the URL to 127.0.0.1? ===== No. See previous subsection. ===== My web application consists of multiple web servers. What URL do I need to specify, and in which web server's Nginx config file? ===== Put the web application's 'server_name' value and the server block's port in the URL, and put passenger_pre_start on all machines that you want to pre-start the web application on. The simulated web request is always sent to 127.0.0.1, with the domain name in the URL as value for the 'Host' HTTP header, so you don't need to worry about the request ending up at a different web server in the cluster. ===== Does passenger_pre_start support https:// URLs? ===== Yes. And it does not perform any certificate validation. === Logging and debugging options === [[PassengerLogLevel]] ==== passenger_log_level ==== 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: - '0': Show only errors and warnings. - '1': Show the most important debugging information. This might be useful for system administrators who are trying to figure out the cause of a problem. - '2': Show more debugging information. This is typically only useful for developers. - '3': Show even more debugging information. This option may only occur once, in the 'http' configuration block. The default is '0'. ==== passenger_debug_log_file ==== 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. :option: `--log-file` include::users_guide_snippets/alternative_for_flying_passenger.txt[] ==== passenger_debugger ==== :version: 3.0.0 include::users_guide_snippets/enterprise_only.txt[] 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) or the `debugger` gem (when on Ruby 1.9). If you're using Bundler, you should add this to your Gemfile: ------------------------------------------- gem 'ruby-debug', :platforms => :ruby_18 gem 'debugger', :platforms => :ruby_19 ------------------------------------------- Once debugging is turned on, you can use the command `passenger-irb --debug ` 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 the 'http' configuration block. * In a 'server' configuration block. * In a 'location' configuration block. * In an 'if' configuration scope. In each place, it may be specified at most once. The default value is 'off'. === Ruby on Rails-specific options === [[RailsEnv]] ==== rails_env ==== This option allows one to specify the default `RAILS_ENV` value. This option may occur in the following places: * In the 'http' configuration block. * In a 'server' configuration block. * In a 'location' configuration block. * In an 'if' configuration scope. In each place, it may be specified at most once. The default value is 'production'. === Rack and Rails >= 3 specific options === [[RackEnv]] ==== rack_env ==== This option allows one to specify the default `RACK_ENV` value. This option may occur in the following places: * In the 'http' configuration block. * In a 'server' configuration block. * In a 'location' configuration block. * In an 'if' configuration scope. In each place, it may be specified at most once. The default value is 'production'. === Deprecated options === The following options have been deprecated, but are still supported for backwards compatibility reasons. ==== rails_spawn_method ==== Deprecated in favor of <>. == Analysis and system maintenance == include::users_guide_snippets/analysis_and_system_maintenance.txt[] == Tips == include::users_guide_snippets/tips.txt[] == Under the hood == Phusion Passenger hides a lot of complexity for the end user (i.e. the web server system administrator), but sometimes it is desirable to know what is going on. This section describes a few things that Phusion Passenger does under the hood. === Page caching support === include::users_guide_snippets/under_the_hood/page_caching_support.txt[] [[application_detection]] === How Phusion Passenger detects whether a virtual host is a web application === After you've read the deployment instructions you might wonder how Phusion Passenger knows that the server root points to a web application that Phusion Passenger is able to serve, and how it knows what kind of web application it is (e.g. Rails or Rack). Phusion Passenger checks whether the virtual host is a Rails application by checking whether the following file exists: ------------------------------------------------ dirname(DocumentRoot) + "/config/environment.rb" ------------------------------------------------ If you're not a programmer and don't understand the above pseudo-code snippet, it means that Phusion Passenger will: 1. Extract the parent directory filename from the value of the ``root'' directive. 2. Append the text "/config/environment.rb" to the result, and check whether the resulting filename exists. So suppose that your server root is '/webapps/foo/public'. Phusion Passenger will check whether the file '/webapps/foo/config/environment.rb' exists. Note that Phusion Passenger for Nginx does *not* resolve any symlinks in the root path. So for example, suppose that your root points to '/home/www/example.com', which in turn is a symlink to '/webapps/example.com/public'. Phusion Passenger for Nginx will check for '/home/www/config/environment.rb', *not* '/webapps/example.com/config/environment.rb'. This file of course doesn't exist, and as a result Phusion Passenger will not activate itself for this virtual host, and you'll most likely see some output generated by the Nginx default directory handler such as a Forbidden error message. Detection of Rack applications happens through the same mechanism, exception that Phusion Passenger will look for 'config.ru' instead of 'config/environment.rb'. include::users_guide_snippets/appendix_a_about.txt[] include::users_guide_snippets/appendix_b_terminology.txt[] include::users_guide_snippets/appendix_c_spawning_methods.txt[] include::users_guide_snippets/environment_variables.txt[]