# Passenger default config # http://modrails.com/documentation/Users%20guide%20Nginx.html # 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 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 # # 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 # # 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 # # 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 # # 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 # # 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 # # 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 # # 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
# # 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 # # 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 # # 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 # # 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 # # 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. # # 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 # # 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 # # 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 # # 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 # # 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 # # 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 # # 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 # # 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 # # 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 # # 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 # # 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 # # 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 # # 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 # # 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 # # 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;