# kgateway: the Envoy control plane that outgrew the Gloo name

> A Kubernetes Gateway API implementation built on Envoy, split off from Solo.io's Gloo in 2018 and now maintained as a CNCF sandbox project with two release lines shipping in parallel.

**kgateway-dev/kgateway** — The Cloud-Native API Gateway and AI Gateway

- Repository: https://github.com/kgateway-dev/kgateway
- Website: https://kgateway.dev
- Stars: 5,688 · Forks: 810
- Language: Go
- License: Apache-2.0
- Published: 2026-10-07 · Updated: 2026-10-07 · Language: en
- Canonical page: https://hysenlabs.com/projects/kgateway-dev-kgateway

## From Gloo to kgateway, and what the tree says about it

The project started in 2018 as Gloo, built by Solo.io, and reached a production-ready 1.0 in 2019. It now lives under the kgateway-dev organisation, describes itself as the Cloud-Native API Gateway and AI Gateway, points its homepage at kgateway.dev, and carries 5,688 stars with 810 forks and 228 open issues. The last push was 2026-09-19.

The README itself is short. It opens with badges, one paragraph about being a resilient and performance-oriented control plane that implements the Kubernetes Gateway API for Envoy, three use-case bullets, a history note, and then a block of community links. There is no YAML in it. The first honest observation about this repository is that it is a signpost to kgateway.dev/docs rather than a manual in its own right.

The directory listing carries more information than the prose does. `api/` holds the custom resource types, `cmd/` the entry points, `internal/` and `pkg/` the implementation, `install/` the packaging, `design/` the design documents, `devel/` contributor guides, `examples/` fourteen YAML files plus two directories, `test/`, `hack/` and `tools/`. At the root sit a `Tiltfile`, `.golangci.yaml`, `.goreleaser.yaml`, `osv-scanner.toml`, `THREAT_MODEL.md` and both `AGENTS.md` and `CLAUDE.md`, which says something concrete about how the project expects day-to-day work to happen.

## Two release lines shipping on the same afternoon

The three most recent releases are v2.4.5 and v2.3.9, both published on 2026-09-16 and roughly 24 minutes apart, and v2.4.4 from 2026-08-31. Two major version lines in maintenance at the same time is a deliberate signal about upgrade support.

What makes those two notes interesting is that they carry the same fix. An OAuth2 TrafficPolicy would stay permanently broken if the OpenID provider was unreachable the first time kgateway discovered its configuration, which is exactly what happens when the control plane and the identity provider restart together. The failure latched until the control plane itself was restarted. Discovery now retries in the background, starting 30 seconds after a failure and backing off exponentially, so recovery from a long provider outage can take a few minutes.

Both notes also mention an apiKeyAuth TrafficPolicy that selected two Secrets holding the same api-key value. Envoy rejects a duplicate credential, which froze xDS delivery for the entire listener while the policy still reported itself as Accepted. Identical credentials are now collapsed, and two clients genuinely sharing one key value fail translation with the policy reporting Accepted=False. That second case is the more instructive one, because it describes a state where a policy looks healthy and the data plane is not receiving updates at all.

## Four resource kinds and a three tier policy split

`examples/` is the most useful directory in the repository. It contains `example-gw.yaml`, `example-http-route.yaml`, `httpbin.yaml`, and then a run of policy examples whose filenames spell out the resource model: `example-listener-policy-with-additional-fields.yaml`, `example-basic-auth-traffic-policy.yaml`, `example-backendconfigpolicy-circuit-breakers.yaml`, `example-gatewayparameters-stats-matcher.yaml`, `example-direct-response-route.yaml`, `example-http-route-with-header-modifier.yaml`.

The naming pattern separates two families. Gateway and HTTPRoute come from the Gateway API itself, so those examples are about compliance rather than invention. Everything else is a kgateway-specific kind, and they sort cleanly into three scopes: GatewayParameters for cluster-wide configuration, ListenerPolicy for anything that belongs to a listener, and TrafficPolicy plus BackendConfigPolicy for things attached at route or service level. If you have used Istio, that split will feel familiar, for the reason given below.

The v2.4.5 release is a good illustration of why the three tiers are separated. It added `normalizePath` and `mergeSlashes` fields to ListenerPolicy's `httpSettings`, both defaulting to true to match what had been hardcoded before. Turning a previously implicit path-normalisation behaviour into a listener-scoped setting only makes sense when the listener is a first-class object you can attach policy to.

## What version 2.3.0 handed back to agentgateway

One README callout explains the most significant structural decision. kgateway previously acted as a control plane for the agentgateway data plane in order to enable AI and agentic features. Starting with version 2.3.0, that control plane was migrated to the agentgateway repository, so that kgateway could concentrate on being a stable, well-tested API gateway powered by Envoy.

The README closes by thanking Envoy and agentgateway as the two data planes it builds on, describing the result as a dual control plane architecture. That is the honest answer to the question of how kgateway and agentgateway differ: they sit at different points in the same architecture rather than competing for the same traffic, and kgateway no longer carries the agent-side control plane at all.

The practical consequence is that anyone arriving from the AI gateway side may land on a repository that no longer serves that purpose, and the roadmap questions move elsewhere. For the traffic kgateway does claim, the README describes a range from lightweight microgateway deployments sitting between services up to massively parallel centralised gateways handling billions of API calls, with route delegation and composable policies for multi-team tenancy.

## Reading go.mod to understand what this is built on

The module header is two lines and the dependency list is the real specification.

```go
module github.com/kgateway-dev/kgateway/v2
go 1.26.7
```

The require block pulls in `envoyproxy/go-control-plane` with its contrib, ratelimit and envoy submodules, `istio.io/api`, `istio.io/client-go` and `istio.io/istio` at 1.30.0-alpha, `k8s.io/api` and `k8s.io/apiextensions-apiserver` at v0.36.2, and `helm.sh/helm/v3`. The Istio entries are the headline. kgateway consumes Istio's API types rather than defining a parallel service mesh vocabulary, which places it as a peer that interoperates with a mesh instead of one that tries to replace it.

Two other root files are load bearing rather than decorative. `.custom-gcl.yml` configures a custom build of the Go linter, and `osv-scanner.toml` drives dependency vulnerability scanning. The v2.4.4 notes confirm the second one matters, recording an Envoy update made specifically for CVE fixes. That combination of an explicit threat model document, a scanner config and monthly releases is a reasonable signal about how seriously the security side is handled.

## Distribution, governance, and where the documentation takes over

The v2.4.4 release notes state that the project ships as a Helm chart and as Docker images, with the chart published to an OCI registry under `cr.kgateway.dev`. The Makefile defaults the image registry to `ghcr.io/kgateway-dev`, so container images and the chart live in two different places, which is worth knowing before you write automation around either one.

The README footer carries a CNCF sandbox project badge. Sandbox is the earliest governance tier, so it is worth naming accurately: this is a project under active development with an outside sponsor, not a graduated one with a mature technical steering committee.

Almost everything you need to decide anything lives off the README. Contributing and releasing both point into `devel/contributing/`, and configuration, policy reference and upgrade guidance are on kgateway.dev. So the practical reading order for someone evaluating this is unusual: skip the README, work through the example YAML files to learn the resource model, then use the docs site for the details those files deliberately leave out. The questions the README genuinely does not answer are which policy kind owns which scope, how a data plane failure surfaces when a policy still reports Accepted, and how the two active release lines are supported.

## Conclusion

kgateway is worth reading for the shape of its policy model rather than its feature list. GatewayParameters, ListenerPolicy, TrafficPolicy and BackendConfigPolicy form a clear three-tier split between cluster, listener and route scope, and the examples directory is more informative than the README. The trade is that the README is a pointer to kgateway.dev, not a manual. Before committing, check which of the two active release lines your install guide targets, since v2.4.x and v2.3.x were both taking patches on the same afternoon in September 2026.

## FAQ

### What are the key differences between Agentgateway and Kgateway?

They sit at different points in one architecture rather than competing. kgateway is the control plane for Envoy, and until version 2.3.0 it also hosted the control plane for the agentgateway data plane. That agent-side control plane has moved to its own repository, leaving kgateway focused on L7 API gateway work.

### What policy types does kgateway add beyond the Gateway API?

Four custom kinds, split across three scopes. GatewayParameters covers cluster-wide settings, ListenerPolicy covers anything bound to a listener, and TrafficPolicy and BackendConfigPolicy attach at route or service level. The examples directory has a YAML file for each, which is the fastest way to see how they compose.

### Is kgateway the same project as Gloo?

It is the continuation of it. The project launched in 2018 as Gloo under Solo.io and was production ready by 2019. It now ships as kgateway under the kgateway-dev organisation, and the README points at a published migration plan covering the transition.

### How is kgateway distributed?

As a Helm chart and Docker images. The chart is published to an OCI registry at oci://cr.kgateway.dev/kgateway-dev/charts/kgateway, and the repository ships a Tiltfile plus an install directory for local development.

## Sources

- [kgateway-dev/kgateway on GitHub](https://github.com/kgateway-dev/kgateway)
- [License: Apache-2.0](https://github.com/kgateway-dev/kgateway/blob/main/LICENSE)
- [Project website](https://kgateway.dev)
- [README](https://github.com/kgateway-dev/kgateway/blob/main/README.md)
- [Releases](https://github.com/kgateway-dev/kgateway/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/kgateway-dev-kgateway