Long Term Support Release

Welcome to Tyk’s Long Term Support (LTS) Releases section. Here, we’ll walk you through the practical aspects of how LTS benefits your business. Explore our approach to stability, understand semantic versioning and learn about our compatibility policies. We’ll also cover support for non-LTS components and provide links on upgrading and staying informed about new LTS releases.

​

What Makes Long-Term Support (LTS) So Valuable to Our Customers?

Long Term Support describes a release of our Gateway and Dashboard which offers our customers, stability over a 1-2 year period. It also means we are committed to ensuring you have uninterrupted service for the lifetime of the long term release. There are many customer benefits in keeping pace with our long term release:

1. Stability: Tyk will always strive to avoid issuing its latest release as a long term support release. Instead, we prefer to let the release be proven in a production setting before it becomes LTS so we can iron out any rare issues.
2. Security: Tyk commits that the latest LTS will be secure at the point of release by containing the latest available Go version. This ensures Go related security issues are minimized.
3. Functional Richness: There will always be great capability contained in out latest LTS which moves your game on in terms of workflows.
4. Continuation of Service: We will patch the LTS version every 7 weeks for the period it remains in full support.

In summary, LTS releases are stable minor or patch releases that are suitable for production use.

---

​

What Is Our LTS Offering?

We provide full support for the first 12 months, including regular maintenance intervals every eight weeks. Following this period, we transition to maintenance support for an additional 12 months, focusing on critical fixes and essential security patching as needed. We release a new Gateway LTS version every 12 months, which includes the latest stable Golang version.

​

Advantages of a 12-Month Long-Term Support (LTS) Cycle

1. It allows us to keep pace with Golang versions and other key dependency upgrades, which keeps both our customers and your customers safe (low CVE).
2. It allows us to bring you the best capability whilst offering stability.
3. It allows us to get great product insight and use that to improve the product.

In case there’s a need to operate on a version beyond the established LTS policy, potential assistance may be available. However, this requires a discussion with your designated Account Manager.

​

Support Definitions

Full Support

During the full support period, we patch the LTS branch on a regular eight-week cadence. These patches may include any of the following:

• Security updates
• Bug fixes
• UX and UI improvements
• Any other necessary changes, regardless of severity level.

Maintenance Support

After the initial 12 months of full support, Tyk will release a new LTS version. This means that the previous LTS version now enters maintenance support. In maintenance support, we do not offer regular planned patching. Instead, we will only fix bugs and security issues deemed critical, and this will be a reactive process based on need. If your internal upgrade processes are heavily governed, this may be something you want to take advantage of If we find something critical we will react immediately and invoke our critical fix process. Generally critical fixes are expressed as a system down with no workaround, or an urgent security issue.

​

Current LTS releases Timeline

---

​

What About Non-LTS Gateway Releases?

While these releases are fully supported, their support window is limited. A non-LTS minor version reaches its End-of-Life (EOL) as soon as the next minor version is released. For example:

• Tyk v5.1.x is fully supported until v5.2.0 is released.
• Once v5.2.0 is available, v5.1.x is considered End-of-Life and will no longer receive patches or security fixes.

For users who require a longer support window and predictable patching, we strongly recommend using our LTS releases.

---

​

Major / Minor / Patch - How Do We Decide?

We know that an LTS release that has a major semantic version is not a desirable practice. So, we will always endeavor to avoid shipping major versions, especially major versions as LTS releases. However, sometimes it is unavoidable and we have to ship a major version. Our first commitment to you is to make our definitions of major / minor / patch are transparent:

​

Major Version

The major version is designated as X.0 and is defined by one or more of the following:

1. Breaking changes to Tyk APIs, including Tyk Gateway API, Tyk Dashboard API, MDCB, Tyk EDP, and any other component that exposes APIs. Changes include not just the endpoints, but also behavior and functionality, schemas, input parameters, return error codes, and messages. The APIs are documented and published as an OpenAPI Spec document. In case we need to introduce breaking changes, we will create a new version of the API. However, currently, none of Tyk APIs are versioned.
2. Breaking changes to Tyk custom plugins interfaces, breaking plugin compiler for customer Go plugins after plugins have been recompiled.
3. Breaking changes in the config files in all Tyk components, fields in the config files, environment variables used by Tyk components, APIs (function calls) of Tyk middleware, Go template interface.
4. Deprecation of existing functionalities or engines that break a key business process.
5. Crypto deprecations.
6. Changes to common names in certificates.

In summary, breaking changes involves anything with which a user interacts with a Tyk product and might have to make changes to maintain functionality in response to a change we implement. Subsequently, breaking changes are introduced in a major version, in accordance with the Semantic Versioning specification.

​

Minor Version

