What it is
Kong Gateway is an API gateway for microservices, regular API traffic, and newer LLM/MCP scenarios. Its central role is to sit between clients and services.
The project grew from a practical infrastructure problem: as services multiply, routing, access checks, limits, observability, and policies should not live separately in every service.
Kong’s main task is to accept requests, proxy them to the right services, apply plugins, and provide one traffic management layer.
What is inside
Inside the project are the Lua/OpenResty ecosystem, plugins, documentation, Kubernetes Ingress Controller, installation modes, and material for running it yourself.
Kong can route, load-balance, check service health, add authentication, rate-limit requests, and extend behavior through the plugin hub.
How people use it
A normal scenario is to put Kong in front of a set of services, define routes and services, then add security, logging, and limit policies.
In Kubernetes, Kong is often used as an ingress layer to manage incoming traffic through declarative rules.
Example
A route through the gateway
This example shows Kong’s role: an external path is connected to an internal service, and policies can be added around the route.
client -> Kong Gateway -> service: http://orders:8080
route: /api/orders
plugins: auth, rate-limit, loggingStrengths
The project’s strength is extensibility. The API gateway becomes not just a proxy, but a place to apply repeated rules centrally.
Another advantage is maturity in microservice environments: many traffic tasks already exist as plugins and integrations.
Limitations
The limitation is that an API gateway becomes a critical architecture point. A mistake in config, plugin, or limit can affect many services at once.
Kong also does not replace a good API contract. It manages entry and policies, while schemas, errors, and versioning remain service-team work.
Who it fits
Kong fits organizations with several services that need unified control over incoming traffic, security, and observability.
For a small app with one API, it may be unnecessary if the same tasks are calmly handled inside the framework.
In the catalog, Kong matters as a notable open project at the boundary of API infrastructure and platform engineering.
A practical start is to connect one non-critical service, define a route, add a simple plugin, and check how the team stores and reviews configuration.
In practical architecture, Kong often appears once there are enough services for policies to repeat. If authentication, limits, and logs are configured in one place, service teams copy less identical code.