For the complete documentation index, see llms.txt. Markdown versions of all docs pages are available by appending .md to any docs URL.
Version support
View supported versions and their release cycle.
Review the following information about supported release versions for the agentgateway project.
Supported versions
| agentgateway | Release date | Kubernetes | Gateway API* | MCP spec† | Helm | Istio‡ |
|---|---|---|---|---|---|---|
| 1.5.x | 27 Aug 2026 | 1.32 - 1.37 | 1.4 - 1.6 | 2026-07-28 | >= 3.12 | 1.23 - 1.30 |
| 1.4.x | 27 Jul 2026 | 1.31 - 1.36 | 1.4 - 1.6 | 2026-07-28 | >= 3.12 | 1.23 - 1.30 |
| 1.3.x | 18 Jun 2026 | 1.31 - 1.36 | 1.3 - 1.5 | 2025-11-25 | >= 3.12 | 1.23 - 1.30 |
| 1.2.x | 14 May 2026 | 1.31 - 1.36 | 1.3 - 1.5 | 2025-11-25 | >= 3.12 | 1.23 - 1.29 |
| 1.1.x | 09 Apr 2026 | 1.31 - 1.35 | 1.3 - 1.5 | 2025-06-18 | >= 3.12 | 1.23 - 1.29 |
| 1.0.x | 16 Mar 2026 | 1.31 - 1.35 | 1.3 - 1.5 | 2025-06-18 | >= 3.12 | 1.23 - 1.29 |
| 2.2.x | 09 Feb 2026 | 1.31 - 1.35 | 1.2 - 1.4 | 2025-06-18 | >= 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.
† Agentgateway supports the MCP spec at the listed version.
‡ Istio versions: Istio must run on a compatible version of Kubernetes. For example, Istio 1.29 is tested, but not supported, on Kubernetes 1.30. 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
.0-rc.1,.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 were introduced in the experimental channel of the upstream Kubernetes Gateway API. The table distinguishes the minimum version listed for each feature from the version in which it became standard. Features that remain experimental are subject to change.
| Feature | Minimum Gateway API version | Standard channel since |
|---|---|---|
| ListenerSets | 1.3 | 1.5 |
| TCPRoutes | 1.3 | 1.6 |
| TLSRoutes | 0.3 | 1.5 |
| BackendTLSPolicy | 1.4 | 1.4 |
| CORS policies | 1.2 | 1.5 |
| Frontend client-certificate validation | 1.4 | 1.5 |
| Retries | 1.2 | Experimental |
| Session persistence | 1.3 | Experimental |
| HTTPRoute rule attachment option | 1.3 | 1.4 |
BackendTLSPolicy and named HTTPRoute rules became standard in Gateway API 1.4. ListenerSets, HTTPRoute CORS filters, TLSRoutes, and frontend client-certificate validation became standard in Gateway API 1.5. TCPRoutes and UDPRoutes became standard in Gateway API 1.6. These features do not require experimental CRDs at or after their standard-channel version.
Note
Experimental feature gate: Experimental Gateway API features in agentgateway are controlled by the AGW_ENABLE_EXPERIMENTAL_GATEWAY_API_FEATURES environment variable in your agentgateway controller deployment. This setting is enabled by default. To set it explicitly, or to turn experimental features off, include the following Helm value:
controller:
extraEnv:
AGW_ENABLE_EXPERIMENTAL_GATEWAY_API_FEATURES: "true"Sample command for version 1.6.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.6.0/experimental-install.yaml