Have a Cookie? :)

Our site uses cookies to provide functionality and performance as well as for social media and advertising purposes. Social media and advertising cookies of third parties are used to offer you social media functionalities and personalized ads for NGINX content and offers. To get more information about these cookies and how we process personal data, check our Privacy Policy. Do you accept the use of cookies and the processing of personal data involved?

Your Cookie Settings

Site functionality and performance

These cookies are required for NGINX site functionality and are therefore always enabled. These include cookies that allow you to be remembered as you explore the NGINX site, help make the shopping cart and checkout process possible as well as assist in security issues and conforming to regulations. To use the NGINX website, you have to consent to these cookies and the processing of personal data according to the NGINX website terms of use and privacy policy.

Social media and advertising

Social media cookies offer the possibility to connect you to your social networks and share content from our website through social media. Advertising cookies (of third parties) collect information to help better tailor NGINX advertising to your interests, both within and beyond NGINX websites. De-selecting these cookies may result in seeing advertising that is not as relevant to you or you not being able to link effectively with Facebook, Twitter, or other social networks and/or not allowing you to share content on social media.

Choosing Between a Stable or a Mainline Version

Mainline – Includes the latest features and bug fixes and is always up to date. It is reliable, but it may include some experimental modules, and it may also have some number of new bugs.

Stable – Doesn’t include all of the latest features, but has critical bug fixes that are always backported to the mainline version. We recommend the stable version for production servers.

Choosing Between a Prebuilt Package and Compiling from Source

Both the NGINX Open Source mainline and stable versions can be installed in two ways:

As a prebuilt binary package. This is a quick and easy way to install NGINX Open Source. The package includes almost all official NGINX modules and is available for most popular operating systems. See Installing a Prebuilt Package.

As binaries you compile from source. This way is more flexible: you can add particular modules, including third‑party modules, or apply the latest security patches. See Compiling and Installing from Source for details.

Installing a Prebuilt Package

Installing NGINX Open Source from a package is much easier and faster than building from source, but building from source enables you to compile in non-standard modules. Prebuilt packages are available for most popular Linux distributions, including CentOS, Debian, Red Hat Enterprise Linux (RHEL), SUSE Linux Enterprise Server (SLES), and Ubuntu. See Linux packages at nginx.org for the list of currently supported operating systems.

Modules Included in a Prebuilt Package

See Configure Arguments at nginx.org for the list of modules included in each prebuilt package.

Installing Prebuilt CentOS and RHEL Packages

NGINX, Inc. provides packages for the following CentOS, Oracle Linux, and RHEL versions:

Version

Supported Platforms

6.x

x86_64, i386

7.4+

x86_64, ppc64le

The package can be installed from:

A default RHEL or CentOS repository. This is the quickest way, but generally the provided package is outdated.

The official repo at nginx.org. You have to set up the yum repository the first time, but after that the provided package is always up to date.

Installing a Prebuilt CentOS/RHEL Package from an OS Repository

Install the EPEL repository:

$ sudo yum install epel-release

Update the repository:

$ sudo yum update

Install NGINX Open Source:

$ sudo yum install nginx

Verify the installation:

$ sudo nginx -v
nginx version: nginx/1.6.3

Installing a Prebuilt CentOS/RHEL Package from the Official NGINX Repository

Set up the yum repository for RHEL or CentOS by creating the file nginx.repo in /etc/yum.repos.d, for example using vi:

Configuring the Build Options

Configure options are specified with the ./configure script that sets up various NGINX parameters, including paths to source and configuration files, compiler options, connection processing methods, and the list of modules. The script finishes by creating the Makefile required to compile the code and install NGINX Open Source.

An example of options to the configure script (should be typed as a single line):

Configuring NGINX Paths

The configure script allows you to set paths to NGINX binary and configuration files, and to dependent libraries such as PCRE or SSL, in order to link them statically to the NGINX binary.

Parameter

Description

--prefix=<PATH>

Directory for NGINX files, and the base location for all relative paths set by the other configure script options (excluding paths to libraries) and for the path to the nginx.conf configuration file. Default: /usr/local/nginx.

--sbin-path=<PATH>

Name of the NGINX executable file, which is used only during installation. Default: <prefix>/sbin/nginx

--conf-path=<PATH>

Name of the NGINX configuration file. You can, however, always override this value at startup by specifying a different file with the -c<FILENAME> option on the nginx command line. Default: <prefix>conf/nginx.conf

--pid-path=<PATH>

Name of the nginx.pid file, which stores the process ID of the nginx master process. After installation, the path to the filename can be changed with the pid directive in the NGINX configuration file. Default: <prefix>/logs/nginx.pid

--error-log-path=<PATH>

Name of the primary log file for errors, warnings, and diagnostic data. After installation, the filename can be changed with the the error_log directive in the NGINX configuration file. Default: <prefix>/logs/error.log

