Web Server Load Balancing with NGINX Plus

Today we’re announcing the release of NGINX 1.6 and 1.7. This article explains how we schedule product releases at NGINX, Inc., and explains the significance of this version number change.

NGINX 1.6 was forked from the current mainline branch (1.5), which was then renumbered to 1.7. This is an annual checkpoint where we take the current mainline (feature) branch and fork it to a stable (no new features) branch. We continue active development on the renumbered mainline branch.

Version 1.4 is no longer supported. Version 1.6 is forked from version 1.5 as the new “stable” branch, and 1.5 is renumbered to 1.7 as the “mainline” branch

In NGINX nomenclature, “stable” means that no new features are added (the feature set is stable). Only major bug fixes are committed to that version.

We develop new features and all bug fixes in the mainline branch. We operate a time‑based release process, so you can expect to see new mainline releases approximately once per month, with exceptional releases when necessary. Over the last year, the mainline has seen the introduction of SPDY 3.1 support, authentication via subrequests, SSL session ticket support, IPv6 support for DNS, and PROXY protocol support. We integrated community contributions for SSL support for uwsgi. We’ve extended error logging, added cache revalidation directives, added SMTP pipelining, added buffering options for FastCGI, improved support for MP4 streaming, and extended handling of byte‑range requests for streaming and caching.

Note that stable does not mean more reliable or more bug‑free. In fact, the mainline is generally regarded as more reliable because we port all bug fixes to it, and not just critical fixes as for the stable branch. On the other hand, changes in the stable branch are very unlikely to affect third‑party modules. We don’t make the same commitment concerning the mainline, where new features can affect the operation of third‑party modules.

Which Version Should I Use?

We recommend that in general you deploy the NGINX mainline branch at all times. The main reason to use the stable branch is that you are concerned about possible impacts of new features, such as incompatibility with third‑party modules or the inadvertent introduction of bugs in new features.

If you have pinned your installation to the official NGINX repository, the next time you update you will get the latest 1.6 or 1.7 build as appropriate.

If you install NGINX from a third‑party repository, you might not have control over which version is deployed, and the repository might not keep pace with the mainline and stable branches. Where possible, install NGINX from our repository, where the binaries are tested against our internal regression framework and keep pace with releases from the official NGINX source.

You can run the nginx -V command to determine the version number of your NGINX binary:

user@host:~$ nginx -V
nginx version: nginx/1.5.12

What About NGINX Plus?

NGINX Plus is the commercially supported version of NGINX, with a number of additional features, many of which utilize a new shared‑memory architecture specific to NGINX Plus). NGINX Plus tracks the mainline version of NGINX, and is typically released on a three‑month cycle. New features in the mainline branch are merged into NGINX Plus and released once they have passed full integration testing and have been proven in field deployments of NGINX:

NGINX Plus tracks the NGINX mainline branch, and adds some commercial‑only features

The internal version numbers in NGINX Plus match the mainline release with which NGINX Plus is most closely synchronized.

Hero image
《NGINX 完全指南》2024 年最新完整版



Owen Garrett


Owen is a senior member of the NGINX Product Management team, covering open source and commercial NGINX products. He holds a particular responsibility for microservices and Kubernetes‑centric solutions. He’s constantly amazed by the ingenuity of NGINX users and still learns of new ways to use NGINX with every discussion.


F5, Inc. 是备受欢迎的开源软件 NGINX 背后的商业公司。我们为现代应用的开发和交付提供一整套技术。我们的联合解决方案弥合了 NetOps 和 DevOps 之间的横沟,提供从代码到用户的多云应用服务。访问 了解更多相关信息。