NGINX Gateway Fabric, the Gateway API with NGINX as the data plane

A control plane that configures NGINX

NGINX Gateway Fabric is an open source project that provides an implementation of the Gateway API using NGINX as the data plane. The stated goal is to implement the core Gateway APIs, and the list is specific: Gateway, GatewayClass, HTTPRoute, GRPCRoute, TCPRoute, TLSRoute and UDPRoute, in order to configure an HTTP or TCP/UDP load balancer, a reverse proxy or an API gateway for applications running on Kubernetes. That is the whole scope, and it is worth being clear about it, because the project is not a general service mesh and not a multi-cloud gateway. It is the standard Kubernetes routing API with a very well understood data plane behind it. The configuration channel is NGINX Agent, which is how the control plane reaches the proxy. The documentation points at a design principles document and an architecture page, and the repository carries an Active project status badge next to the OpenSSF Scorecard, the continuous integration, the Go Report Card and the codecov badges.

The examples directory is the documentation that teaches

The examples in this repository are unusually broad, and they are the fastest way to understand what the project actually does. The list runs to more than twenty named directories, and the coverage is not just about routing. There is basic-authentication, external-authentication and secure-backend for the authentication side, cors-filter and the request and response header filters for the request handling side, rate-limit-policy and guardrails for traffic control, https-termination and tls-routing for the transport, tcp-routing, udp-routing and grpc-routing for the protocols, traffic-splitting for the weighting of backends, upstream-settings-policy and proxy-settings-policy and client-settings-policy for the fine tuning, accesspolicy for the access control layer, cross-namespace-routing for the multi-tenant case, snippets for injecting configuration, helm for the packaging, and waf-policy for the web application firewall module. The getting started path in the documentation is to run a kind cluster, install the platform, deploy these examples, and then follow the guides for routing and securing traffic or for monitoring the cluster.

Two release channels, and a versioning note that has aged

Releases are published on GitHub, and the README describes two channels. The latest release is 2.8.0, and the table pairs it with the manifests, documentation and examples built from that tag. The edge version is for experimenting with features that are not yet in a release, and it is built from the latest commit on the main branch, with its own manifests and examples taken from that branch. The difference in practice is who maintains your configuration, since the edge channel tracks unreleased code. The versioning section says the project uses semantic versioning, and then carries a note that major version zero is reserved for development and that anything may change at any time because the public API is not stable. That note is a leftover from the zero major version era, since the project is now at 2.8.0, and it is a small illustration of why the compatibility table, not the prose, is the document to trust. Release planning is tracked through GitHub milestones, and the ISSUE_LIFECYCLE.md file in the repository describes how an issue is created and assigned to a release.

Six components move together

The technical specifications table is the single most useful page for an adopter, because it shows that installing this platform means choosing a version of six things at once. For the 2.8.0 release and the edge version, the row reads Gateway API 1.6.3, Kubernetes 1.32 or newer, NGINX OSS 1.31.7, NGINX Plus R37.2, NGINX Agent v3.12.2 and F5 WAF for NGINX 5.16.0. The older rows show how the floor has moved over time, with 2.6.8 on Gateway API 1.5.1 and Kubernetes 1.31, 2.4.2 on Gateway API 1.4.1 and Kubernetes 1.25, and 1.2.0 on Gateway API 1.0.0 and Kubernetes 1.23. Two entries stand out. The F5 WAF column is empty for the 2.5.1 release and earlier, so the WAF module arrived partway through the 2.x line, and the Agent column is empty below 2.0.2, since the agent based configuration path is recent. A table like this is also a maintenance commitment, since a team that wants the newest Gateway API features has to move the NGINX and Agent versions with it.

What the Go dependencies say about the extension points

The go.mod is a map of the project's ambitions. The obvious entries are the Kubernetes client libraries at v0.37.1, controller-runtime for the controller machinery, and sigs.k8s.io/gateway-api at v1.6.3, which is the API being implemented, plus the gateway-api-inference-extension at v1.6.2 for the AI inference side. Two dependencies are more surprising and more telling. The envoy proxy control plane library is present, which is a sign that the project engages with the xDS style of configuration model that the Gateway API ecosystem grew up around. On the operations side there is the NGINX Agent at v3.12.2, the telemetry exporter, the AWS SDK for S3, OpenTelemetry with a gRPC trace exporter, the Prometheus client and the Prometheus operator API types, which is where the monitoring story comes from, and Cobra for the command line. The test stack is Ginkgo with Gomega, and the AWS SDK is there for the object storage path, which is a detail worth checking if you plan to read resources from a bucket.

Go, Rust, njs and Helm in one build

The Makefile shows that this is not a single language project. The Go binary is the controller, and the NGINX configuration templates live in internal/controller/nginx/conf, with njs modules under internal/controller/nginx/modules/src. Then there is a Rust directory, internal/controller/nginx/modules/rust/ai-guardrails, with its own test image, which is where the AI guardrails module is built, and a separate NGINX Docker build that passes the repository certificate and key as build secrets rather than copying them into the image, plus a second build argument for including the WAF module. Two experimental switches are exposed, ENABLE_EXPERIMENTAL and ENABLE_INFERENCE_EXTENSION, which map onto the features that are still settling. The build also handles its own telemetry, with the endpoint and a twenty four hour report period compiled into the binary through linker flags, and an insecure variant of that endpoint for local work. The supporting tooling is pinned in the Makefile too, with golangci-lint at v2.14.0, the kind node image at v1.37.0 and helm-docs at v1.14.2, all of them marked as renovate managed.

Editorial conclusion

NGINX Gateway Fabric fits a Kubernetes platform team that wants to expose services through the Gateway API and has NGINX, or wants to standardise on NGINX Plus, as the data plane, and it fits a team that learns a new platform by reading its examples, since the examples directory covers routing, security and traffic management in a form you can apply directly. It does not fit a team that wants a gateway independent of NGINX, since the data plane is the product rather than an implementation detail, and it does not fit a team that cannot accept a strict component matrix, because the supported versions of NGINX, the Agent, the WAF module and the Gateway API move together. Verify three things first: that the version of NGINX OSS or Plus you run matches the row in the compatibility table for the release you install, that the Gateway API resources and features you need are listed on the compatibility page rather than assumed, and whether you want the edge version built from the main branch, which the documentation reserves for experimentation rather than production.

Frequently asked questions

Official sources

1. Issues
2. License: Apache-2.0
3. nginx/nginx-gateway-fabric on GitHub
4. README
5. Releases