--http-log-path=<PATH>

Name of the primary log file for requests to the HTTP server. After installation, the filename can always be changed with the access_log directive in the NGINX configuration file. Default: <prefix>/logs/access.log

--user=<NAME>

Name of the unprivileged user whose credentials are used by the NGINX worker processes. After installation, the name can be changed with the user directive in the NGINX configuration file. Default: nobody

--group=<NAME>

Name of the group whose credentials are used by the NGINX worker processes. After installation, the name can be changed with the user directive in the NGINX configuration file. Default: the value set by the --user option.

--with-pcre=<PATH>

Path to the source for the PCRE library, which is required for regular expressions support in the location directive and the Rewrite module.

--with-pcre-jit

Builds the PCRE library with “just-in-time compilation” support (the pcre_jit directive).

--with-zlib=<PATH>

Path to the source for the zlib library, which is required by the Gzip module.

Configuring NGINX GCC Options

With the configure script you can also specify compiler‑related options.

Parameter

Description

--with-cc-opt="<PARAMETERS>"

Additional parameters that are added to the CFLAGS variable. When using the system PCRE library under FreeBSD, the mandatory value is --with-cc-opt="-I/usr/local/include". If the number of files supported by select() needs to be increased, it can also specified here as in this example: --with-cc-opt="-DFD_SETSIZE=2048".

--with-ld-opt="<PARAMETERS>"

Additional parameters that are used during linking. When using the system PCRE library under FreeBSD, the mandatory value is --with-ld-opt="-L/usr/local/lib".

Specifying NGINX Connection Processing Methods

With the configure script you can redefine the method for event‑based polling. For more information, see Connection processing methods in the NGINX reference documentation.

Module Name

Description

--with-select_module, --without-select_module

Enables or disables building a module that enable NGINX to work with the select() method. The modules is built automatically if the platform does not appear to support more appropriate methods such as kqueue, epoll, or /dev/poll.

--with-poll_module, --without-poll_module

Enables or disables building a module that enables NGINX to work with the poll() method. The module is built automatically if the platform does not appear to support more appropriate methods such as kqueue, epoll, or /dev/poll.

Selecting the NGINX Modules to Build

NGINX consists of a set of function‑specific modules, which are specified with configure script along with other build options.

Some modules are built by default – they do not have to be specified with the configure script. Default modules can however be explicitly excluded from the NGINX binary with the --without-<MODULE-NAME> option on the configure script.

Modules not included by default, as well as third‑party modules, must be explicitly specified in the configure script together with other build options. Such modules can be linked to NGINX binary either statically (they are then loaded each time NGINX starts) or dynamically (they are loaded only if associated directives are included in the NGINX configuration file.

Modules Built by Default

If you do not need a module that is built by default, you can disable it by naming it with the --without-<MODULE-NAME> option on the configure script, as in this example which disables the Empty GIF module (should be typed as a single line):

Used to implement location and variable handlers in Perl and insert Perl calls into SSI. Requires the PERL library. To compile as a separate dynamic module instead, change the option to --with-http_perl_module=dynamic.

Transforms XML responses using one or more XSLT stylesheets. The module requires the Libxml2 and XSLT libraries. To compile as a separate dynamic module instead, change the option to --with-http_xslt_module=dynamic.

Including Third-Party Modules

You can extend NGINX functionality by compiling NGINX Open Source with your own module or a third‑party module. Some third‑party modules are listed in the NGINX Wiki. Use third‑party modules at your own risk as their stability is not guaranteed.

Statically Linked Modules

Most modules built into NGINX Open Source are statically linked: they are built into NGINX Open Source at compile time and are linked to the NGINX binary statically. These modules can be disabled only by recompiling NGINX.

To compile NGINX Open Source with a statically linked third‑party module, include the --add-module=<PATH> option on the configure command, where <PATH> is the path to the source code (this example is for the RTMP module):

$ ./configure ... --add-module=/usr/build/nginx-rtmp-module

Dynamically Linked Modules

NGINX modules can also be compiled as a shared object (*.so file) and then dynamically loaded into NGINX Open Source at runtime. This provides more flexibility, as the module can be loaded or unloaded at any time by adding or removing the associated load_module directive in the NGINX configuration file and reloading the configuration. Note that the module itself must support dynamic linking.

To compile NGINX Open Source with a dynamically loaded third‑party module, include the --add-dynamic-module=<PATH> option on the configure command, where <PATH> is the path to the source code:

$ ./configure ... --add-dynamic-module=<PATH>

The resulting *.so files are written to the the prefix/modules/ directory, where the prefix is a directory for server files such as /usr/local/nginx/.

To load a dynamic module, add the load_module directive to the NGINX configuration after installation: