nginx 1.14

The 1.14 stable line incorporated the development work that followed the preceding stable line. Notable additions include HTTP/2 server-push controls, gRPC proxying through the ngx_http_grpc_module, and the mirror module for duplicating requests to a secondary destination without using that destination’s response. It also accumulated the compatibility fixes, HTTP handling changes, and module refinements made during the intervening mainline development series. These capabilities are available only when the relevant modules were built into the nginx binary and configured correctly.

This cycle has reached end of life, so nginx upstream no longer provides fixes for newly discovered defects or security issues in this line. Remaining on it leaves the edge proxy, TLS termination point, and HTTP request-processing path dependent on an unmaintained codebase. It also makes it harder to adopt current TLS and HTTP features, current operating-system and cryptographic-library combinations, and fixes expected by modern deployment tooling. The longer a deployment remains on 1.14, the more likely its configuration, custom modules, and surrounding automation will require a larger jump rather than a routine upgrade. Third-party or locally compiled modules are a particular risk because they may need to be rebuilt and retested for the target nginx binary.

Select a currently maintained nginx target line and identify whether the deployment uses nginx open source or a separately supported commercial distribution; do not assume their package, module, or upgrade paths are interchangeable. Inventory the running binary’s build options, loaded dynamic modules, configuration includes, TLS settings, upstream protocols, caching behavior, and any use of HTTP/2 push, gRPC proxying, or request mirroring. Build or obtain target-compatible versions of every required third-party module, then test the existing configuration with the target binary in a non-production environment. Exercise TLS handshakes, reloads, static and proxied traffic, WebSocket or gRPC traffic where applicable, caching, logging, and error handling. Roll out gradually with configuration and binary rollback procedures prepared, and remove obsolete directives or workarounds only after their replacement behavior has been verified.