NGINX downloads are available for two separate branches of NGINX code—mainline and stable. The mainline branch is the one in which active development is taking place. Here is where new features will be found and integrated before finding their way into the stable branch. When a mainline version is released, it has undergone the same QA and a similar set of functional tests as the stable branch, so either branch may be used on production systems. The major difference between the two branches lies in the support of third-party modules. The internal API may change in the mainline release, whereas it stays the same on the stable branch, so backward compatibility for third-party modules is only available for stable releases.
In order to compile NGINX from source, certain requirements need to be met on your system. Besides a compiler, you also need the OpenSSL and Perl Compatible Regular Expressions (PCRE) libraries and development headers if you want to enable SSL support and be able to use the rewrite module, respectively. The rewrite module is enabled by default, so if you don't have PCRE libraries and headers, you'll need to disable the rewrite module during the configuration phase. Depending on your system, these requirements may already be met in the default installation. If not, you will need to both locate the appropriate package and install it, or download the source, unpack it, and point NGINX's configure script to this location.
NGINX will attempt to build a dependent library statically if you include a --with-<library>=<path>
option to configure. You might do this if you want to ensure that NGINX is not dependent on any other part of the system and/or would like to squeeze that extra bit of performance out of your nginx
binary. If you are using features of external libraries that are only available from a certain version onwards (for example, the next protocol negotiation TLS extension available from OpenSSL Version 1.0.1), then you have to specify the path to the unpacked sources of that particular version.
There are other, optional, packages that you can provide support for, if you like. These include MD5 and SHA-1 hashing algorithm support, zlib
compression, and libatomic
library support. The hashing algorithms are used in many places in NGINX, for example, to compute the hash of a URI to determine a cache key. The zlib
compression library is used for delivering gzipped
content. If the atomic_ops
library is available, NGINX will use its atomic memory update operations to implement high-performance memory-locking code.
NGINX can be downloaded from http://nginx.org/en/download.html. Here you will find the source of either branch in .tar.gz
, or .zip
format. Unpack the archive into a temporary directory as follows:
$ mkdir $HOME/build $ cd $HOME/build && tar xzf nginx-<version-number>.tar.gz
Configure it using the following command:
$ cd $HOME/build/nginx-<version-number> && ./configure
And compile it as follows:
$ make && sudo make install
When compiling your own nginx
binary, you are much more free to include only what you need. Can you already say under which user NGINX should run? Do you want to specify the default log file locations so that they don't need to be explicitly set in the configuration? The following table of configure options will help you design your own binary. These are options that are valid for NGINX, independent of which module is activated.
You are also able to compile with optimizations that you may not get in a packaged installation. This is where the following options can be especially useful:
NGINX is unique among high-performing web servers in that it was also designed to be a mail proxy server. Depending on your goals in building NGINX, you can configure it for web acceleration, a web server, a mail proxy, or all three. It may be beneficial to have one package that you can install on any server in your infrastructure and be able to set NGINX's role through configuration, or it may serve your needs better to have a slimmed-down binary to use in high-performance environments where every extra KB counts.
The following table specifies configuration options that are unique to the mail module.
For a typical mail proxy, I would recommend configuring NGINX as follows:
$ ./configure --with-mail --with-mail_ssl_module --with-openssl=${BUILD_DIR}/openssl-1.0.1p
SSL/TLS is needed nowadays on almost every mail installation and not having it enabled on a mail proxy robs users of expected functionality. I've recommended compiling OpenSSL statically so that there are no dependencies on the operating system's OpenSSL library. This does mean, though, that you will have to be vigilant and ensure that your statically-compiled OpenSSL is kept up-to-date and rebuild your binary when necessary. The BUILD_DIR
variable referenced in the preceding command would of course have to be set beforehand.
The following table shows what configuration options are available to the http
module, from activating the Perl module to specifying the location of temporary directories.