Version support
Review the following information about supported release versions for the agentgateway project.
Supported versions
| agentgateway | Release date | Kubernetes | Gateway API* | Helm | Istio† |
|---|---|---|---|---|---|
| 1.0.x | 16 Mar 2026 | 1.31 - 1.35 | 1.5.x | >= 3.12 | 1.23 - 1.29 |
| 2.2.x | 09 Feb 2026 | 1.31 - 1.35 | 1.4.x | >= 3.12 | 1.23 - 1.27 |
* Gateway API versions: The agentgateway project is conformant to the Kubernetes Gateway API specification. For more details, see the Gateway API docs and agentgateway conformance report per version, such as Gateway API v1.5.0.
† Istio versions: Istio must run on a compatible version of Kubernetes. For example, Istio 1.27 is tested, but not supported, on Kubernetes 1.28. For more information, see the Istio docs.
Release development
New features for agentgateway are developed on main before being part of a release. Tags are created off of main for each release, such as v1.0.0.
Release process
Development of a quality stable release on main typically follows this process:
- New feature development is suspended on
main. - Release candidates are created, such as
1.0.0-rc.1,1.0.0-rc.2, and so on. - A full suite of tests is performed for each release candidate. Testing includes all documented workflows, a test matrix of all supported platforms, and more.
- Documentation for that release is prepared, vetted, and staged.
- The stable minor version is released as part of a tag, such as
v1.0.0. - Feature development on
mainis resumed.
Feature development on main branch
Feature development is performed on the main branch. Merges to main trigger CI tests and linting, but do not automatically produce published development builds. Releases are tag-driven: a build is published only when a version tag (such as v1.0.0) is pushed or a release is triggered manually.
Backports
New features are neither developed nor backported to long-term support branches. However, critical patches, bug fixes, and documentation updates are released as needed.
Experimental features in Gateway API
The following features are experimental in the upstream Kubernetes Gateway API project, and are subject to change.
| Feature | Minimum Gateway API version |
|---|---|
ListenerSets* | 1.3 |
| TCPRoutes | 1.3 |
TLSRoutes* | 0.3 |
| BackendTLSPolicy | 1.4 |
CORS policies* | 1.2 |
| Retries | 1.2 |
| Session persistence | 1.3 |
| HTTPRoute rule attachment option | 1.3 |
* Note: ListenerSets, CORS in HTTPRoutes, and TLSRoutes moved from the experimental to the standard channel in Gateway API version 1.5.
Experimental feature gate: To use experimental Gateway API features in agentgateway, you must enable the KGW_ENABLE_GATEWAY_API_EXPERIMENTAL_FEATURES environment variable in your agentgateway controller deployment. This setting defaults to false and must be explicitly enabled. For example, you might upgrade your installation with the following Helm value:
controller:
extraEnv:
KGW_ENABLE_GATEWAY_API_EXPERIMENTAL_FEATURES: "true"Sample command for version 1.5.0: Note that some CRDs are prefixed with X to indicate that the entire CRD is experimental and subject to change.
kubectl apply --server-side -f https://github.com/kubernetes-sigs/gateway-api/releases/download/v1.5.0/experimental-install.yaml