= Phusion Passenger users guide, Nginx version =

image:images/phusion_banner.png[link="http://www.phusion.nl/"]

Phusion Passenger is an Nginx module, which makes deploying Ruby and Ruby on
Rails applications on Nginx a breeze. It follows the usual Ruby on Rails
conventions, such as "Don't-Repeat-Yourself" and ease of setup, while at the
same time providing enough flexibility.

This users guide will teach you:

- How to install Nginx with Phusion Passenger support.
- How to configure Phusion Passenger.
- How to deploy a Ruby on Rails application.
- How to deploy a link:http://rack.rubyforge.org/[Rack]-based Ruby application.
- How to solve common problems.

This guide assumes that the reader is somewhat familiar with Nginx and with
using the commandline.


== Supported operating systems ==

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

Phusion Passenger for Nginx has been tested on:

- Ubuntu Linux 8.04 (x86)
- Gentoo Linux (AMD64)
- MacOS X Leopard (x86)

Other operating systems have not been tested, but Phusion Passenger will probably
work fine on them. Please
link:http://code.google.com/p/phusion-passenger/issues/list[report a bug]
or
link:http://groups.google.com/group/phusion-passenger[join our discussion list]
if it doesn't.


[[install_passenger]]
== Installing Phusion Passenger ==

=== Overview ===

As you might already know, Nginx does not support loadable modules, in contrast
to most other web servers (e.g. Apache). Therefore, to install Phusion Passenger
for Nginx, one must recompile and reinstall Nginx with Phusion Passenger support.
There are two ways to do this:

1. By running the Phusion Passenger installer for Nginx. This installer will
   guide you through the entire installation process, including downloading,
   compiling and installing Nginx. You should be able to get Nginx with Phusion
   Passenger support up-and-running in a matter of minutes. This is the
   recommended installation method.
2. By manually configuring and compiling Nginx with Phusion Passenger support,
   through Nginx's `--add-module` configure option. Generally, using our
   installer is easier, so you should only use this method if you're already
   familiar with compiling Nginx.

TIP: You might have to run the installation commands in the following sections
as 'root'. If the installer fails because of permission errors, it will tell
you.

[[specifying_ruby_installation]]
=== Specifying the correct Ruby installation ===

If your system has multiple Ruby installations -- which is likely the case on
MacOS X, or if you've also installed
link:http://www.rubyenterpriseedition.com[Ruby Enterprise Edition] -- then you
will need to tell the operating system which Ruby installation to use, prior to
running the Phusion Passenger installer. If you only have one Ruby installation
(the case on most Linux systems), then you can skip this section because Phusion
Passenger will automatically detect it.

To specify a Ruby installation, prepend your Ruby installation's `bin`
directory to the `PATH` environment variable. For example, if you have the
following Ruby installations:

- /usr/bin/ruby
- /opt/myruby/bin/ruby

and you want to use the latter, then type:

----------------------------------
export PATH=/opt/myruby/bin:$PATH
----------------------------------

=== Installing Phusion Passenger for Nginx through the installer ===

==== Obtaining the Phusion Passenger files and running the installer ====

You must obtain the Phusion Passenger files in order to run the installer.
This can be done either by installing the Phusion Passenger gem, or by
downloading the source tarball.

===== Gem =====

First, install the Phusion Passenger gem by running:

---------------------------------
gem install passenger
---------------------------------

Next, run the Phusion Passenger installer for Nginx:

---------------------------------
passenger-install-nginx-module
---------------------------------

Please follow the instructions given by the installer.

===== Source tarball =====

The source tarball can be download from the
link:http://www.modrails.com/[Phusion Passenger website]. Extract the tarball to
whatever location you prefer. *The Phusion Passenger files are to reside in that
location permanently.* For example, if you would like Phusion Passenger to
reside in `/opt/passenger-x.x.x`, then type:

--------------------------------------------------------------
cd /opt
tar xzvf ~/YourDownloadsFolder/passenger-x.x.x.tar.gz
--------------------------------------------------------------

Next, run the Phusion Passenger installer for Nginx:

--------------------------------------------------------------
/opt/passenger-x.x.x/bin/passenger-install-nginx-module
--------------------------------------------------------------

Please follow the instructions given by the installer.

IMPORTANT: Please do not remove the passenger-x.x.x folder after installation.
Furthermore, the passenger-x.x.x folder must be accessible by Nginx.

==== Non-interactive/automatic installation ====

By default, the installer is interactive. If you want to automate installation,
then you can do so by passing various answers to the installer through command
line options.

Please run the installer with `--help` for a list of available command line
options.

=== Installing Phusion Passenger for Nginx manually ===

You can also install Phusion Passenger the way you install any other Nginx module.
To do this, run Nginx's configure script with `--add-module=/path-to-passenger-root/ext/nginx`.

If you installed Phusion Passenger via the gem, then 'path-to-passenger-root'
can be obtained with the command:

--------------------------
passenger-config --root
--------------------------

This will probably output something along the lines of '/usr/lib/ruby/gems/1.8/gems/passenger-x.x.x',
so you'll probably have to specify something like `--add-module=/usr/lib/ruby/gems/1.8/gems/passenger-x.x.x/ext/nginx`.

If you installed Phusion Passenger via a source tarball, then 'path-to-passenger-root'
is the directory which contains the Phusion Passenger source code. So if you
extracted the Phusion Passenger source code to '/opt/passenger-x.x.x', then you'll
have to specify `--add-module=/opt/passenger-x.x.x/ext/nginx`.


[[deploying_a_ror_app]]
== Deploying a Ruby on Rails 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
<<RailsEnv,rails_env>> 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 from your Ruby on Rails application's 'public'
folder to a directory in the document root. For example:
-------------------------------------------
ln -s /webapps/mycook/public /websites/phusion/rails
-------------------------------------------

Next, set 'passenger_enabled on' and add a <<PassengerBaseURI,passenger_base_uri>>
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
<<PassengerBaseURI,passenger_base_uri>> 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 <<application_root,root folder>>. 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 <<capistrano,Capistrano recipe>>.


[[deploying_a_rack_app]]
== Deploying a Rack-based Ruby application ==

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
<<RackEnv,rack_env>> 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 <b>world</b>"]]
end
run app
-------------------------------------------

Finally, we deploy it by adding the following configuration options to
the Apache 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 from your Rack application's 'public'
folder to a directory in the document root. For example:
-------------------------------------------
ln -s /webapps/rackapp/public /websites/phusion/rack
-------------------------------------------

Next, set 'passenger_enabled on' and add a <<PassengerBaseURI,passenger_base_uri>>
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 Apache. The application has now been deployed.

[TIP]
======================================
You can deploy multiple Rack applications under a virtual host, by specifying
<<PassengerBaseURI,passenger_base_uri>> 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 <<application_root,root folder>>. 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[]


== 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 <directory> ===
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
<<moving_phusion_passenger,Moving Phusion Passenger to a different directory>> for more information.

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

=== passenger_log_level <integer> ===
This option allows one to specify how much information Phusion Passenger should
write to the Apache 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_ruby <filename> ===
This option allows one to specify the Ruby interpreter to use.

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

[[PassengerUseGlobalQueue]]
=== passenger_use_global_queue <on|off> ===
Turns the use of global queuing on or off.

This option may occur in the following places:

 * 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'.

'This feature is sponsored by http://www.37signals.com/[37signals].'

include::users_guide_snippets/global_queueing_explained.txt[]

[[PassengerUserSwitching]]
=== passenger_user_switching <on|off> ===
Whether to enable <<user_switching,user switching support>>.

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

[[PassengerDefaultUser]]
=== passenger_default_user <username> ===
Phusion Passenger enables <<user_switching,user switching support>> by default.
This configuration option allows one to specify which user Rails/Rack
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'.

