nginx 1.30

NGINX 1.30 is a stable-line release that consolidates the work from the preceding 1.29 mainline series. Relative to the prior stable line, its change set is cumulative: it brings the mainline branch’s completed features, bug fixes, protocol and TLS changes, and configuration behavior changes into a branch intended for conservative deployment. Teams should treat the upstream CHANGES files for 1.29 and 1.30 as the authoritative migration delta, particularly where they use optional HTTP, stream, mail, TLS, caching, or third-party dynamic modules. NGINX has not announced that the 1.30 line is retired, and no active-maintenance cutoff is known for it.

Remaining on 1.30 means accepting that fixes and compatibility changes delivered only in newer NGINX lines are unavailable. The practical exposure grows when later releases address security defects, HTTP or TLS interoperability issues, regressions, or compatibility with newer operating systems and cryptographic libraries. Locally built or vendor-supplied third-party modules are a separate risk: they may lag newer NGINX APIs, or a future upgrade may require rebuilding and retesting them. The absence of a declared retirement decision or known maintenance cutoff should not be read as evidence of continuing active patch work; teams should check the current upstream release activity and the fixes included after their deployed 1.30 patch level.

Inventory every NGINX instance, its exact patch level, build options, loaded modules, TLS libraries, operating-system packages, and configuration includes. Compare the upstream change logs from the deployed version through the intended target, then identify changes affecting request routing, proxying, caching, HTTP/2 or HTTP/3, TLS, logging, and custom modules. Test the target version in a representative environment with production traffic patterns, certificate rotation, upstream failures, reloads, and rollback procedures. Prefer packages maintained by the operating-system or trusted vendor where they meet requirements; otherwise establish a repeatable build process and rebuild every compatible dynamic module. Continue monitoring upstream releases and security advisories rather than relying on lifecycle metadata alone.