Kong puts API, LLM, and MCP traffic behind one gateway
Kong began as an API gateway and now presents the same boundary for model and agent traffic. Conventional services get routing, load balancing, health checks, TLS termination, authentication, authorization, rate limits, transformations, and logs. AI Gateway adds a common LLM API across OpenAI, Anthropic, Gemini, Bedrock, Azure AI, Databricks, Mistral, Hugging Face, and other providers. MCP support adds traffic governance, security, analytics, and generation of MCP interfaces from REST APIs.
That combination matters when a platform needs one policy point for several traffic types. Model providers differ in authentication, limits, and failure behavior, while MCP servers add tool permissions. A gateway keeps clients thinner and gives operators one place to stop traffic. Kong then becomes part of every request path and must be operated like critical network infrastructure.
The local trial opens 3 ports and uses PostgreSQL
The README recommends cloning the separate docker-kong repository, entering its Compose directory, and starting the database profile. Proxy requests arrive on port 8000. The Admin API listens on 8001, and Kong Manager appears on 8002. A DB-less Docker procedure is also documented for declarative configuration. Konnect offers a managed control plane for teams that prefer a hosted route, while the Apache-licensed gateway can run on containers, bare metal, or Kubernetes.
A successful proxy request is only the beginning. Production needs certificates, upstream health policy, protected administration, configuration promotion, backups, plugins, logs, and upgrades. AI use adds provider credentials, routing, and failure policy. MCP adds server identity, tool authorization, and audit requirements. Kong centralizes those controls; each still needs an owner and a test.
What happened when we ran it
Our sandbox measured spec/fixtures/proxy_wasm_filters at commit fa9c3b6. Cargo installed 65 packages in 11 seconds and built the Rust fixture in 22 seconds. Tests finished in 10 seconds with 6 passed and 0 failed out of 6. The environment was an unprivileged container with 3 CPUs, 12 GB of RAM, and no secrets. This result is clean and narrowly scoped.
The fixture is not Kong Gateway. It does not exercise the main Lua application, OpenResty, PostgreSQL mode, DB-less configuration, the Admin API, proxy routing, AI plugins, MCP controls, or the management UI. The repository scan found 2,499 files, about 4,264 source lines by the harness counter, 24 CI workflows, and a tests directory, but no Dockerfile. Buyers should not quote the 6 passing tests as proof that a Kong deployment or plugin set works.
Plugins supply policy and create compatibility work
Kong's plugin model is the practical center of the product. First-party and community plugins add authentication, traffic control, transformations, monitoring, serverless calls, and provider-specific behavior. Developers can extend the gateway in Lua, Go, or JavaScript. Declarative DB-less mode suits immutable configuration, while database and hybrid modes support other operational patterns. The Kubernetes ingress controller connects these gateway policies to cluster resources without changing the proxy's core job.
Plugins also touch streaming bodies, credentials, caches, and request phases where small mistakes create noisy failures. Issue #14967 reports that the response-transformer plugin logs a warning for every intermediate chunk of a large JSON response even though the final transformation succeeds. The report identifies an existing large-response test that does not assert log output. This is not a data-corruption report, but false warnings can flood logs and trigger alerts, so large or streamed responses belong in plugin acceptance tests.
DNS and administration deserve targeted failure tests
Issue #14970 documents Kong 3.7 failing to resolve an upstream container literally named web, while the operating system resolver and other container names work. The reporter reproduced the behavior on Docker Desktop and native Linux, and Kong substituted 127.0.53.53 before returning 502. Renaming the service to webui fixed it. The report is version-specific and does not establish the behavior in 3.9.3, but the minimal reproduction is relevant to Compose users.
Another current report says malformed foreign keys or workspaces can produce a generic 500 from the Admin API where a 400 with the actual validation message would be more useful. Gateway teams should test bad configuration as carefully as good configuration: invalid upstream names, unavailable DNS, expired vault secrets, oversized bodies, provider timeouts, and partial control-plane failure. A traffic gateway earns trust through failure behavior, not through a successful hello-world route.
Open source gateway and commercial platform are separate decisions
The repository is Apache 2.0 and includes the gateway, plugin development kit, DB-less mode, hybrid deployment, and Kubernetes integration. The README separately describes Konnect subscriptions with managed control plane services, analytics, a service catalog, and developer portals. AI Gateway marketing also groups many capabilities under a broad product name. Teams should map every required plugin and control to its actual edition before assuming the open repository covers the buying list.
Kong Community can be judged against APISIX or an Envoy-based platform. Konnect belongs against managed API platforms. LiteLLM is narrower for teams that only need model normalization and budgets. Existing Kong users can add AI and MCP policy incrementally. New adopters should confirm that general API governance justifies the wider system.
Current maintenance supports a production shortlist
GitHub showed 44,039 stars, 191 open issues and pull requests, and a last push on August 16, 2026. The latest GitHub release we fetched was 3.9.3 from June 17. Recent issues cover DNS, UTF-8 validation, Admin API status codes, response transformation, and vault secret deduplication. The later push and active reports matter more than the release date alone when judging health.
Kong belongs on the shortlist for a shared edge that must handle many services and now several AI protocols. Test the exact edition, deployment mode, and plugins with representative traffic. Include a provider outage, an MCP authorization failure, DNS failure, a large streamed response, and an unavailable database or control plane. If those tests feel excessive for the application, Kong is probably excessive too. If they match risks the platform already owns, centralizing them at a mature gateway is a reasonable decision.