NGINX Gateway Fabric is an open-source project that provides an implementation of the Gateway API using NGINX as the data plane. The goal of this project is to implement the core Gateway APIs -- Gateway, GatewayClass, HTTPRoute, TCPRoute, TLSRoute, and UDPRoute -- to configure an HTTP or TCP/UDP load balancer, reverse-proxy, or API gateway for applications running on Kubernetes. NGINX Gateway Fabric supports a subset of the Gateway API.

For a list of supported Gateway API resources and features, see the Gateway API Compatibility doc.

Learn about our design principles and architecture.

1. Quick Start on a kind cluster.
2. Install NGINX Gateway Fabric.
3. Build an NGINX Gateway Fabric container image from source or use a pre-built image available on GitHub Container Registry.
4. Deploy various examples.
5. Read our guides.

We publish NGINX Gateway Fabric releases on GitHub. See our releases page.

The latest release is 1.0.0.

The edge version is useful for experimenting with new features that are not yet published in a release. To use, choose the edge version built from the latest commit from the main branch.

The table below summarizes the options regarding the images, manifests, documentation and examples and gives your links to the correct versions:

NGF uses semantic versioning for its releases. For more information, see https://semver.org.

Major version zero (0.Y.Z) is reserved for development, anything MAY change at any time. The public API is not stable.

The features that will go into the next release are reflected in the corresponding milestone. Refer to the Issue Lifecycle document for information on issue creation and assignment to releases.

The following table lists the software versions NGINX Gateway Fabric supports.

*the installation manifests use the minor version of NGINX container image (e.g. 1.25) and the patch version is not specified. This means that the latest available patch version is used.

We generate SBOMs for the binaries and the Docker image.

The SBOMs for the binaries are available in the releases page. The SBOMs are generated using syft and are available in SPDX format.

The SBOM for the Docker image is available in the GitHub Container repository. The SBOM is generated using syft and stored as an attestation in the image manifest.

For example to retrieve the SBOM for linux/amd64 and analyze it using grype you can run the following command:

docker buildx imagetools inspect ghcr.io/nginxinc/nginx-gateway-fabric:edge --format '{{ json (index .SBOM "linux/amd64").SPDX }}' | grype

For troubleshooting help, see the Troubleshooting document.

We’d like to hear your feedback! If you experience issues with our Gateway Controller, please open a bug in GitHub. If you have any suggestions or enhancement requests, please open an idea on GitHub discussions. You can contact us directly via [email protected] or on the NGINX Community Slack in the #nginx-gateway-fabric channel.

Please read our Contributing guide if you'd like to contribute to the project.

NGINX Gateway Fabric is not covered by any support contract.

This document describes which Gateway API resources NGINX Gateway Fabric supports and the extent of that support.

Gateway API features has three support levels: Core, Extended and Implementation-specific. We use the following terms to describe the support status for each level and resource field:

• Supported. The resource or field is fully supported.
• Partially supported. The resource or field is supported partially or with limitations. It will become fully supported in future releases.
• Not supported. The resource or field is not yet supported. It will become partially or fully supported in future releases.

Note: it might be possible that NGINX Gateway Fabric will never support some resources and/or fields of the Gateway API. We will document these decisions on a case by case basis.

NGINX Gateway Fabric doesn't support any features from the experimental release channel.

Below we list the resources and the support status of their corresponding fields.

For a description of each field, visit the Gateway API documentation.

Support Levels:

• Core: Supported.
• Extended: Not supported.
• Implementation-specific: Not supported.

NGINX Gateway Fabric supports only a single GatewayClass resource configured via --gatewayclass flag of the static-mode command.

Fields:

• spec
  • controllerName - supported.
  • parametersRef - not supported.
  • description - supported.
• status
  • conditions - supported (Condition/Status/Reason):
    • Accepted/True/Accepted
    • Accepted/False/InvalidParameters
    • Accepted/False/GatewayClassConflict: Custom reason for when the GatewayClass references this controller, but a different GatewayClass name is provided to the controller via the command-line argument.

Support Levels:

• Core: Supported.
• Extended: Partially supported.
• Implementation-specific: Not supported.

NGINX Gateway Fabric supports only a single Gateway resource. The Gateway resource must reference NGINX Gateway Fabric's corresponding GatewayClass. See static-mode command for more info.

Fields:

• spec
  • gatewayClassName - supported.
  • listeners
    • name - supported.
    • hostname - supported.
    • port - supported.
    • protocol - partially supported. Allowed values: HTTP, HTTPS.
    • tls
      • mode - partially supported. Allowed value: Terminate.
      • certificateRefs - The TLS certificate and key must be stored in a Secret resource of type kubernetes.io/tls. Only a single reference is supported.
      • options - not supported.
    • allowedRoutes - supported.
  • addresses - not supported.