=== Important deployment options
==== passenger_enabled <on|off> ====
This option may be specified in 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_ror_app,Deploying a Ruby on Rails application>>
and <<deploying_a_rack_app,Deploying a Rack-based Ruby application>>
for examples.

[[PassengerBaseURI]]
==== passenger_base_uri <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 <<deploying_rails_to_sub_uri,Deploying Rails to a sub URI>>
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 a 'server' configuration block.
 * In a 'location' configuration block.
 * In an 'if' configuration scope.

=== Resource control and optimization options ===
[[PassengerMaxPoolSize]]
==== passenger_max_pool_size <integer> ====
The maximum number of Ruby on Rails or Rack application instances that may
be simultaneously active. A larger number results in higher memory usage,
but improved ability to handle concurrent HTTP clients.

The optimal value depends on your system's hardware and the server's average
load. You should experiment with different values. But generally speaking,
the value should be at least equal to the number of CPUs (or CPU cores) that
you have. If your system has 2 GB of RAM, then we recommend a value of '30'.
If your system is a Virtual Private Server (VPS) and has about 256 MB RAM, and
is also running other services such as MySQL, then we recommend a value of '2'.

If you find that your server is unable to handle the load on your Rails/Rack websites
(i.e. running out of memory) then you should lower this value. (Though if your
sites are really that popular, then you should strongly consider upgrading your
hardware or getting more servers.)

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

TIP: We strongly recommend you to <<reducing_memory_usage,use Ruby Enterprise
Edition>>. This allows you to reduce the memory usage of your Ruby on Rails applications
by about 33%. And it's not hard to install.

==== passenger_max_instances_per_app <integer> ====
The maximum number of application instances that may be simultaneously active
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 <<PassengerMaxPoolSize,passenger_max_pool_size>>. A value of 0
means that there is no limit placed on the number of instances a single application
may use, i.e. only the global limit of <<PassengerMaxPoolSize,passenger_max_pool_size>>
will be enforced.

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

[[PassengerPoolIdleTime]]
==== passenger_pool_idle_time <integer> ====
The maximum number of seconds that an application instance may be idle. That is,
if an application instance 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 instances 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 instances needs to
make place for another application instance. 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'.

=== Ruby on Rails-specific options ===
[[RailsEnv]]
==== rails_env <string> ====
This option allows one to specify the default `RAILS_ENV` value.

This option may occur in the following places:

 * 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'.

==== rails_spawn_method <string> ====
[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
`rails_spawn_method` to 'conservative'. Otherwise, leave it at 'smart-lv2' (the default).
************************************************

However, we do recommend you to try to understand it. The 'smart' and 'smart-lv2' spawn
methods bring many benefits.
=========================================================

include::users_guide_snippets/rails_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-lv2'.

==== rails_framework_spawner_idle_time <integer> ====
The FrameworkSpawner server (explained in <<spawning_methods_explained,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 FrameworkSpawner 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 FrameworkSpawner server is kept around
longer, which may slightly increase memory usage. But as long as the
FrameworkSpawner server is running, the time to spawn a Ruby on Rails backend
process only takes about 40% of the time that is normally needed, assuming that
you're using the 'smart' <<RailsSpawnMethod,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 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 '1800' (30 minutes).

==== rails_app_spawner_idle_time <integer> ====
The ApplicationSpawner server (explained in <<spawning_methods_explained,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 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' <<RailsSpawnMethod,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 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 '600' (10 minutes).

=== Rack-specific options ===
[[RackEnv]]
==== rack_env <string> ====
This option allows one to specify the default `RACK_ENV` value.

This option may occur in the following places:

 * 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'.


== Analysis and system maintenance tools ==

include::users_guide_snippets/analysis_and_system_maintenance_tools.txt[]


== Tips ==

include::users_guide_snippets/tips.txt[]


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[]