NGINX API Gateway: Features, Use Cases & Guide

The NGINX API gateway has become a cornerstone for organizations seeking high performance, scalability, and control over API traffic. By leveraging the power of NGINX as an API gateway, you gain flexibility in traffic management and security while supporting a range of architectural patterns, including microservices and hybrid environments.

Comparing NGINX API Gateway with Other Solutions

There are several leading API gateway technologies available, such as Kong, AWS API Gateway, and Envoy. NGINX API gateway stands out due to its lightweight architecture, robust performance, and integration flexibility. Unlike some cloud-native solutions that may require proprietary infrastructure or tight cloud-provider integration, NGINX can be deployed anywhere you need—on-premises, in the cloud, or at the edge.

Among the alternatives, Kong Gateway is itself built on NGINX and OpenResty and extends it with a Lua plugin ecosystem. Envoy-based gateways, such as kgateway, Envoy Gateway, and Istio ingress gateways, implement the Kubernetes Gateway API and apply configuration changes dynamically through xDS rather than file reloads. For LLM, MCP, and A2A traffic, purpose-built AI gateways such as agentgateway handle sessions, streaming, and token-based limits natively.

Performance: NGINX is renowned for low latency and the ability to process thousands of API calls per second.
Flexibility: Customize routing, authentication, and rate limiting through configuration or Lua extensions.
Deployment: Easily fits into legacy, hybrid, or containerized workloads without heavy dependencies.

Learn more about NGINX and other gateway technologies at Solo.io NGINX Topics.

Frequently Asked Questions about NGINX API Gateway

What distinguishes the NGINX API gateway from just using NGINX as a reverse proxy?

While both approaches use NGINX’s powerful routing engine, the API gateway mode provides advanced capabilities such as API authentication, granular rate limiting, request/response transformation, and centralized monitoring, which are not part of a basic reverse proxy setup.

Is NGINX API gateway suitable for Kubernetes and cloud-native workloads?

Yes. NGINX can integrate directly with container orchestration platforms such as Kubernetes, either as a Kubernetes Ingress controller or a standalone gateway, enabling seamless management of modern microservices APIs.

How do I choose between open source and commercial NGINX API gateway options?

If your organization requires enterprise support, advanced analytics, or out-of-the-box security integrations, commercial solutions like NGINX Plus may be preferred. The open source edition is a solid starting point for basic API gateway use cases.

What is the NGINX API gateway?

An API gateway secures and orchestrates traffic between backend services and API consumers. NGINX Plus API Gateway receives all API requests from clients, determines which services are required by the request, and delivers responses with high performance. NGINX provides ultra-fast API responses in less than 30 milliseconds, and can handle thousands of requests per second.

Key features of the the NGINX Plus API Gateway include:

Authenticates API calls
Routes requests to the appropriate backend
Applies rate limiting to prevent service overload
Mitigates DDoS attacks
Offloads SSL/TLS traffic
Improves API performance and handles errors and exceptions

How is NGINX currently used as an API gateway?

NGINX can be deployed as an API gateway in three ways:

Using native NGINX functionality—some organizations use basic NGINX features to directly manage API traffic. For example, NGINX can identify whether API traffic is HTTP or gRPC, and translate API management requirements into NGINX configurations to receive, route, rate limit, and secure API requests.
Extending NGINX with Lua—OpenResty is an open source product based on NGINX, which adds the Lua interpreter to the NGINX core, allowing users to build feature-rich functionality on top of NGINX. Lua modules can also be compiled and loaded into NGINX open source and NGINX Plus builds. There are many NGINX-based open source API gateway implementations, most of which use Lua or OpenResty.
NGINX Plus API Gateway—using NGINX’s dedicated API gateway product.

When using the first two options for API management, keep the following in mind:

Performance and request latency—Lua is a great way to extend NGINX, but it can degrade NGINX performance. Independent testing of a simple Lua script shows a performance degradation of 50 to 90%. If you choose a solution that relies heavily on Lua, make sure it meets your performance requirements without adding latency to requests.
Converged approach—the NGINX server can manage API traffic in parallel to normal web traffic. An API gateway is a subset of standard NGINX features. When you use other products to manage the network or API communications, these solutions can add complexity to DevOps, CI/CD, monitoring, security, and other application development and delivery capabilities. Using NGINX both for web and API traffic can simplify the architecture.

What are the benefits of the NGINX API Gateway?

The table below illustrates API gateway use cases for channeling external API calls to internal services.

	Use of API Gateway	Reverse Proxy of NGINX
