Kong Gateway 3.9: One Control Plane for APIs, LLMs, and MCP Traffic

What Kong Actually Solves

Kong Gateway is a proxy that sits between clients and your backend services, handling routing, load balancing, health checks, and authentication. The README positions it as a central layer for microservices and conventional API traffic, but the headline addition in recent versions is AI traffic. It now covers LLM providers and MCP (Model Context Protocol) traffic, which is a different workload than typical HTTP APIs. The intended user is an engineering team that operates many services and wants one place to enforce policies like rate limits, transformations, and logging. If you have a single API and no need for central policy, Kong is overkill. The value grows with the number of services and the diversity of traffic types you must govern.

How the Gateway Is Put Together

Kong is written in Lua, which is unusual for a gateway but explains its plugin model. The core proxy handles L4 and L7 traffic, SSL/TLS termination, and routing. Everything else comes from plugins. The README lists plugins for authentication (JWT, basic auth, OAuth, ACLs), traffic control, rate limiting, request and response transformation, and logging. Plugins can be written in Lua, Go, or JavaScript, which broadens who can extend the gateway. The architecture is split into two planes in hybrid mode: a control plane for configuration and a data plane for traffic. There is also a DB-less declarative mode where configuration is provided as a file rather than stored in a database. This separation is a key design choice: you can run Kong without a database for simple setups, or with Postgres for dynamic configuration via the Admin API. The README does not explain how plugins are loaded internally, but the Plugin Development Kit (PDK) is referenced as the interface for building them.

Getting It Running: Docker and Declarative Config

The quickest path is the Docker Compose distribution. The README gives two commands: clone the docker-kong repository, then start the stack with KONG_DATABASE=postgres docker-compose --profile database up. That brings up Postgres and the gateway. Port 8000 receives traffic, port 8001 exposes the Admin API, and port 8002 serves Kong Manager, the web UI. For a database-less setup, the docs point to a separate Docker installation procedure. The README does not show the exact DB-less command, but it does indicate that declarative configuration is a supported deployment model. That means you can define services, routes, and plugins in a YAML file and load it via decK, the command-line tool mentioned for configuration. The Admin API is RESTful, so you can also script configuration changes. The setup is straightforward for someone who has used Docker Compose before. The dependency on Postgres in the default compose file is worth noting, because it adds a stateful component to what might otherwise be a stateless proxy.

The AI and MCP Features Are the Real Differentiator

The README highlights a universal LLM API that routes requests across providers like OpenAI, Anthropic, GCP Gemini, AWS Bedrock, Azure AI, Databricks, Mistral, and Huggingface. This is not just a proxy; it is an abstraction layer that lets you switch providers without changing your client code. The feature list also includes semantic security, caching, and semantic routing, which are more advanced than simple rate limiting. MCP traffic governance and security are mentioned, plus autogeneration of MCP from any RESTful API. That last feature is notable: it suggests you can expose existing REST endpoints as MCP tools without writing a server. The documentation link points to a separate AI gateway product page, so the open source repository may not include all these features out of the box. The README says "60+ AI features" but does not enumerate them, so you should check the official AI documentation to see which are available in the community edition versus the paid product. This is a point where the README is thin, and you will need to verify specifics before relying on them.

Kubernetes and the Ingress Controller

Kong runs natively on Kubernetes through its official ingress controller, which is a separate repository (kubernetes-ingress-controller). This is a significant advantage if you are already on Kubernetes because it lets you define Kong configuration as Kubernetes resources, using the same declarative approach as the rest of your cluster. The ingress controller handles routing and can apply Kong plugins to services based on annotations or custom resources. The README does not detail the controller's configuration, but the existence of a dedicated project means you are not limited to the Docker Compose workflow. For teams that manage infrastructure with GitOps, this integration is likely the main reason to choose Kong over a simpler proxy. The trade-off is that you now have two systems to understand: the gateway itself and the ingress controller's mapping to Kubernetes objects. The documentation for the controller is separate, so you will need to consult it for specifics like how to expose the Admin API or how to configure TLS.

Limitations and Failure Modes

One limitation is the operational complexity. The default compose stack includes Postgres, and hybrid mode requires managing separate control and data planes. That is a lot of moving parts for a gateway that could be a single binary. If you do not need dynamic configuration, the DB-less mode is simpler, but the README does not give a one-line command for it, so you must dig into the docs. Another failure mode is plugin compatibility. Kong has a large plugin hub, but many plugins are community-developed, and the README does not state which are officially supported. A plugin that works on version 3.8 might break on 3.9, given the release cadence. The changelog is the only source for that, and it is not summarized in the README. Also, the AI features are the biggest selling point, but the README points to a separate product page for the AI gateway, which suggests some capabilities may be gated behind the commercial offering. If you need those features, verify the community edition includes them before building your architecture around them.

Alternatives and How They Differ

The most direct alternative is Envoy, which is also a high-performance proxy but takes a different approach. Envoy is written in C++ and uses a filter chain model where you compose behavior from a set of built-in filters. Kong uses a plugin model where you write or install plugins, often in Lua. Envoy has a steeper learning curve for configuration, but it is more transparent about its internals and has a broader set of networking features out of the box. For Kubernetes, you could also use NGINX Ingress Controller, which is simpler but does not have the same plugin ecosystem or AI capabilities. The real difference is that Kong positions itself as an application-layer gateway with business logic, while Envoy is a data-plane proxy that you must assemble with control plane tooling like Istio. If your primary need is LLM and MCP traffic, Kong's universal API is a differentiator that Envoy does not offer directly; you would have to build that abstraction yourself. That is a concrete trade-off: Kong gives you a ready-made AI layer but ties you to its plugin model, while Envoy gives you more control but more work.

Maintenance, Licensing, and Upgrade Path

Kong is licensed under Apache-2.0, which is permissive and allows commercial use without copyleft obligations. That is a clean license for most organizations. Maintenance is active; the repository shows releases in June 2026, with 3.9.3 as the latest patch. The project follows Semantic Versioning, so you can expect breaking changes only in major versions, but minor releases like 3.9.x may still introduce new plugin behavior. The README points to a changelog for details, which is where you should look before upgrading. The upgrade cost is tied to your deployment mode. If you use Postgres, you must handle database migrations, which Kong typically runs automatically but can require downtime in large setups. If you use DB-less mode, upgrades are simpler because you just replace the binary and reload the declarative config. The hybrid mode adds the complexity of upgrading control and data planes in coordination. The plugin ecosystem is a long-term cost: you may depend on community plugins that are not updated for new versions, so you need to test after each upgrade. The README does not provide a migration guide, but the changelog and documentation are the resources you would use.

Editorial conclusion

Adopt Kong Gateway if you need one gateway for conventional APIs and emerging LLM or MCP traffic, especially in Kubernetes where the official ingress controller is a natural fit. Skip it if you only proxy a handful of REST endpoints and want minimal operational overhead, because the plugin ecosystem and deployment modes demand real configuration effort. Before committing, verify that your target LLM providers are covered by the universal API, confirm whether you need DB-less or hybrid mode for your scale, and review the changelog for 3.9.x to see if recent fixes address your specific plugin combinations.

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes