Version support

Review the following information about supported release versions for the agentgateway project.

Supported versions

agentgatewayRelease dateKubernetesGateway API*HelmIstio
1.0.x16 Mar 20261.31 - 1.351.5.x>= 3.121.23 - 1.29
2.2.x09 Feb 20261.31 - 1.351.4.x>= 3.121.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:

  1. New feature development is suspended on main.
  2. Release candidates are created, such as 1.0.0-rc.1, 1.0.0-rc.2, and so on.
  3. 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.
  4. Documentation for that release is prepared, vetted, and staged.
  5. The stable minor version is released as part of a tag, such as v1.0.0.
  6. Feature development on main is 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.

FeatureMinimum Gateway API version
ListenerSets*1.3
TCPRoutes1.3
TLSRoutes*0.3
BackendTLSPolicy1.4
CORS policies*1.2
Retries1.2
Session persistence1.3
HTTPRoute rule attachment option1.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

Agentgateway assistant

Ask me anything about agentgateway configuration, features, or usage.

Note: AI-generated content might contain errors; please verify and test all returned information.

Tip: one topic per conversation gives the best results. Use the + button in the chat header to start a new conversation.

Switching topics? Starting a new conversation improves accuracy.
↑↓ navigate select esc dismiss

What could be improved?

Your feedback helps us improve assistant answers and identify docs gaps we should fix.

Need more help? Join us on Discord: https://discord.gg/y9efgEmppm

Want to use your own agent? Add the Solo MCP server to query our docs directly. Get started here: https://search.solo.io/.