Topology Management	Multiple application programming interfaces for accepting configuration changes and facilitating blue-green processes	Using APIs and service discovery to track down endpoints (NGINX Plus); orchestrating APIs for blue-green deployment
Authorization Offloading	Authentication tokens in incoming requests are interrogated	The use of external auth services in addition to internal authentication mechanisms (such as JWTs, API keys, and OpenID Connect)
Vulnerable Applications Protection	API and method-based rate limiting	Limiting connections to backend services and imposing rate limits based on various criteria such as origin IP address or request parameters
API Lifecycle Management	Rewriting legacy API queries and rejecting API calls that have been deprecated	Requests can be rewritten in various ways, and a robust decision engine can be used to redirect or respond
Request Routing	In order to determine where to send a request, the service (host header), API method (HTTP URL), and parameters are all taken into account	Route requests depend on their host header, URL, and other parameters
Additional Protocols	TCP-borne message queue	WebSocket, TCP, UDP
Core Protocols	gRPC HTTP, REST (HTTPS)	HTTPS, gRPC, HTTP/2

NGINX can control web traffic by translating across protocols like HTTP/2, HTTP, FastCGI, and uwsgi, offering uniform configuration and monitoring platforms. In addition, NGINX is flexible enough to execute in containers with minimal resources required.

Tutorial: Deploying NGINX as an API gateway

Here is a tutorial that explains how to deploy NGINX as an API gateway for a RESTful API that communicates using JSON.

The general process is:

Install NGINX Plus: If you don’t already have NGINX Plus installed, you’ll need to download and install it on your server. You can find detailed installation instructions on the NGINX website.
Define the API endpoints: Next, you’ll need to define the endpoints that your API will expose. An endpoint is a specific location within the API that can be accessed and performs a specific function. For example, you might have an endpoint that returns a list of users or an endpoint that allows users to create a new account. You can define your endpoints in a configuration file, using the NGINX Plus API gateway syntax.
Configure the API gateway: Next, you’ll need to configure the API gateway to route requests to the appropriate backend service. You’ll need to specify the location of the backend service and the URL path that the API gateway should use to access it. You can also configure additional functionality, such as rate limiting and data transformation, at this stage.
Test the API gateway: Once you’ve configured the API gateway, you can test it to ensure that it is working correctly. You can use a tool like cURL or Postman to send test requests to the API gateway and verify that it is correctly routing requests to the backend service and returning the correct responses.
Deploy the API gateway: When you’re satisfied that the API gateway is working correctly, you can deploy it to your production environment. You’ll need to make sure that the API gateway is running on a server that is accessible to your clients, and that it is configured to handle the expected load.

Here is what the code looks like:

The following minimal nginx.conf example defines a backend service, a simple rate limit, and a route that proxies API requests to that backend. (A complete nginx.conf also needs an events {} block.)

http {
    # Define the backend services the gateway routes to
    upstream users_service {
        server 10.0.0.10:8080;
        server 10.0.0.11:8080;
    }

    # Allow 10 requests per second per client IP
    limit_req_zone $binary_remote_addr zone=api_limit:10m rate=10r/s;

    server {
        listen 80;
        server_name api.example.com;

        # Route /api/users requests to the users service
        location /api/users {
            limit_req zone=api_limit burst=20 nodelay;
            proxy_pass http://users_service;
            proxy_set_header Host $host;
            proxy_set_header X-Real-IP $remote_addr;
        }

        # Reject requests that don't match a defined API route
        location / {
            return 404;
        }
    }
}

This configuration does three things:

The upstream users_service block defines the backend servers. NGINX load balances requests across them (round robin by default).
The limit_req_zone directive tracks clients by IP address and allows 10 requests per second. The limit_req directive in the /api/users location applies that limit, with a burst of 20.
The location /api/users block uses proxy_pass to forward matching requests to users_service and passes the original host and client IP. The location / block returns 404 for any path that is not a defined API route.

Run nginx -t to validate the configuration, then nginx -s reload to apply it.

API gateway management with agentgateway and kgateway

For AI and agentic traffic, such as LLM calls, MCP tool servers, and agent-to-agent (A2A) communication, start with agentgateway: an open source, Rust-based Linux Foundation project built for AI protocols, with Solo Enterprise for agentgateway adding enterprise features and 24x7 support. For conventional API traffic, NGINX alternatives built on Envoy Proxy are the common path.

While NGINX can be used in API Gateway use cases, many companies are alternatively choosing to move to a more modern, cloud native API gateway architecture based on Envoy Proxy. Solo Enterprise for kgateway builds on kgateway (open source, free forever) to deliver a more secure, more scalable, more extensive API Gateway than NGINX.

kgateway itself is open source and free forever (CNCF). Solo Enterprise for kgateway adds enterprise support and features on top.

kgateway is Kubernetes native, and able to run on any cloud.
kgateway integrates with GitOps to enable highly automated environments.
kgateway integrated with DevSecOps best practices to ensure compliance with major industry standards.
kgateway integrates with Solo Enterprise for Istio, to help scale as the Kubernetes and microservices environments grow.

Get started with agentgateway for AI and agent traffic (or Solo Enterprise for agentgateway), kgateway (CNCF open source, free forever), Solo Enterprise for kgateway for enterprise API gateway capabilities, or Solo Enterprise for Istio for service mesh.