kgateway is an Apache-2.0, Go-based control plane that implements the Kubernetes Gateway API for Envoy, giving platform and API teams a cloud-native API gateway for microservices, serverless functions and legacy backends across any cloud or environment.

What it is

kgateway is a Cloud Native Computing Foundation sandbox project that acts as a control plane for Envoy, programmed through the Kubernetes Gateway API. It was launched in 2018 as Gloo by Solo.io and has been production-ready since 2019, and it has evolved into a gateway that the project describes as the most mature and widely deployed in the market today. The codebase is written in Go and licensed under Apache-2.0, with 5,688 stars and 810 forks on GitHub.

The problem it solves is the gap between Kubernetes networking primitives and the policy layer that APIs actually need. Rather than hand-writing Envoy configuration or maintaining a per-team ingress setup, operators declare routes and policies through the Gateway API and let kgateway program Envoy. It lives squarely in the Kubernetes ecosystem and takes the place of bespoke Kubernetes ingress controllers and manual Envoy configuration, putting authentication, authorization and rate limiting in a single declared place. The same control plane scales from lightweight microgateway deployments between services up to centralized gateways that the README says handle billions of API calls.

Key capabilities

• Control plane implements the Kubernetes Gateway API for Envoy, so routing is declarative rather than hand-configured.
• Applies API policies in one place, including authentication, authorization and rate limiting.
• Supports route delegation and composable policies so multiple personas and teams can express APIs in the same cluster.
• Routes to backends implemented as microservices, serverless functions or legacy apps, enabling gradual migration off legacy code while existing systems keep running.
• Carries the kubernetes-ingress-controller role alongside api-management, grpc and hybrid-apps in its topic set.
• Scales from microgateway deployments between services to massively parallel centralized gateways, per the project's own description.
• From version 2.3.0, the agentgateway control plane moved to the separate agentgateway repository, leaving kgateway focused on Envoy-powered API gateway duties.

Who uses it and how

• Platform and infrastructure teams running Kubernetes who need a shared, policy-driven entry point for APIs instead of per-service ingress definitions.
• Organizations mid-migration that run microservices, serverless functions and legacy applications side by side, using routing to shift traffic gradually.
• Multi-tenant environments where several teams and personas share a cluster and rely on route delegation and composable policies to keep ownership separate.
• Large-scale operators: the project states it processes billions of API requests for many of the world's biggest companies.
• Teams replacing an existing Kubernetes ingress controller with a Gateway API-native gateway backed by Envoy.

Getting started

Installation and run instructions are published on the project site at https://kgateway.dev, with documentation at https://kgateway.dev/docs. Contributors start from devel/contributing/README.md, and release mechanics are described in devel/contributing/releasing.md.

How it compares

The provided facts do not list any paid products that kgateway replaces, and they name no directly competing gateway in this registry, so it stands alone here. Its only named relations are beneath it rather than beside it: Envoy as the data plane, the Kubernetes Gateway API as the configuration surface, and agentgateway as a sibling project that now owns the AI and agentic control plane. Anyone weighing it against another gateway should do that comparison outside this entry, since the facts here supply nothing to compare on licence, hosting or cost model.

When to use it — and when not to

A self-hoster needs a Kubernetes cluster and an Envoy data plane to operate, and should expect to manage policy, routing and upgrade cycles themselves; the README excerpt documents no database, object storage or SMTP dependency. Do not pick kgateway if the requirement is an AI or agentic gateway, because that control plane moved to the agentgateway repository at version 2.3.0 and is no longer part of this project's scope. The repository also carries 231 open issues and an excerpt that points to external docs rather than inline install commands, so teams wanting a single self-contained quickstart should read https://kgateway.dev/docs before committing.