> For the complete documentation index, see [llms.txt](https://developer.harness.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://developer.harness.io/continuous-delivery/troubleshooting-and-resources/toolchain-policy.md).
# Harness Integration Upgrade Policy
Harness integration upgrade cadence, support policy, and tooling version expectations
Harness updates Continuous Delivery (CD) integrations on a regular cadence so connectors, CLIs, and plugins stay aligned with upstream tools. This topic explains the update cycle, how Harness defines support for Kubernetes and other integrations, and how release notes communicate impact.
***
## What you will learn from this topic
* How [quarterly integration updates](#quarterly-integration-updates) relate to upstream tool release velocity
* How [testing and quality assurance](#testing-and-quality-assurance) apply before an integration update ships
* How to read the [tooling version matrix](#tooling-version-matrix) for connectors and plugins
* How Harness defines [Kubernetes version support](#kubernetes-maintenance-faq) for managed and self-managed clusters
* Where to find [release notes and impact assessment](#release-notes-and-impact-assessment) after an SDK, CLI, or integration update
***
## Quarterly integration updates
Harness updates its integrations on a quarterly basis. The schedule follows the release velocity of the integrated tools. Routine updates bring newer features and fixes into the Harness integration layer so your pipelines can use current upstream capabilities.
***
## Scope of tooling updates
Tooling updates apply across integrations, not only one product line. The goal is to keep supported integrations current with upstream releases that Harness has tested for the related deployment types.
***
## Testing and quality assurance
Harness tests integration updates against the corresponding and impacted deployment types to reduce functional regressions. Testing focuses on preserving existing deployment behavior for supported versions listed in the matrix.
***
## Tooling version matrix
The following table lists connector and integration versions from the prior published revision of this topic. Treat Supported Version as the Harness-supported baseline for planning, and confirm Latest Version against upstream release notes when you upgrade.
| Connector | Integration | Supported Version | Latest Version | Upgrade Cycle |
| ---------- | -------------------------------------------------------------------------------- | ----------------- | -------------- | ------------- |
| Kubernetes | Kubernetes | 1.27.4 | 1.30.3 | Quarterly |
| Helm | Helm | 3.8.x | 3.14.x | Quarterly |
| Tanzu | Tanzu | cf cli v7 | cf cli v8 | Quarterly |
| Terraform | Terraform | 1.3.5 | 1.9.4 | Quarterly |
| Terragrunt | Terragrunt | 0.40.x | 0.66.4 | Quarterly |
| Serverless | [Serverless.com plugin](https://hub.docker.com/r/harness/serverless-plugin/tags) | 3.x | 4.x | Quarterly |
| Jenkins | Jenkins Build Step | 2.440 | 2.471 | Quarterly |
| GitOps | Argo CD | 2.8.x | 2.12.x | Quarterly |
| AWS | [AWS SAM Plugin](https://hub.docker.com/r/harness/aws-sam-plugin/tags) | 1.84.0 | 1.121.0 | Quarterly |
***
## Kubernetes maintenance FAQ
The following questions describe how Harness supports Kubernetes versions for CD integrations.
What Kubernetes versions does Harness support, and how is support maintained?
Harness officially supports the current stable Kubernetes minor release and the two previous minor releases, aligned with common cloud-vendor support windows. For example, when `1.30` is the current stable minor in that window, support covers `1.30`, `1.29`, and `1.28`.
Kubernetes and Helm integrations receive quarterly maintenance, and can receive updates more often when upstream changes require it.
What about on-premises Kubernetes clusters that customers maintain themselves?
Versions outside the official support window are handled on a best-effort basis. That includes older minors such as `1.27`, `1.26`, down through `1.22`.
For clusters older than `1.22`, Harness aims to keep integrations backwards compatible where practical, but cannot guarantee behavior for every older Kubernetes release. Harness does not ship patches solely to keep unsupported Kubernetes versions working. The supported path is to upgrade the cluster.
Harness can surface installation or upgrade pre-flight checks during deployment that warn when the Kubernetes version is outside the support policy.
What does it mean to support a Kubernetes version?
Support means Harness does not intentionally introduce changes that break compatibility with the oldest minor still in the supported window. For example, Harness does not introduce a `v1.30`-only behavior if it breaks compatibility with `v1.28` while `v1.28` remains supported. When a newer minor enters the window and an older minor leaves it, compatibility with the dropped minor is no longer guaranteed.
If you run an unsupported Kubernetes version and hit a problem caused by incompatibility, upgrade the cluster. Harness does not issue a patch solely to support an older unsupported Kubernetes version.
***
## Integration FAQs
Does Harness use SDKs for the cloud vendors?
Yes. Harness uses the AWS SDK, Google Cloud SDK, and Azure SDK for the related deployment paths.
***
## Why routine updates matter
Keep the following outcomes in mind when you plan upgrades:
* **Capabilities:** Newer upstream releases expose features and fixes your pipelines can use after Harness validates the integration.
* **Security:** Older tool versions accumulate known vulnerabilities. Staying on supported integration versions reduces exposure from outdated CLIs and plugins.
* **Performance:** Upstream releases often include performance fixes that improve reliability of the integration path.
***
## Release notes and impact assessment
When Harness updates an SDK, CLI, or integration, release notes describe the changes, benefits, and potential impact on existing workflows. Review those notes before you roll the update through lower environments.
***
## Feedback
If an integration update causes unexpected behavior in your pipelines, contact [Harness Support](mailto:support@harness.io) with the integration name, versions involved, and the deployment type.
***
## Next steps
* [CD and GitOps tutorials](/continuous-delivery/troubleshooting-and-resources/tutorials/cd-gitops-tutorials.md): Validate deployments after an integration upgrade.
* [CD FAQs](/continuous-delivery/troubleshooting-and-resources/faqs.md): Review related Continuous Delivery questions.
* [Harness Support](mailto:support@harness.io): Report integration regressions or request clarification on support windows.
{% @harness-feedback/feedback %}