File nginx_passenger.conf of Package rubygem-passenger

File nginx_passenger.conf of Package rubygem-passenger (Revision 83f7d73ed1dfc9d10af165e7d652e5ec)

Currently displaying revision 83f7d73ed1dfc9d10af165e7d652e5ec, show latest

# Passenger default config
# http://modrails.com/documentation/Users%20guide%20Nginx.html

# 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 or 
# passenger-config --root
# This required option may only occur once, in the http configuration block.
#
# The config variable got moved to its own file that will get updated by
# the package.
# 
include conf.d/passenger_root.include;

# 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.
passenger_ruby /usr/bin/ruby;

# passenger_spawn_method <string>
#
# 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:
#
# smart
#    When this spawn method is used, Phusion Passenger will attempt to cache 
#    any framework code (e.g. Ruby on Rails itself) and application code for a 
#    limited period of time. Please read Spawning methods explained for a more 
#    detailed explanation of what smart spawning exactly does.
#
# smart-lv2
#    This spawning method is similar to smart but it skips the framework 
#    spawner and uses the application spawner directly. This means the 
#    framework code is not cached between multiple applications, although it is 
#    still cached within instances of the same application. Please read 
#    Spawning methods explained for a more detailed explanation of what 
#    smart-lv2 spawning exactly does.
#
# conservative
#    This spawning method is similar to the one used in Mongrel Cluster. It 
#    does not perform any code caching at all. Please read Spawning methods 
#    explained for a more detailed explanation of what conservative spawning 
#    exactly does.
#
# This option may occur in the following places:
#    - In the http, server & location configuration block.
#    - In an if configuration scope.
#
# In each place, it may be specified at most once. The default value is smart-lv2.
#passenger_spawn_method smart-lv2;

# Important deployment options
# ============================

# passenger_enabled <on|off>
#
# 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 Ruby on Rails application and Deploying a Rack-based Ruby 
# application for examples.
#passenger_enabled on;

# 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 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 the http, server & location configuration block.
#    - In an if configuration scope.
#passenger_base_uri /app1;

# Connection handling options
# ===========================

# passenger_use_global_queue <on|off>
#
# Turns the use of global queuing on or off.
# This option may occur in the following places:
#    - In the http, server & location  configuration block.
#    - In an if configuration scope.
# In each place, it may be specified at most once. The default value is on.
#passenger_use_global_queue on;

# passenger_ignore_client_abort <on|off>
#
# 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, server, location configuration block.
#    - In an if configuration scope.
# In each place, it may be specified at most once. The default value is off.
#passenger_ignore_client_abort off;

# passenger_set_cgi_param <CGI environment name> <value>
#
# 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, server, location configuration block.
#    - In an if configuration scope.

# passenger_pass_header <header name>
#
# 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, server & location configuration block.
#    - In an if configuration scope.

# passenger_buffer_response <on|off>
#
# When turned on, application-generated responses are buffered in memory and 
# also on disk if the response is larger than a certain threshold. By 
# buffering responses, protection is provided against slow HTTP clients that 
# can not read your response immediately.
#
# This option may occur in the following places:
#    - In the http, server & location configuration block.
#    - In an if configuration scope.
# In each place, it may be specified at most once. The default value is on.
#passenger_buffer_response on;

# Security options
# ================

# passenger_user_switching <on|off>
#
# Whether to enable user switching support.
# This option may only occur once, in the http configuration block. The default value is on.
#passenger_user_switching on;

# passenger_user <username>
#
# If user switching support is enabled, then Phusion Passenger will by default 
# run the web application as the owner if 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, server & location configuration block.
#    - In an if configuration scope.
# In each place, it may be specified at most once.

# passenger_group <group name>
#
# 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 the http, server & location configuration block.
#    - In an if configuration scope.
#
# In each place, it may be specified at most once.

# passenger_default_user <username>
#
# 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.
#passenger_default_user nobody;

# passenger_default_group <group name>
#
# 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.
#passenger_default_group nobody;

# passenger_friendly_error_pages <on|off>
#
# 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, server & location configuration block.
#    - In an if configuration scope.
# In each place, it may be specified at most once. The default value is on.
#passenger_friendly_error_pages on;

# Resource control and optimization options
# =========================================

# 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.

# passenger_min_instances <integer>
#
# This specifies the minimum number of application instances that must be kept 
# around whenever Phusion Passenger cleans up idle instances. 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 instances during 
# Nginx startup. It just makes sure that when the application is first accessed:
#    - at least the given number of instances will be spawned.
#    - the given number of processes will be kept around even when instances 
#      are being idle cleaned (see passenger_pool_idle_time).
#
# If you want to pre-start application instances 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.
#
# The passenger_min_instances option may occur in the following places:
#   - In the http, server & 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_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 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 passenger_max_pool_size will be enforced.
#
# This option may only occur once, in the http configuration block. The default value is 0.

# 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.

# passenger_pre_start <url>
#
# By default, Phusion Passenger does not start any application instances 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 instances 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 passenger_min_instances 
#      because application instances 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.

# Logging and debugging options
# =============================

# passenger_log_level <integer>
#
# 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_log_level 0;

# passenger_debug_log_file <filename>
#
# 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.

# Ruby on Rails-specific options
# ==============================

# rails_env <string>
#
# This option allows one to specify the default RAILS_ENV value.
#
# This option may occur in the following places:
#    - In the http, server & location configuration block.
#    - In an if configuration scope.
# In each place, it may be specified at most once. The default value is production.
#rails_env production;

# rails_framework_spawner_idle_time <integer>
#
# The FrameworkSpawner server (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 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 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, server & 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_framework_spawner_idle_time 1800;

# rails_app_spawner_idle_time <integer>
#
# The ApplicationSpawner server (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 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 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, server & 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).
#rails_app_spawner_idle_time 600;

# Rack-specific options
# rack_env <string>
#
# This option allows one to specify the default RACK_ENV value.
#
# This option may occur in the following places:
#    - In the http, server & location configuration block.
#    - In an if configuration scope.
# In each place, it may be specified at most once. The default value is production.
#rack_env production;