According to the Semantic Versioning specification, a MINOR version is incremented when you add functionality in a backward compatible manner. In other words, if Tyk makes changes to your software that do not break any existing functionality, you can increment the MINOR version number. For example, if you add new features or capabilities to your software without changing any existing functionality, you can increase the MINOR version number.

​

Patch Version

A patch, sometimes just called a fix, is a small piece of code that’s used to correct a problem, usually called a bug, with an operating system or software program. Patches are software and Operating System (OS) updates that address security vulnerabilities within a program or product. Tyk may choose to release updates to fix performance bugs, as well as to provide enhanced security features.

---

​

Compatibility

Tyk has a few different components that can drive questions on what version of X goes with what version of Y. When we release a new Gateway version, it triggers us to be clear on version compatibility with other areas of the Tyk stack. As part of the release of the new Gateway LTS version we will commit to showing everyone two compatibility dimensions:

1. Recommended releases - To ensure you get the most out of the latest Tyk experience, we’ll provide information on which versions of different components across the entire stack you need.
2. Backwards Compatibility - We’ll provide information on what components and versions remain backward compatible with the new Tyk Dashboard and Tyk Gateway versions.

Our next LTS version will be announced in April 2026.

---

​

Available Gateway Versions on Cloud

To ensure a consistent and high-quality user experience, we have updated the way Gateway (GW) versions are displayed and supported in the Cloud console. This aligns with our Long-Term Support (LTS) policy and aims to encourage users to stay current with supported versions while reducing operational overhead for our team. Version Availability in the Cloud Console When selecting the “Latest” option, users can only choose the latest feature branch (Gateway Release Notes). When selecting the “LTS” option, users will be able to choose from the following:

• Current LTS version (e.g., 5.8.x): Full support provided, with the latest patch marked as Recommended.
• Extended Support (e.g., 5.3.x): Maintenance support only.

Older versions (e.g., 5.2.x and below) are marked as “Unsupported” and will be greyed out. Implications for Unsupported Versions Users with deployments on unsupported versions (e.g., 5.2.x) will see a notice informing them that their version is “Unsupported”. Unsupported versions are not eligible for bug fixes or feature updates. Users encountering issues will be advised to upgrade to a supported version. While Tyk Cloud deployments may remain on unsupported versions without a specific upgrade timeline, we may automatically upgrade such deployments in case internal reasons (e.g., infrastructure dependencies, security, or performance risks) require such an action. In this case, Tyk will communicate a timeline for upgrading in advance. Upgrade Recommendations Users running deployments on a supported but non-latest version within a branch (e.g., 5.3.2) will see a notice encouraging an upgrade to the “Recommended” version (e.g., 5.3.11). This ensures users benefit from the latest security patches and improvements within the supported branch.

---

​

How Do I Upgrade and How Can Tyk Help?

We have step-by-step install guides for various architectures and installation types. Refer to upgrading tyk for further details. And don’t forget, our brilliant Customer Success Teams and Account Managers are here to assist you with any issues - pleases refer to your SLA on the specifics of how we can help!

---

​

Keep Me Informed!

We release a new LTS version every 12 months. If you want to be alerted about our next LTS release and what capabilities will be released within it, please sign up to our mailing list. We will release our preliminary communications a month before the new LTS version gets released.

---

​

Support Arrangements for Other Tyk Components

We have established a detailed LTS structure for Tyk Gateway and Tyk Dashboard due to their foundational role in our customers’ infrastructure. However, our support strategy for Tyk Pump, Tyk Identity Broker (TIB), MDCB, and Tyk Operator is tailored to reflect their distinct operational aspects and risk profiles, and is deeply integrated with our LTS model. These components are often more standalone in nature and are subject to infrequent and minor changes compared to the core products. Therefore, aligning them with the same LTS versioning isn’t necessary or practical. Instead, we employ a continuous delivery model that ensures these components are always updated with the latest improvements and security patches. Our commitment extends beyond version numbers, as we ensure each of these components is thoroughly tested for quality assurance with all active LTS releases of the Gateway and Dashboard. Ultimately, our diversified support approach aims to balance agility with assurance, offering the most appropriate level of support for each component while minimizing risk and maximizing value for our customers. To provide the most secure and efficient environment, we advise the following with the release of a new LTS version:

​

Developer Portal

Continually evolves with frequent updates. We recommend adopting the latest release for optimal performance and feature set, ensuring consistent user experience and accessibility to the newest enhancements.

​

MDCB and Helm

Receive updates synchronized with the core Gateway and Dashboard to support new features and capabilities. These components are mature and updates typically consist of minor iterations.

​

Pump, TIB, Sync and Operator

We recommend staying up to date with these components because they are rigorously tested to operate smoothly with the active LTS versions of Tyk Gateway and Tyk Dashboard. With new releases of Tyk Gateway and Tyk Dashboard LTS versions, our customers should follow the above guidelines to ensure the most secure, stable and efficient environment.