# 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;
#
# avoid using tmp directories, since cleanup jobs will remove files
#
passenger_temp_dir @passengertmpdir@
# 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;