NGINX Community Blog

What’s New in F5 NGINX Gateway Fabric 2.3.0 

—

by

Micheál Kingston
in

We’re pleased to announce F5 NGINX Gateway Fabric (NGF) 2.3.0, and we’re shipping it a little early, right before the holidays, for one compelling reason: to meet strong community demand for a Kubernetes Gateway API conformance-focused release.   

With this release, NGF is now one of only five generally available Gateway API implementations, as shown in the community’s official Gateway Controller Implementation Status.  

After the ingress-nginx retirement announcement, we saw a significant spike in downloads of NGF. Clearly, the community is kicking the tires on upgrading to Gateway API implementation. By increasing our release cadence and continuing to build out useful additional functionality, we are making NGF even more capable at production scale and more versatile for Kubernetes traffic management requirements.. 

At a glance 

In NGF 2.3.0, we focused on: 

  • Gateway API v1.4.1 conformance (upgrade + conformance alignment) (PR #4166) (GitHub) 
  • Enhanced RegularExpression path matching aligned with real-world NGINX migration patterns (RE2/PCRE-friendly validation) (PR #4450) (GitHub) 

You can review everything included in the release here: NGF 2.3.0 GitHub release notes and the NGF documentation changelog. (GitHub) 

Gateway API v1.4.1 conformance 

NGF 2.3.0 updates Gateway API dependencies to v1.4.1, ensuring NGF stays aligned with the latest GA spec and conformance expectations. (PR #4166, Gateway API v1.4.1 release) (GitHub) 

Why it matters: 
Gateway API adoption is accelerating, and conformance is how platform teams de-risk standard-based routing and avoid “implementation surprises” during migration. Staying current on conformance is also how the ecosystem keeps interoperability real, not aspirational. Net net, conforming platforms mean more trustworthy and reliable systems. 

Who it helps: 

  • Platform engineering and SRE teams standardizing cluster networking across teams and environments 
  • Organizations migrating from Ingress that want a clean, spec-aligned runway to Gateway API 
  • Enterprises building multi-controller strategies where conformance reduces integration friction 

BackendTLSPolicy support for upstream mTLS 

NGF 2.3.0 expands support for securing traffic from the gateway to backends using Gateway API’s BackendTLSPolicy, including common requirements for upstream verification and mutual TLS patterns. (Gateway API TLS guide, GEP-1897, PR #3900) 
For NGF-specific guidance, see: Securing backend traffic using mutual TLS. 

Why it matters: 
Many teams terminate TLS at the edge and stop there. BackendTLSPolicy support makes it practical to enforce encryption and identity all the way to upstream services, which is increasingly requiredfor regulated workloads, zero trust architectures, and internal service-to-service hardening. 

Who it helps: 

  • Security and compliance teams implementing end-to-end encryption and stronger service identity controls 
  • Platform teams that need a standards-based way to express upstream TLS behavior across clusters 
  • Application owners running sensitive internal services who want mTLS without bespoke sidecar complexity 

Customizable access logs (format + ability to disable) 

This release adds first-class support to customize the NGINX access log format (or disable access logging) via the NginxProxy configuration. This was a highly requested capability from users who want logs to “just drop in” to existing log pipelines. (Issue #1200, PR #4102) (GitHub) 

Concretely, NGF’s API now supports spec.logging.accessLog.format and spec.logging.accessLog.disable. The format string maps to NGINX log_format semantics. (NGF API reference, NGINX log_format docs) (NGINX Documentation) 

Why it matters: 
Operational logs are only useful if they’re parsable, consistent, and aligned with your existing observability stack. Custom formatting reduces downstream parsing glue, and disabling access logs can be important for high-throughput gateways where logs are handled differently (or where audit strategy is externalized).  

Who it helps: 

  • SRE and observability teams integrating NGF into Splunk, Elastic, Datadog, OpenSearch, and SIEM pipelines 
  • Platform engineers standardizing log schemas across gateways and clusters 
  • High-scale environments where teams need explicit control over log volume and format 

Multiple InferencePool backends (Gateway API Inference Extension) 

NGF 2.3.0 improves flexibility for AI inference routing by supporting multiple InferencePool backends in a route’s backendRefs. (Issue #4192, PR #4439) (GitHub) 
If you’re exploring the broader model-routing patterns, see NGF’s guide: Gateway API Inference Extension. 

Why it matters: 
Real inference deployments often require routing across multiple pools for capacity, model variants, or staged rollout patterns. Supporting multiple pools cleanly improves composability and reduces awkward “one route per pool” workarounds. 

Who it helps: 

  • AI platform teams operating multiple inference backends (per model, per team, per SLA tier) 
  • Teams doing progressive delivery for inference workloads (canary, blue-green, shadow) 
  • Organizations standardizing inference traffic management using the emerging Gateway API inference patterns 

Enhanced RegularExpression path matching aligned with NGINX migration realities 

NGF 2.3.0 improves how RegularExpression (Regex) path matching behaves for teams migrating existing NGINX-style routes. Specifically, NGF now validates regex in a way that is intended to be PCRE and RE2 friendly, reducing surprises when teams bring over “real” NGINX regex patterns from ingress-nginx or hand-authored NGINX configs. (PR #4450) (GitHub) 

Why it matters: 
Regex is frequently where migrations bog down: patterns that worked for years in NGINX can fail validation or behave unexpectedly under stricter matching rules. This change is meant to keep the migration path smooth while remaining compatible with Gateway API’s RegularExpression intent. 

Who it helps: 

  • Teams migrating from ingress-nginx with existing NGINX regex path rules 
  • Platform teams consolidating disparate routing rules into Gateway API without rewrites 
  • Application owners who rely on regex-based routing for versioning, legacy paths, or complex route trees 

Additional updates 

Alongside the headline features, NGF 2.3.0 also includes a set of stability and lifecycle improvements, including updates to key components such as NGINX Plus and NGINX Agent. (PR #4365, PR #4372) (GitHub) 

Looking ahead to 2026 

2026 will be an inflection point for Gateway API adoption. NGF’s roadmap is focused on enterprise-grade production capabilities, including deeper security controls, robust operational features, and comprehensive support. NGINX is seeing this, as well, in user behavior. By far, NGF now constitutes the majority of all downloads for ingress and Kubernetes traffic management and is among the most popular Gateway API implementations in the CNCF.  

If you have customers evaluating their path forward, especially teams migrating from community ingress-nginx, this is an excellent time to start the transition planning toward a supported Gateway API implementation with a clear conformance-driven roadmap. We are happy to help. You can contact us in Slack or via email. 

Release notes and resources