• status
  • addresses - partially supported. LoadBalancer and Pod IP.
  • conditions - supported (Condition/Status/Reason):
    • Accepted/True/Accepted
    • Accepted/True/ListenersNotValid
    • Accepted/False/ListenersNotValid
    • Accepted/False/Invalid
    • Accepted/False/UnsupportedValue- custom reason for when a value of a field in a Gateway is invalid or not supported.
    • Accepted/False/GatewayConflict- custom reason for when the Gateway is ignored due to a conflicting Gateway. NGF only supports a single Gateway.
    • Programmed/True/Programmed
    • Programmed/False/Invalid
    • Programmed/False/GatewayConflict- custom reason for when the Gateway is ignored due to a conflicting Gateway. NGF only supports a single Gateway.
  • listeners
    • name - supported.
    • supportedKinds - supported.
    • attachedRoutes - supported.
    • conditions - supported (Condition/Status/Reason):
      • Accepted/True/Accepted
      • Accepted/False/UnsupportedProtocol
      • Accepted/False/InvalidCertificateRef
      • Accepted/False/ProtocolConflict
      • Accepted/False/UnsupportedValue- custom reason for when a value of a field in a Listener is invalid or not supported.
      • Accepted/False/GatewayConflict - custom reason for when the Gateway is ignored due to a conflicting Gateway. NGF only supports a single Gateway.
      • Programmed/True/Programmed
      • Programmed/False/Invalid
      • ResolvedRefs/True/ResolvedRefs
      • ResolvedRefs/False/InvalidCertificateRef
      • ResolvedRefs/False/InvalidRouteKinds
      • Conflicted/True/ProtocolConflict
      • Conflicted/False/NoConflicts

Support Levels:

• Core: Supported.
• Extended: Partially supported.
• Implementation-specific: Not supported.

Fields:

• spec
  • parentRefs - partially supported. Port not supported.
  • hostnames - supported.
  • rules
    • matches
      • path - partially supported. Only PathPrefix and Exact types.
      • headers - partially supported. Only Exact type.
      • queryParams - partially supported. Only Exact type.
      • method - supported.
    • filters
      • type - supported.
      • requestRedirect - supported except for the experimental path field. If multiple filters with requestRedirect are configured, NGINX Gateway Fabric will choose the first one and ignore the rest.
      • requestHeaderModifier - supported. If multiple filters with requestHeaderModifier are configured, NGINX Gateway Fabric will choose the first one and ignore the rest.
      • responseHeaderModifier, requestMirror, urlRewrite, extensionRef - not supported.
    • backendRefs - partially supported. Backend ref filters are not supported.
• status
  • parents
    • parentRef - supported.
    • controllerName - supported.
    • conditions - partially supported. Supported (Condition/Status/Reason):
      • Accepted/True/Accepted
      • Accepted/False/NoMatchingListenerHostname
      • Accepted/False/NoMatchingParent
      • Accepted/False/NotAllowedByListeners
      • Accepted/False/UnsupportedValue - custom reason for when the HTTPRoute includes an invalid or unsupported value.
      • Accepted/False/InvalidListener - custom reason for when the HTTPRoute references an invalid listener.
      • Accepted/False/GatewayNotProgrammed - custom reason for when the Gateway is not Programmed. HTTPRoute may be valid and configured, but will maintain this status as long as the Gateway is not Programmed.
      • ResolvedRefs/True/ResolvedRefs
      • ResolvedRefs/False/InvalidKind
      • ResolvedRefs/False/RefNotPermitted
      • ResolvedRefs/False/BackendNotFound
      • ResolvedRefs/False/UnsupportedValue - custom reason for when one of the HTTPRoute rules has a backendRef with an unsupported value.
      • PartiallyInvalid/True/UnsupportedValue

Support Levels:

• Core: Supported.
• Extended: N/A.
• Implementation-specific: N/A

Fields:

• spec
  • to
    • group - supported.
    • kind - supports Secret and Service.
    • name- supported.
  • from
    • group - supported.
    • kind - supports Gateway and HTTPRoute.
    • namespace- supported.

Status: Not supported.

Status: Not supported.

Status: Not supported.

Status: Not supported.

Custom policies will be NGINX Gateway Fabric-specific CRDs that will allow supporting features like timeouts, load-balancing methods, authentication, etc. - important data-plane features that are not part of the Gateway API spec.

While those CRDs are not part of the Gateway API, the mechanism of attaching them to Gateway API resources is part of the Gateway API. See the Policy Attachment doc.