Skip to main content
Open Source (Mozilla Public License) This page contains all release notes for Tyk Gateway displayed in reverse chronological order

​
Support Lifetime

Only the most recent Tyk Gateway release and the most recent on the Long Term Support (LTS) branch are supported. We recommend staying current on the feature or LTS branch to minimise exposure to security vulnerabilities from third party dependencies.

​
5.14 Release Notes

​
5.14.0 Release Notes

​
Release Date 7 July 2026

​
Release Highlights

OAuth 2.0 authentication with external Authorization Server Tyk Gateway introduces a first-class OAuth 2.0 authentication method for Tyk OAS APIs, enabling token validation against an external Identity Provider such as Keycloak, Okta, or Auth0 that acts as the Authorization Server. Tyk acts as the OAuth 2.0 protected resource, validating inbound bearer tokens against the IdP’s JWKS endpoint. It performs enforcement only and does not issue tokens. The new method supports scope enforcement at API, per-operation, and per-MCP-primitive granularity, giving you fine-grained access control over individual endpoints and tools without additional middleware. It is natively expressed through the standard oauth2 security scheme in the Tyk OAS API definition, and replaces the deprecated External OAuth method, which performed only limited token validation. This is also the foundation for Protected Resource Metadata and RFC 8693 Token Exchange, described below. RFC 8693 Token Exchange for Upstream Authentication (Enterprise Edition) When the inbound client token should not reach your upstream service, for example when an AI agent’s SSO token needs to be replaced with a service-specific token carrying the correct audience and scopes, Tyk Gateway can perform an RFC 8693 token exchange transparently before forwarding the request. The original token is consumed at the Gateway; the upstream sees only the exchanged token. Token exchange is configured within the oauth2 scheme and supports multiple named providers. Per-operation and per-MCP-primitive overrides allow a different audience and scope set for individual endpoints and tools. Exchanged tokens are cached to avoid a round-trip on every request, with a configurable safety margin to ensure upstream services always receive a valid token. MCP Capability Discovery Aligned with Access Control When an AI agent connects to an MCP proxy, it begins by discovering what tools, resources, and prompts are available. Previously, Tyk enforced allow and block rules only at invocation time: agents would discover capabilities they were not permitted to use and only encounter the restriction when they attempted to call them. The MCP proxy now filters the tool, resource, and prompt lists returned during capability discovery (tools/list, resources/list, prompts/list) and the initialize handshake using the same OAS-level rules. Agents see only what they are permitted to invoke, producing a cleaner agent experience and reducing unnecessary round-trips to Tyk Gateway. Simplified Secrets and Certificate Management for Kubernetes Deployments Local filesystem has been added to the supported storage options for Key Value secret storage, using the file:// and $secret_file. schema. This allows Tyk Gateway to resolve KV and secret references from the contents of a local file, such as a Kubernetes Secret mounted on the Data Plane pod, without relying on third-party systems or environment variables. Building on this, API definitions can now reference a PEM-encoded certificate stored directly in a Key-Value store from any TLS certificate field. Rotating a certificate is then a matter of updating the value in the secret store and triggering a hot reload. No change to the API definition is required. Other Changes This release also delivers: granular enforced timeouts configurable in milliseconds, seconds, or minutes at both API and endpoint level; the original client request path recorded in OpenTelemetry spans, traffic logs, and access logs before any path stripping or rewriting; a configurable graceful shutdown delay to prevent HTTP 502 errors during scale-down in high-traffic Kubernetes deployments; a Client IdP registry for centralized JWT Identity Provider management (Enterprise Edition); and standardized application log format aligned with other Tyk components - see Breaking Changes if your log parsing tools depend on the previous format. Notable fixes include: a Gateway crash under high authentication load; unbounded memory growth with CoProcess plugins and large sessions; and GraphQL API authentication headers not being forwarded upstream. For a comprehensive list of changes, please refer to the detailed changelog below.

​
Breaking Changes

Changes to application logs This release makes changes to the format of Tyk Gateway application logs so that output is consistent with other Tyk components and aligned with industry observability standards.
This is only a breaking change if you specifically rely on the current log format: for example, if your monitoring, parsing, or alerting tools are built around the existing timestamp format or the entire message.
Mitigation: A new legacy option has been added to the log_format configuration. This setting preserves the format used in Tyk Gateway 5.13.0 and earlier, with the historical timestamp format and lack of a field identifying the originating API. The default value is text.

​
Dependencies

Compatibility Matrix For Tyk Components
3rd Party Dependencies & Tools
Given the potential time difference between your upgrade and the release of this version, we recommend users verify the ongoing support of third-party dependencies they install, as their status may have changed since the release.

​
Deprecations

Per-endpoint Enforced Timeout Configuration The introduction of granular per-endpoint enforced (request) timeouts means that the existing controls (value for Tyk OAS and timeout for Tyk Classic) should now be considered as deprecated. For Tyk OAS APIs, the Gateway will automatically round this duration up to the nearest whole second and store that value in the original value field so that a timeout will continue to be enforced if that API is deployed to an older Gateway. This rounding up is not performed automatically for Tyk Classic APIs - the user must set extended_paths.hard_timeouts.timeout to ensure the timeout is enforced on older Gateways.

​
Upgrade instructions

If you are upgrading to 5.14.0, please follow the detailed upgrade instructions.

​
Downloads

Tyk Helm Charts are configured to install the LTS version of Tyk Gateway. You will need to modify them to install v5.14.0.

​
Changelog

Added
A new OAuth 2.0 authentication method is available for Tyk OAS APIs, enabling authentication against an external Identity Provider (IdP) such as Keycloak, Okta, or Auth0 that acts as the OAuth 2.0 Authorization Server. Tyk acts as the OAuth 2.0 protected resource, validating inbound bearer tokens against the IdP’s JWKS endpoint.
This is distinct from Tyk OAuth 2.0, in which Tyk acts as the OAuth 2.0 Authorization Server and issues tokens to clients.It replaces and significantly improves upon the deprecated External OAuth method, which performed limited validation of tokens provided by an external IdP.
The OAuth 2.0 authentication method supports scope enforcement at the API, per-operation and per-MCP-primitive levels. This requires that inbound tokens carry specific OAuth scopes for fine-grained access control over individual endpoints and tools.The new auth method is natively integrated with the Tyk OAS API definition using the oauth2 security scheme and is the foundation for scope enforcement, Protected Resource Metadata, and RFC 8693 Token Exchange.
Protected Resource Metadata (PRM) configuration has moved from the top-level authentication.protectedResourceMetadata block into the oauth2 scheme, under authentication.securitySchemes[name].oauth2.protectedResourceMetadata. This aligns PRM with the scheme it describes and allows each oauth2 scheme to carry its own discovery configuration.A new autoDeriveScopes option automatically populates the PRM scopes_supported list from the API’s OAS security: declarations, keeping the discovery document in sync with the API definition without manual maintenance.
Enterprise Edition only
Tyk Gateway supports RFC 8693 token exchange for upstream authentication. When configured, the Gateway exchanges the inbound client token for a new token issued by your identity provider before forwarding the request upstream; the original token never reaches the upstream service. This is particularly valuable for MCP flows where an AI agent’s SSO token must be replaced with a service-specific token carrying the correct audience and scopes for the backend.Token exchange is configured within the oauth2 scheme and supports multiple named providers, each with its own token endpoint, client credentials, and default target audience. Per-operation and per-MCP-primitive overrides allow a different audience and scope set for individual endpoints and tools.Exchanged tokens are cached using one of two models to avoid a round-trip to the identity provider on every request. A configurable safety margin causes tokens to be refreshed before they expire, ensuring upstream services always receive a valid token.
Local filesystem has been added to the supported storage options for Key Value secret storage, using the file://<key> and $secret_file.<key> schema. This allows Gateway to resolve KV/secret references from the contents of a local file - such as Kubernetes Secrets mounted on the Data Plane pod.The base path for all external file references must be configured in the Tyk Gateway config as kv.file.base_path. This acts as an enable/disable control for external file references.Secrets and other environment specific values can be stored local to the Data Plane without the use of third party systems or environment variables. Trailing newlines are stripped by default and multi-line content is preserved. Secret rotations are picked up on API reload.
API definitions can now carry a PEM-encoded certificate as a string stored directly in any of the TLS certificate fields:
  • client certificates (server.clientCertificates.allowlist)
  • client CA certificates (server.clientCertificates.clientCaCertificates)
  • custom domain certificates (server.customDomain.certificates)
  • upstream client certificates (upstream.mutualTLS.domainToCertificateMapping.certificate)
  • upstream CA certificates (upstream.tlsTransport.sslCertificates)
Whilst including the certificate in the API definition is not a recommended approach, this allows the PEM-encoded certificate to be stored directly in a Key-Value store and resolved into the API definition using the existing KV reference system, keeping private key material out of the Control Plane. Changing the certificate stored as a “value” will ensure that Tyk automatically rotates to the new certificate when the API is reloaded.This is an alternative to the existing options of referencing a Tyk Certificate Store ID or a path to the certificate file on the local filesystem. Existing API definitions that reference certificates by ID or file path continue to work unchanged.
You can now configure more granular enforced (request) timeouts using human-readable values such as 500ms, 1.5s, or 2m.Configure the per-endpoint timeout in the Tyk Vendor Extension using the new duration field in the per-operation enforceTimeout object. This accepts human-readable durations in milliseconds, seconds, or minutes (for example 500ms, 1.5s, or 2m).If using Tyk Classic APIs, the equivalent field name is extended_paths.hard_timeouts.duration.The existing fields with a per-second granularity (value for Tyk OAS and timeout for Tyk Classic) should now be considered as deprecated, but remain fully compatible so existing API definitions continue to work unchanged.In a distributed (MDCB) deployment, the Control Plane will automatically round this duration up to the nearest whole second and store that value in the original value field so that a timeout will continue to be enforced if that API is deployed to an older Data Plane Gateway. This does not happen for Tyk Classic APIs, so you must remember to set the legacy field manually for the timeout to be enforced automatically on an older Data Plane Gateway.
You can now configure an enforced (request) timeout at API level. This API-level timeout takes precedence over the Gateway default (proxy_default_timeout). The more granular endpoint-level timeout overrides the API-level value.Configure the timeout in the Tyk Vendor Extension using upstream.enforceTimeout using human-readable durations in milliseconds, seconds, or minutes (for example 500ms, 1.5s, or 2m).If using Tyk Classic APIs, the equivalent control is global_enforce_timeout in the version_data section.
We have made changes to the format of Tyk Gateway application logs to make them consistent with logs generated by other Tyk components and aligned with industry observability standards.
  • RFC3339 timestamps: Log entries now consistently use the industry-standard RFC3339 timestamp format (e.g. 2024-12-12T13:59:08Z), previously a mix of timestamp formats was used.
  • Log message field renamed: The log message field is renamed from msg to message, for consistency with other Tyk components.
  • Track 404 target: A host field has been added to log entries for requests that generate HTTP 404 errors. This records the Host header from the request, allowing users to distinguish whether the unmatched request was directed at the proxy API or the control API (if they are configured on different ports)
ConfigurationThe log_format configuration option now accepts three explicit values:
  • text: plain-text logs in the new format introduced in this release (new default).
  • json: JSON logs in the new format.
  • legacy: preserves the format used in Gateway 5.13.0 and earlier, with the historical timestamp format and the msg field name.
This is a breaking change for any user whose monitoring or log-parsing tools rely on the specific format of the Tyk Gateway application logs. If you require the previous timestamp format, the msg field name, or no host for HTTP 404 logs, you should set log_format to legacy.
The Gateway now records the original client request path, captured before any path stripping or URL rewriting, in logs. This allows you to tell which client-facing endpoint was called even when the request is transformed before reaching the upstream.
  • The full path requested by the client is recorded as original_path in:
    • OpenTelemetry span
    • traffic logs
    • access logs
  • The API listen path that was matched and indicates which API proxy was triggered is also now recorded in traffic logs, as listen_path.
  • The existing path field is unchanged and continues to show the path sent to the upstream.
The Gateway can now wait for a configurable period after receiving a shutdown signal before it stops accepting new connections, giving load balancers and orchestrators time to detect that the node is no longer ready and remove it from the pool. This prevents the HTTP 502 errors that could otherwise occur during scale-down in high-traffic deployments.A new graceful_shutdown_delay_seconds configuration option controls the wait (default: 0 seconds). As soon as a SIGTERM, SIGINT, or SIGQUIT is received, the readiness endpoint (/ready) immediately begins to return 503 Service Unavailable, but the Gateway keeps accepting and serving traffic for the configured delay period.Following the delay period, the existing graceful shutdown process continues.
Enterprise Edition only
Tyk Gateway’s authentication middleware provides support for JSON Web Token (JWT) signature validation against JSON Web Key Sets (JWKS) stored locally in the API definition or, more commonly, retrieved from the dedicated JWKS endpoint of a 3rd party Identity Provider (IdP) (the issuer of the token). Following signature validation, the claims within the JWT can be interrogated to identify scopes which are then used to identify the Policies that should be applied to the Session generated for the request. This scope-to-policy mapping is traditionally stored in the API definition.The new Client IdP registry extracts the IdP details (issuer value and JWKS endpoint) and the scope-to-policy mapping from the API definitions into a new registry that maps the IdP metadata against the API(s). When a request is received, the Gateway will first check any JWKS URLs and scope-to-policy mappings in the API definition (for backward compatibility) before checking the registry.This separation allows simpler and cleaner management of Identity Providers - modifying the metadata in the registry will automatically update the behavior of APIs without making any change to the API definitions themselves.The IdP registry exists as an in-memory table that is managed by the Tyk Dashboard.
The MCP proxy now filters the tool, resource, and prompt lists returned during capability discovery (tools/list, resources/list, prompts/list) and the initialize capability handshake using OAS-level allow and block rules configured in the MCP OAS definition.Previously, these rules were enforced at invocation time only: discovery responses passed through unfiltered from the upstream server, so agents would discover capabilities they could not use and only encounter the restriction when they tried to call them. Agents now see only the tools, resources, and prompts they are permitted to invoke.
Fixed
Docker images published in v5.13.0 contained mixed layer compression: base image layers used zstd compression while Tyk application layers used gzip. This caused image copy and promotion failures with legacy Docker tooling, older registry versions, and some security scanners, with the error: zstd compression is not officially supported for docker images.All image layers are now uniformly compressed using gzip, restoring compatibility with skopeo, oc image mirror, and other tools that do not support OCI zstd compression.
When the Gateway control API is moved to a separate port via control_api_port, requests to the proxy/data API port that did not match any configured API (generating an HTTP 404 response) were silently dropped: no log entry was generated even with track_404_logs enabled. This has been fixed; 404 logs are now correctly emitted for unmatched requests on all listening ports.
We have resolved a risk of unbound memory consumption for APIs using gRPC plugins. The leak was due to an internal regular-expression cache that could grow without limit when Session access rights contained per-user URL patterns, and excessive memory churn when copying large sessions on every request. The fix bounds the maximum size of the cache and reuses Session objects to eliminate the churn. The Gateway now also aligns GOMAXPROCS with the container’s CPU quota at startup.This fix introduces the following new configuration options:
Under sustained high-concurrency traffic to OIDC, JWT, or Auth-key protected APIs - particularly when the local session cache was disabled - the Gateway could crash with a fatal concurrent map iteration and map write panic. This caused unexpected pod restarts, in-flight request loss, and intermittent cluster instability.This has been fixed. The temporary workaround of enabling the local session cache (disable_cached_session_state: false) is no longer required.
The Gateway’s min_token_length configuration is intended to prevent the use of API tokens (keys) that are insecure due to their length. All tokens presented during a request to an API are checked against this value and immediately rejected with HTTP 403 if shorter than the configured minimum length.Previously, a token with length equal to min_token_length would be rejected with HTTP 403, which is non-intuitive and can lead to wasted debugging time.Also, it was possible to create a custom key shorter than the configured minimum length. The Session would be created, but the key would be unusable as any attempt to use it in a request would be rejected due to the token’s length.Now, tokens with length exactly equal to min_token_length are correctly accepted and an attempt to create a custom key shorter than min_token_length fails immediately with a 400 Bad Request.
We have resolved an issue where, when a GraphQL API was configured with strip_auth_data set to false, the client’s authentication header (for example Authorization, or a custom header such as X-API-KEY) was not forwarded to the upstream service. This affected all GraphQL execution modes (proxy-only (including WebSocket subscriptions), subgraph, Universal Data Graph, and supergraph) leaving upstream services that require the header unable to authenticate the request.The active authentication method’s header is now propagated upstream across all execution modes, with only the active method’s header forwarded. In addition, upstream WebSocket connections for subscriptions are no longer reused across clients presenting different credentials, so each subscription carries its own authentication header, and one client’s token can no longer leak to another. When strip_auth_data is true, no authentication headers are forwarded, as before.
When an AI agent made a request through a Tyk MCP proxy, Tyk’s spans, access logs, and analytics records were disconnected from the agent’s distributed trace. This was because AI agents using MCP pass their trace context inside the JSON-RPC message body (params._meta) rather than the HTTP header - Tyk was only looking at the HTTP header, so it missed the agent’s trace ID and started a fresh one.This made it impossible to correlate what Tyk did with the agent’s journey using a single trace ID, forcing operators to reconstruct Tyk’s role manually from timestamps rather than following one trace end-to-end.
Tyk 5.8.14 introduced a change in the behavior of the health endpoints when Tyk Gateway is deployed in the Control Plane. If Redis goes down and the Tyk Dashboard is still available, the Gateway’s health endpoints can incorrectly report that everything is healthy.The Gateway regularly polls for the availability of Dashboard and Redis, caching the status and reporting this when the health endpoints are called. The cache is only updated once both checks are complete and, as a side effect of the fix applied in 5.8.14 to address an issue with the Gateway registration with Dashboard, it was possible for the checks to loop infinitely until Redis was available, such that the cached status was never updated with a “Redis down” message.The Control Plane Gateway’s health endpoints now correctly report the most recent snapshot of Dashboard and Redis availability.
Security Fixes

​
5.13 Release Notes

​
5.13.1 Release Notes

​
Release Date 2 July 2026

​
Release Highlights

This patch implements several changes and fixes to improve the stability and correct the behavior of the Gateway. The default content of application logs has been updated with RFC3339 format timestamp and consistent formatting with other components. This could be a breaking change for any user whose tooling relies on the specific content of application logs. A legacy mode is available, as described below. For a comprehensive list of changes, please refer to the detailed changelog below.

​
Breaking Changes

Changes to application logs This release makes changes to the format of Tyk Gateway application logs so that output is consistent with other Tyk components and aligned with industry observability standards.
This is only a breaking change if you specifically rely on the current log format: for example, if your monitoring, parsing, or alerting tools are built around the existing timestamp format or the entire message.
Mitigation: A new legacy option has been added to the log_format configuration. This setting preserves the format used in Tyk Gateway 5.13.0 and earlier, with the historical timestamp format and lack of a field identifying for the originating API.

​
Dependencies

Compatibility Matrix For Tyk Components
3rd Party Dependencies & Tools
Given the potential time difference between your upgrade and the release of this version, we recommend users verify the ongoing support of third-party dependencies they install, as their status may have changed since the release.

​
Deprecations

There are no deprecations in this release.

​
Upgrade instructions

If you are upgrading to 5.13.1, please follow the detailed upgrade instructions.

​
Downloads

​
Changelog

Fixed
Docker images published in v5.13.0 contained mixed layer compression — base image layers used zstd compression while Tyk application layers used gzip. This caused image copy and promotion failures with legacy Docker tooling, older registry versions, and some security scanners, with the error: zstd compression is not officially supported for docker images.All image layers are now uniformly compressed using gzip, restoring compatibility with skopeo, oc image mirror, and other tools that do not support OCI zstd compression.
We have made changes to the format of Tyk Gateway application logs to make them consistent with logs generated by other Tyk components and aligned with industry observability standards.
  • RFC3339 timestamps: Log entries now consistently use the industry-standard RFC3339 timestamp format (e.g. 2024-12-12T13:59:08Z), previously a mix of timestamp formats was used.
ConfigurationThe log_format configuration option now accepts three explicit values:
  • text: plain-text logs in the new format introduced in this release (new default).
  • json: JSON logs in the new format.
  • legacy: preserves the format used in Gateway 5.13.0 and earlier, with the historical timestamp format.
This is a breaking change for any user whose monitoring or log-parsing tools rely on the specific format of the Tyk Gateway application logs. If you require the previous timestamp format, you should set log_format to legacy.
When an AI agent made a request through a Tyk MCP proxy, Tyk’s spans, access logs, and analytics records were disconnected from the agent’s distributed trace. This was because AI agents using MCP pass their trace context inside the JSON-RPC message body (params._meta) rather than the HTTP header - Tyk was only looking at the HTTP header, so it missed the agent’s trace ID and started a fresh one. This made it impossible to correlate what Tyk did with the agent’s journey using a single trace ID, forcing operators to reconstruct Tyk’s role manually from timestamps rather than following one trace end-to-end.
When the Gateway control API is moved to a separate port via control_api_port, requests to the proxy/data API port that did not match any configured API (generating an HTTP 404 response) were silently dropped: no log entry was generated even with track_404_logs enabled. This has been fixed; 404 logs are now correctly emitted for unmatched requests on all listening ports.Additionally, a host field has been added to 404 log entries (when using text or json log_format). This records the Host header from the request, allowing users to distinguish whether the unmatched request was directed at the proxy API or the control API.
Resolved a risk of unbound memory consumption for APIs using gRPC plugins. The leak was due to an internal regular-expression cache that could grow without limit when Session access rights contained per-user URL patterns, and excessive memory churn when copying large sessions on every request. The fix bounds the maximum size of the cache and reuses Session objects to eliminate the churn. The Gateway now also aligns GOMAXPROCS with the container’s CPU quota at startup.This fix introduces the following new configuration options:
Under sustained high-concurrency traffic to OIDC, JWT, or Auth-key protected APIs - particularly when the local session cache was disabled - the Gateway could crash with a fatal concurrent map iteration and map write panic. This caused unexpected pod restarts, in-flight request loss, and intermittent cluster instability.This has been fixed. The temporary workaround of enabling the local session cache (disable_cached_session_state: false) is no longer required.
The Gateway’s min_token_length configuration is intended to prevent the use of API tokens (keys) that are insecure due to their length. All tokens presented during a request to an API are checked against this value and immediately rejected with HTTP 403 if shorter than the configured minimum length.Previously, a token with length equal to min_token_length would be rejected with HTTP 403, which is non-intuitive and can lead to wasted debugging time.Also, it was possible to create a custom key shorter than the configured minimum length. The Session would be created, but the key would be unusable as any attempt to use it in a request would be rejected due to the token’s length.Now, tokens with length exactly equal to min_token_length are correctly accepted and an attempt to create a custom key shorter than min_token_length fails immediately with a 400 Bad Request.
Resolved an issue where, when a GraphQL API was configured with strip_auth_data set to false, the client’s authentication header (for example Authorization, or a custom header such as X-API-KEY) was not forwarded to the upstream service. This affected all GraphQL execution modes (proxy-only (including WebSocket subscriptions), subgraph, Universal Data Graph, and supergraph) leaving upstream services that require the header unable to authenticate the request.The active authentication method’s header is now propagated upstream across all execution modes, with only the active method’s header forwarded. In addition, upstream WebSocket connections for subscriptions are no longer reused across clients presenting different credentials, so each subscription carries its own authentication header, and one client’s token can no longer leak to another. When strip_auth_data is true, no authentication headers are forwarded, as before.
Tyk 5.8.14 introduced a change in the behavior of the health endpoints when Tyk Gateway is deployed in the Control Plane. If Redis goes down and the Tyk Dashboard is still available, the Gateway’s health endpoints can incorrectly report that everything is healthy.The Gateway regularly polls for the availability of Dashboard and Redis, caching the status and reporting this when the health endpoints are called. The cache is only updated once both checks are complete and, as a side effect of the fix applied in 5.8.14 to address an issue with the Gateway registration with Dashboard, it was possible for the checks to loop infinitely until Redis was available, such that the cached status was never updated with a “Redis down” message.The Control Plane Gateway’s health endpoints now correctly report the most recent snapshot of Dashboard and Redis availability.
Security Fixes

​
5.13.0 Release Notes

​
Release Date 19 May 2026

​
Release Highlights

Tyk 5.13.0 introduces MCP (Model Context Protocol) Gateway support, bringing AI agent tool servers into Tyk’s API management platform. This release also completes Tyk’s observability stack with full OpenTelemetry metrics export, and delivers a comprehensive API error response customization system. Gateway support for MCP We have introduced the MCP (Model Context Protocol) Gateway, enabling teams to proxy, secure, and manage AI agent tool servers within Tyk API management. The MCP Gateway is not a new component - the capabilities are generally available in this release of Tyk Gateway. MCP Proxies support Server-Sent Events (SSE) streaming, enabling long-lived agent sessions that survive beyond the configured write timeout. A configurable idle timeout terminates stale SSE streams cleanly, and the Gateway sends a structured error event to the client when an upstream connection drops unexpectedly. Tool-Based Access Control (TBAC) enforces fine-grained access rules at two levels: JSON-RPC method level (e.g., tools/call, resources/read) and MCP primitive level (individual tool, resource, or prompt by name). Per-primitive rate limiting sets independent rate limits for each method or named primitive within a Session or Policy. When multiple Policies apply, access lists merge as a union and rate limits use the most permissive value. MCP traffic appears in Gateway access logs with dedicated fields (mcp_method, mcp_primitive_type, mcp_primitive_name) alongside a new api_type field present on all access log entries. OpenTelemetry custom metrics expose the same four MCP dimensions, including mcp_error_code, aligned with the OpenTelemetry mcp.* semantic conventions. Complete Observability with OpenTelemetry Metrics We have introduced comprehensive real-time metrics export through OpenTelemetry, completing Tyk’s observability stack alongside existing distributed tracing and logging. Teams have complete operational visibility with automatic RED metrics (Rate, Errors, Duration), Go runtime health monitoring, and configuration state tracking. The new custom metrics framework enables multi-tenant billing, tier-based SLOs, and business KPI tracking through configurable dimensions sourced from request headers, JWT claims, session data, and API metadata. Built-in cardinality controls and metric-to-trace correlation through exemplars ensure production-ready performance while enabling seamless navigation from metric anomalies to specific traces during incident investigation. Fully Customizable API Error Responses Transform your API’s error experience with the new comprehensive error override system. This feature provides complete control over HTTP error responses from both the Gateway and upstream services, enabling standardized, branded error formats that guide users toward solutions rather than leaving them confused. Configure error overrides at multiple levels - globally and per API - with flexible matching by status codes, error types, message patterns, or response content. Support for dynamic templates with validation context enables RFC 7807 compliance and actionable error feedback, while seamless integration with existing analytics and logging ensures complete observability of overridden responses. For a comprehensive list of changes, please refer to the detailed changelog below.

​
Breaking Changes

Default maximum and minimum TLS versions are now inherited from the underlying Golang library and so will be TLS 1.3 and TLS 1.2, respectively (previously were both set to TLS 1.2). You must set http_server_options.max_version (or the equivalent environment variable) to 771 if you require an upper limit of TLS 1.2. See here for details how to control TLS version and cipher suites. Query parameters from original request are no longer automatically preserved when looping using tyk:// protocol) We have fixed an inconsistent behavior when using the URL rewrite middleware to loop requests using the Tyk protocol (tyk://api-id/path). Previously, query parameters added to the rewrite_to URL were silently dropped, while original request parameters were automatically preserved in the looped request. This behavior was inconsistent with standard HTTP URL rewrites and prevented proper parameter transformation during internal API routing. Impact
  • Original request query parameters are no longer automatically forwarded through internal loops
  • Existing URL rewrite configurations may lose query parameters that were previously passed through automatically
  • APIs relying on automatic parameter forwarding will receive incomplete requests
Migration Required Update your URL rewrite configurations to explicitly include any original query parameters you want to preserve. For example:
  • Before: "rewrite_to": "tyk://api-123/endpoint" (original params auto-forwarded)
  • After: "rewrite_to": "tyk://api-123/endpoint?param1=$tyk_context.request_data.param1"
Strict Validation of Characters Allowed in Policy IDs To avoid an issue where Policy IDs containing special characters could cause problems when parsing API endpoint requests, we have introduced strict validation of Policy IDs during Policy creation and update. The allowed characters are:
  • alphanumeric characters
  • _
  • -
  • .
  • ~
Strict validation can be disabled, if required for existing Policies with incompatible Policy IDs, using the new Gateway configuration allow_unsafe_policy_ids. If using this mode, care must be taken not to use characters that could affect URL parsing.

​
Dependencies

Compatibility Matrix For Tyk Components
To use MCP Gateway features introduced in 5.13.0, upgrade the following Tyk components at the same time:
  • Dashboard 5.13.0: MCP Proxy management and access control configuration
  • Pump 1.15.0: MCP analytics (MongoDB, PostgreSQL, Elasticsearch, and Prometheus backends)
  • MDCB 2.11.0: MCP analytics routing in distributed deployments
  • Operator 1.4.0: MCP Proxy management via Kubernetes CRDs
  • Sync 2.1.7: MCP Proxy support in dump and sync operations
3rd Party Dependencies & Tools
Given the potential time difference between your upgrade and the release of this version, we recommend users verify the ongoing support of third-party dependencies they install, as their status may have changed since the release.

​
Deprecations

There are no deprecations in this release.

​
Upgrade instructions

If you are upgrading to 5.13.0, please follow the detailed upgrade instructions. If your deployment uses MCP Gateway, additional component ordering applies. In distributed deployments, MDCB 2.11.0 must be deployed before Gateway and Dashboard. Tyk Operator 1.4.0 must be deployed after Gateway and Dashboard are running. See MCP Gateway upgrade considerations for the full sequence.

​
Downloads

Tyk Helm Charts are configured to install the LTS version of Tyk Gateway. You will need to modify them to install v5.13.0.

​
Changelog

Changed
We have updated all OpenTelemetry Go SDK dependencies to their latest compatible versions, addressing significant version skew across core packages, OTLP exporters, and contrib instrumentation libraries.The upgrade delivers cumulative performance improvements to span lifecycle methods, trace context propagation, metrics recording, and attribute handling that benefit hot paths exercised on every HTTP request. This change maintains full backward compatibility with existing functionality and serves as a prerequisite for upcoming metrics features.
Added
We have introduced the MCP (Model Context Protocol) Gateway, enabling teams to proxy, secure, and manage AI agent tool servers using Tyk API management. MCP Proxy definitions use OpenAPI Specification (OAS) format and support the JSON-RPC over HTTP transport used by MCP clients and servers.This release includes:
  • SSE streaming: MCP Proxies support long-lived Server-Sent Events connections. The write deadline is cleared for SSE streams so connections survive beyond the configured write timeout. A structured event: error message is sent to the client if the upstream connection drops unexpectedly.
  • Protected Resource Metadata (PRM): The /.well-known/oauth-protected-resource endpoint is served as a middleware in the Gateway chain, making $tyk_context.* substitution variables available for use in PRM resource field values.
For configuration details, see the MCP Gateway documentation.
MCP Proxies support granular access control at the JSON-RPC method and MCP primitive levels. Two new middleware components enforce access rules independently for each request:
  • JSON-RPC method access control: Allows or denies requests by method name (e.g., tools/call, resources/read, prompts/get). Configured via json_rpc_methods_access_rights in a key or policy access definition.
  • MCP primitive access control: Allows or denies requests by primitive type (tool, resource, or prompt) and name. Configured via mcp_access_rights in a key or policy access definition.
When multiple policies apply to a key, access control lists merge using union semantics: a primitive allowed by any policy is accessible. Block rules take precedence over allow rules. Denied requests receive a JSON-RPC error response rather than an HTTP error, maintaining protocol compatibility with MCP clients.For configuration details, see the MCP proxy policies documentation.
MCP Proxies support independent rate limits for each JSON-RPC method and for individual tools, resources, and prompts. Two new fields are available in key and policy access definitions:
  • json_rpc_methods: rate limits keyed by JSON-RPC method name (e.g., tools/call)
  • mcp_primitives: rate limits keyed by primitive type and name
Limits are translated into Virtual Endpoint Method (VEM) entries at session load time and enforced by the existing rate limiting middleware with no additional processing overhead. The translation is in-memory only and is never persisted to Redis.When multiple Policies apply to a Session, rate limits merge using most-permissive semantics: the highest rate allowed by any Policy applies.For configuration details, see the MCP Proxy policies documentation.
Gateway access logs now include MCP-specific fields for requests handled by MCP Proxies:
  • mcp_method: the JSON-RPC method name (e.g., tools/call)
  • mcp_primitive_type: the primitive category (tool, resource, or prompt)
  • mcp_primitive_name: the name of the specific tool, resource, or prompt invoked
A new api_type field is also added to all access log entries, distinguishing MCP traffic from classic, oas, and graphql API types.For details, see the MCP access logs documentation.
OpenTelemetry custom metrics now expose four MCP-specific dimensions, enabling observability of MCP Proxy traffic through configurable metric instruments:
  • mcp_method: the JSON-RPC method name
  • mcp_primitive_type: the primitive category (tool, resource, or prompt)
  • mcp_primitive_name: the name of the specific primitive invoked
  • mcp_error_code: the JSON-RPC error code when an error is returned; empty otherwise
The dimensions are aligned with the OpenTelemetry mcp.* semantic conventions. MCP context is propagated before access control runs, so rejected requests still carry full MCP dimension data.For details, see the MCP metrics documentation.
We have uplifted the existing error response templating system with a new comprehensive mechanism to customize HTTP error responses generated by both the Tyk Gateway and upstream services.This allows users to fully control error responses to standardize formats, mask sensitive information, and comply with industry standards.Key capabilities:
  • Multi-level Configuration: Configure error overrides globally (Gateway-wide), or per API with clear precedence rules
  • Flexible Matching: Target errors by exact status codes (401, 500), patterns (4xx, 5xx), error flags, message patterns, or response body content
  • Rich Response Customization: Override status codes, response bodies, headers, and use template files with dynamic variables
  • Universal Coverage: Customize both Gateway-generated errors (authentication, rate limiting, validation) and upstream service errors (4xx/5xx responses)
Configuration: Error overrides use a map-based structure indexed by HTTP status code in the new error_overrides configuration.Template Support: Response templates support dynamic variables including {{.StatusCode}}, {{.Message}}, and validation-specific context like {{.InvalidParams}} for detailed error feedback.Precedence Order:
  1. API-level overrides
  2. Gateway-level overrides
  3. Default Tyk responses (fallback)
Supported Error Types:
  • Gateway errors: Authentication failures, rate limits, validation errors, transform failures
  • Proxy errors: DNS failures, timeouts, circuit breaker events
  • Upstream errors: 4xx/5xx responses from backend services
Benefits:
  • Standardize error responses across APIs and environments
  • Mask sensitive internal error details for security
  • Provide consistent error formats for client applications
  • Enable RFC 7807 Problem Details compliance
  • Reduce client-side error handling complexity
This feature integrates seamlessly with existing analytics, logging, and observability systems; all overridden responses are properly captured in access logs, analytics records, and distributed traces. The system is fully backward compatible with no configuration required; existing error responses remain unchanged unless explicitly overridden.
When an API exceeded its rate limit and returned an HTTP 429 status code, the X-RateLimit-Limit and X-RateLimit-Remaining response headers were populated from quota data (e.g. monthly limits) rather than rate-limit data (e.g. per-minute thresholds). This was inconsistent with the RFC conventions for these headers and a common source of confusion. This release adds a new Gateway configuration option rate_limit_response_headers. When set to “rate_limits”, the X-RateLimit-* headers are populated from rate-limit data instead of quota data:
  • X-RateLimit-Limit: the configured rate limit threshold
  • X-RateLimit-Remaining: remaining requests in the current rate limit window
  • X-RateLimit-Reset: time until the rate limit window resets
Backward compatibility is preserved: when the option is unset, the headers continue to reflect quota data as before.
We have added a new, simplified, approach to configuring Session lifetime within Redis.Two new fields have been added to the Session object, which can be directly configured when creating Sessions using the Keys API or Policy API:
  • post_expiry_action - determines what happens to the data in Redis after the expires timestamp is reached.
  • post_expiry_grace_period - defines how long (in seconds) the Session is kept in Redis after expiration (if the post_expiry_actions is to retain the Session)
The existing Gateway-wide global session lifetime override is still respected.The legacy API level controls can still be used if both new fields are set to 0 (or unset) so there is no change in behavior for existing Sessions.
Rotating the mTLS certificates used by the Gateway to authenticate with external Identity Providers — for the OAuth external service integration, covering both client and upstream authentication — previously required a Gateway restart. For organizations using short-lived certificates (e.g. 90-day rotation cycles), this added operational overhead, forced infrastructure changes, and in some cases required custom image rebuilds during routine rotation. This release extends KV store reference support to the following Gateway configuration fields:
  • external_services.oauth.mtls.cert_file
  • external_services.oauth.mtls.key_file
  • external_services.oauth.mtls.ca_file
These fields now accept KV store references such as vault:// and consul://, in line with how other sensitive Gateway configuration fields already do. After updating the referenced certificate in the KV store, triggering a Gateway hot reload causes the new value to be picked up — no process restart required. Backward compatibility is preserved: existing OAuth external service configurations using absolute file paths or certificate IDs from the Tyk Certificate Store continue to work without modification.
When configuring mTLS for both upstream authentication and the OAuth external service integration, the same certificate often had to be configured in two places — once for upstream auth, and again in the External Services OAuth configuration. For deployments using the same certificate for both, this created a redundant configuration that needed to be kept in sync. This release adds an optional configuration toggle that allows the Gateway to reuse the mTLS certificate configured for upstream connections when making OAuth calls to the external Identity Provider. When the toggle is enabled, the upstream certificate is used for both purposes, removing the need to maintain duplicate configurations. The toggle is intentionally optional: deployments may legitimately use different certificates for the two endpoints. When the toggle is unset, the OAuth external service continues to use its own dedicated certificate configuration.
We have added support for underscore characters in $secret_vault and $secret_consul secret reference paths. Previously, the underscore character was not supported in these Key-Value store reference paths due to regex pattern limitations, causing references to be truncated at the first underscore. For example, $secret_vault.kv-v2/path.API_KEY would only match up to .API, silently dropping _KEY.This enhancement aligns $secret_vault and $secret_consul patterns with existing $secret_env, $tyk_context, and $tyk_meta patterns that already support underscores. Users can now reference secrets using standard naming conventions like API_KEY and DB_PASSWORD without needing to duplicate secrets under underscore-free names. The change maintains full backward compatibility with existing references that don’t contain underscores.
Building on the API definition compression introduced in 5.12.0, this release extends Data Plane Redis storage optimisation to security policies and makes the previously hardcoded decompression size limit configurable. These improvements help customers with large API and policy footprints (for example, deployments with 100MB+ of API definitions and 60MB+ of security policies) reduce Redis storage costs without impacting request handling performance.Compression is opt-in per asset type via independent configuration flags: storage.compress_api_definitions (introduced in 5.12.0) for API definitions, and the new storage.compress_policies for security policies. Both are disabled by default and remain backward compatible — Gateways transparently load both compressed and uncompressed data from Redis.The decompression size limit is now configurable via the new storage.max_decompressed_size option (default 100MB, minimum 1MB) and is applied independently to API definitions and policies, so each asset type has its own ceiling. As with the original feature, compression and decompression occur only during Gateway reloads, with no impact on the request hot path.
We have introduced comprehensive OpenTelemetry metrics export, providing real-time operational visibility into Gateway performance, health, and business KPIs. This complements existing distributed tracing and logging to deliver a complete observability solution.Key Features:
  • Default Gateway Metrics: Automatic export of RED metrics (Rate, Errors, Duration), Go runtime health metrics (CPU, memory, goroutines, garbage collection), and configuration state tracking (loaded APIs/policies, reload operations)
  • Custom Business Metrics: Define custom counters and histograms with dynamic dimensions sourced from request headers, JWT claims, session data, context variables, and API config_data
  • Endpoint-Level Granularity: Track metrics per endpoint using the new listen_path and endpoint dimensions for detailed API monitoring
  • Multi-Tenant Support: Track usage per customer, tier, or organization using dynamic dimensions
  • Universal Backend Support: Export via OTLP to Prometheus, Grafana, Datadog, New Relic, Dynatrace, and other observability platforms
  • Metric-to-Trace Correlation: Automatic exemplar support links metric anomalies directly to distributed traces, enabling seamless navigation from metrics to traces during incident investigation.
  • Gateway Identity Attributes: Configurable resource attributes help identify and filter individual Gateway instances in multi-node deployments.
Configuration: Metrics are configured under the new opentelemetry.metrics object with independent control from tracing.Default Metrics Exported:
  • Request Metrics: http.server.request.duration, tyk.gateway.request.duration, tyk.upstream.request.duration, tyk.api.requests.total
  • Go Runtime Metrics: CPU utilisation and processing time, memory usage breakdown (heap, stack, allocations), active goroutine count and lifecycle, garbage collection duration and frequency, thread count
  • Configuration Metrics: Loaded APIs and policies count, reload operations and duration
The Go runtime metrics enable teams to correlate system-level resource constraints with API latency patterns, detect potential goroutine or memory leaks early, and right-size infrastructure based on actual resource utilisation.Production Controls: To ensure safe metric collection on the request hot path, the system includes built-in cardinality limits (default: 2,000 combinations per metric) and conditional data loading to prevent performance degradation.
Fixed
We have resolved an issue where “Client TLS certificate is required” errors were logged at warning level, creating unnecessary noise in production logs.Previously, these common client-side authentication failures generated excessive warning-level log entries that could trigger false alerts and obscure more critical issues. The Gateway now logs these authentication failures at info level, maintaining security visibility while reducing log noise and alert fatigue for operations teams.
We have resolved an issue where a Go plugin returning an error status code would result in malformed response bodies that concatenated the original plugin response with additional Gateway error messages.The Gateway now correctly handles plugin-generated error responses without double-writing headers, ensuring response bodies contain only the payload generated by the plugin and eliminating superfluous warnings in logs.
We have resolved inconsistent query parameter handling in URL rewrites when internally looping using the tyk:// scheme. Previously, custom query parameters specified in the rewrite_to URL were silently dropped, while original request parameters were unexpectedly preserved.What’s Fixed:
  • Query parameters explicitly added to rewrite_to URLs are now correctly passed to target APIs
  • Control parameters (method, loop_limit, check_limits) are properly consumed and removed
  • Behavior now matches URL rewrites using http:// protocol
It is important to note that query parameters provided with the original request are no longer automatically forwarded. You must update your URL rewrite configuration to explicitly include any required parameters in the rewrite_to URL.
We have resolved an issue where a Tyk Gateway acting as a client (using upstream mTLS) would fail to authenticate against another Tyk Gateway acting as the mTLS server, resulting in HTTP 403 Forbidden: Client TLS certificate is required errors.The Gateway now reliably presents the configured upstream client certificate whenever requested by the target server, ensuring seamless mTLS communication between APIs hosted on different Tyk Gateways.
We have resolved an issue where the Tyk Gateway default maximum TLS version was incorrectly set to TLS 1.2 instead of TLS 1.3.Tyk Gateway now follows Go’s native TLS defaults (TLS 1.2 minimum, TLS 1.3 maximum), aligning with industry security standards. This maintains full backward compatibility for existing deployments that explicitly configure TLS versions.To change the maximum TLS version, you must explicitly set TYK_GW_HTTPSERVEROPTIONS_MAXVERSION for client-to-Gateway connections or TYK_GW_PROXYSSLMAXVERSION for Gateway-to-upstream connections.To change the minimum TLS version, you must explicitly set TYK_GW_HTTPSERVEROPTIONS_MINVERSION for client-to-Gateway connections or TYK_GW_PROXYSSLMINVERSION for Gateway-to-upstream connections.For full details of TLS version configuration see here.
We have resolved an issue where CORS preflight OPTIONS requests were incorrectly blocked by the AllowList middleware when options_passthrough was disabled.Previously, when APIs had CORS enabled with Tyk handling OPTIONS requests internally (options_passthrough: false), preflight requests would fail AllowList validation because users typically don’t explicitly define OPTIONS endpoints in their AllowList configurations, causing “Requested endpoint is forbidden” errors.The Tyk Gateway now properly recognizes CORS preflight requests and allows them to bypass AllowList middleware checks when Tyk is configured to handle OPTIONS internally, restoring the expected behavior where CORS preflight handling works automatically without requiring explicit OPTIONS endpoint definitions.
We have resolved an issue where Tyk OAS APIs with mock endpoints stopped generating analytics data. This functionality was inadvertently broken while fixing an unrelated internal API proxying issue in Tyk Gateway 5.8.6.Note that analytics are not generated for mock endpoints in Tyk Classic APIs as has always been the case.
We have resolved an issue where OpenTelemetry settings could only be set using environment variables and not the Gateway configuration file (tyk.conf).Now OpenTelemetry can be configured via the opentelemetry section in the Gateway config file (including enabled, exporter, and endpoint fields) or their equivalent environment variables.
We have fixed an issue where the Gateway could fail to load APIs and policies if the Control Plane database was temporarily unavailable during startup (either directly or via MDCB). The Gateway will now automatically retry loading configurations with exponential backoff until successful, restoring self-healing capabilities without requiring a manual restart.
We have resolved an issue where Policy IDs containing special characters could cause problems when parsing API endpoint requests. Previously, Policy IDs with characters such as #, ?, %, and / would interfere with URL parsing in Tyk Gateway API endpoints that use the Policy ID as a path parameter, potentially causing request failures or unexpected behavior.Strict validation has been introduced to restrict policy identifiers to a safe character set (alphanumeric characters plus _, -, ., ~). The validation occurs during Policy creation and updates via the following endpoints:
  • POST /tyk/policies
  • PUT /tyk/policies/{polID}
A new Gateway configuration option allow_unsafe_policy_ids has been added to disable this character validation in case of existing non-compliant Policy IDs. If you must use other characters in your Policy IDs, be careful to avoid any that might cause URL parsing issues.
We have resolved an issue where requests with the application/soap+xml Content-Type received JSON-formatted error responses instead of the expected XML format. The Gateway now correctly returns XML-formatted errors for SOAP requests.
Resolved an issue introduced alongside the span_batch_config feature in 5.12.0 where, when the configuration was omitted or left unset, Gateway startup logs reported the batch processor settings (max_queue_size, max_export_batch_size, batch_timeout) as zero values. The Gateway was internally applying the standard Go SDK defaults correctly, but the logs misrepresented this, making it appear that the OpenTelemetry exporter was misconfigured. Startup logs now report the actual default values in use, giving operators an accurate view of the active configuration.
Resolved an issue where responses served from the Redis cache middleware did not emit access log entries, making cache hits invisible in access logs even when access_logs.enabled was set to true. Cache hits now generate access log entries with the same structure as non-cached responses. The same fix ensures that cache hits are also captured by the newly introduced OpenTelemetry API metrics.
We have resolved a set of related issues affecting Gateway registration with the Dashboard at scale for deployments using an unlimited node license. During mass registrations or rolling upgrades, a combination of lock contention, excessive Redis load, and incorrect handling of 409 Conflict responses could leave Gateways stuck in registration loops without the credentials needed to serve traffic.Gateway registration is now significantly more robust at scale: registration requests are no longer serialized across the fleet, Gateways recover cleanly from transient 409 Conflict responses instead of looping, and the Redis load generated during registration storms is substantially reduced.A dedicated fix for limited node license deployments will be provided in an upcoming release.
Resolved an issue where the Distributed Rate Limiter’s cache cleanup stopped running after its first execution. This could cause unbounded memory growth on APIs using rate limits with high-cardinality keys (such as per-client-IP rate limiting or custom plugins generating unique keys), and could briefly reset active rate-limit buckets shortly after Gateway startup, allowing requests that should have been blocked to pass through. Memory usage now stays bounded, and rate limits are enforced as configured.
Security Fixes
We have addressed CVEs reported in dependent libraries, providing increased protection against security vulnerabilities, including, but not limited to:

​
5.12 Release Notes

​
5.12.1 Release Notes

​
Release Date 21st April 2026

​
Release Highlights

Tyk Gateway has been updated to Golang 1.25 and Debian 13 (Trixie) for enhanced security and performance, including updated FIPS-compliant images. This release addresses multiple CVEs in dependent libraries and fixes a path matching inconsistency for Tyk OAS APIs. For a comprehensive list of changes, please refer to the detailed changelog below.

​
Breaking Changes

There are no breaking changes in this release.

​
Dependencies

Compatibility Matrix For Tyk Components
3rd Party Dependencies & Tools
Given the potential time difference between your upgrade and the release of this version, we recommend users verify the ongoing support of third-party dependencies they install, as their status may have changed since the release.

​
Deprecations

There are no deprecations in this release.

​
Upgrade instructions

If you are upgrading to 5.12.1, please follow the detailed upgrade instructions.

​
Downloads

Please note that the Tyk Helm Charts are configured to install the LTS version of Tyk Gateway. You will need to modify them to install v5.12.1.

​
Changelog

Changed
The Tyk Gateway has been updated to Golang 1.25, improving security by staying up-to-date with Go versions.
Updated the Docker images for Tyk Gateway to Debian 13 (Trixie) to address multiple vulnerabilities in the underlying operating system.
Fixed
Resolved an issue where parameterized paths could incorrectly take precedence over static paths when using the Request Validation or Mock Response middleware in Tyk OAS APIs. Static paths will now correctly bypass these middleware if not explicitly configured, restoring the expected routing behavior.
Security Fixes
Addressed the following CVEs, providing increased protection against security vulnerabilities:

​
5.12.0 Release Notes

​
Release 06 March 2026

​
Release Highlights

OpenAPI Specification 3.1 is now supported In this release, we are delighted to bring initial support for OAS 3.1 in Tyk OAS APIs covering:
  • Import and validation of OpenAPI 3.1 descriptions using Tyk Dashboard to create Tyk OAS APIs
  • OAS 3.1 features:
    • Full JSON Schema Support and $schema keyword
    • The single example keyword is deprecated in OAS 3.1
    • type can be an array
    • exclusiveMinimum and exclusiveMaximum keywords
We do not yet have support for all new features. For more details, see the documentation Enhanced OpenTelemetry Tracing and Log Correlation In this release, we’ve significantly improved observability by bridging the gap between logs and distributed traces. When OpenTelemetry is enabled, Tyk Gateway now automatically injects W3C trace IDs into access logs, and both trace and span IDs into application logs. This allows your DevOps and SRE teams to seamlessly correlate Gateway operational events with distributed traces across platforms such as Grafana Tempo, Jaeger, and OpenSearch, providing full visibility into the request journey. Additionally, we’ve introduced flexible support for custom trace headers. If your organization uses custom correlation ID systems (like X-Correlation-ID), the Gateway can now recognize these as trace context sources. With multiple propagation modes, you can gradually migrate to standard OpenTelemetry tracing without modifying existing downstream systems. Enhanced Error Observability in Access Logs Troubleshooting API errors in production just got significantly faster. We’ve enhanced Gateway access logs to include rich, structured error context for 4XX and 5XX errors, eliminating the need to cross-reference multiple log sources during an incident. Users can now instantly identify the root cause of failures—whether it’s an expired TLS certificate, a network connectivity issue, or a backend service problem—directly from the access logs. This comprehensive visibility drastically reduces time-to-resolution and simplifies debugging. Programmatic Configuration Inspection for Faster Troubleshooting Verifying configuration settings and debugging deployment issues can be time-consuming when multiple configuration sources (files, environment variables, defaults) are involved. To streamline troubleshooting, we’ve introduced configuration inspection endpoints to the Tyk Gateway API. Platform engineers and support teams can now programmatically access the Gateway’s actual runtime configuration directly through the control API. This eliminates the need for manual configuration file sharing and supports automated drift detection, while built-in redaction automatically protects sensitive data like passwords and secrets. Enhanced Security with Client Certificate-Token Binding To provide an additional layer of security for your APIs, we’ve introduced Client Certificate-Token Binding. This feature allows you to form a strict binding association between an Auth Token issued to a client and their specific client certificate. By ensuring that a token can be used only with its bound certificate, you can significantly reduce the risk of token theft or misuse. The feature fully supports certificate rotation scenarios by allowing multiple certificates to be bound to a single key, ensuring uninterrupted access during credential updates. Certificate Authentication as a Standalone Auth Method for Tyk OAS We have restructured Certificate Authentication (formerly known as Dynamic mTLS) to be a dedicated, standalone authentication method in Tyk OAS API definitions. Previously configured as an adjunct to Auth Token authentication, this change aligns Certificate Authentication with other Tyk proprietary methods like HMAC and Custom Auth. This improves API design consistency and makes it much more intuitive to configure certificate-based access, all while maintaining full backward compatibility with your existing API definitions. Optimized Redis Storage for Data Planes We have significantly reduced Redis memory consumption for Data Plane deployments, delivering immediate storage cost savings and improved efficiency for large-scale environments. By implementing intelligent storage optimization, the Gateway now automatically omits empty fields when storing session data, reducing memory usage for typical API keys by up to 20%. Additionally, we’ve introduced optional compression for cached API definitions, reducing storage requirements by up to 75% without impacting API response times. These enhancements are fully backward compatible and require no migration of existing keys or definitions. For a comprehensive list of changes, please refer to the detailed changelog below.

​
Breaking Changes

A change has been made to improve security of the legacy Auth Token + Dynamic mTLS method for securing access to APIs deployed on Tyk. This removes the option to authenticate using only the auth token and enforces the mTLS handshake. Previously, API clients could authenticate without presenting the client certificate or holding the client’s private key. For any user relying on that behavior, we have added a new Gateway configuration option: allow_unsafe_dynamic_mtls_token. Unless deliberately configured in the config file or environment, this is set to false to ensure that Tyk is secure by default.

​
Dependencies

Compatibility Matrix For Tyk Components
3rd Party Dependencies & Tools
Given the potential time difference between your upgrade and the release of this version, we recommend users verify the ongoing support of third-party dependencies they install, as their status may have changed since the release.

​
Deprecations

The introduction of Certificate Authentication as a standalone auth method in place of Auth Token + dynamic mTLS means that the configuration field authentication.securitySchemes.authToken.enableClientCertificate in the Tyk Vendor Extension is now deprecated in favour of authentication.certificateAuth.enabled. The legacy field remains valid for backward compatibility at this time, but users are recommended to switch to the new configuration.

​
Upgrade instructions

If you are upgrading to 5.12.0, please follow the detailed upgrade instructions.

​
Downloads

Please note that the Tyk Helm Charts are configured to install the LTS version of Tyk Gateway. You will need to modify them to install v5.12.0.

​
Changelog

Added
This release introduces initial support for importing and validating OpenAPI 3.1 descriptions to create Tyk OAS APIs. The implementation maintains backward compatibility with OAS 3.0 while adding support for the new JSON Schema 2020-12 validator:
  • Added full JSON Schema support, including the $schema keyword.
  • Added support for defining type as an array (e.g., ["string", "null"]).
  • Support for exclusiveMinimum and exclusiveMaximum
Please note the following limitations in this initial release:
  • Reusable Path Item Objects and the new mutualTLS security scheme are not currently supported.
This release introduces significant storage optimizations for Data Plane Redis caching, reducing memory consumption while maintaining full backward compatibility:
  • Session Object Optimization: The Gateway now automatically omits empty and zero-value fields when storing API keys and session objects. This results in up to a 20% reduction in memory usage, with minimal keys now consuming only 500-700 bytes.
  • API Definition Compression: Added optional Zstd compression for API definitions cached in Redis, achieving up to 75% storage reduction. Compression and decompression occur during Gateway reloads, ensuring zero impact on the request hot path.
  • Configuration: API definition compression is disabled by default. It can be enabled via the new storage.enable_api_definition_compression configuration option.
  • Security Limit: To mitigate the risk of decompression bombs, the maximum combined uncompressed size for the API definitions is limited to 100MB.
This release brings significant improvements to OpenTelemetry tracing and log correlation capabilities within the Gateway. These enhancements ensure better observability and easier debugging across distributed systems by unifying trace context across all log types:
  • Added the trace_id field to Gateway access logs when OpenTelemetry is enabled, matching the X-Tyk-Trace-Id response header.
  • Added trace_id and span_id fields to all request-scoped Gateway application logs (middleware execution, errors, and debugging).
  • Introduced custom trace header configuration (e.g., X-Correlation-ID) to support non-standard header names as trace context sources with three trace propagation modes:
    • Custom-only (read and write custom headers exclusively)
    • Hybrid (read custom headers, write standard traceparent)
    • Composite (read custom headers, write both custom and standard formats)
  • Implemented automatic fallback to standard W3C propagators when custom trace headers are missing or invalid.
In high-throughput production environments, default OpenTelemetry settings can cause silent span loss and incomplete traces under heavy load. To address this, we’ve introduced the ability to tune OpenTelemetry BatchSpanProcessor settings to match your specific traffic patterns. By adjusting queue sizes and batch parameters, you can significantly reduce orphaned child spans and ensure trace completeness, giving you full visibility into your API traffic.Added a new span_batch_config section to the OpenTelemetry configuration to prevent span loss in high-throughput environments. Users can now override default Go SDK settings by tuning max_queue_size, max_export_batch_size, and batch_timeout. This configuration is optional and backward compatible; omitted or zero values will default to standard SDK values.
This release introduces detailed error context fields to access logs for 4XX and 5XX gateway and upstream errors, providing immediate technical insight into failure root causes including:
  • response_flag for standardized error codes (e.g., TLE for TLS expired, UCF for connection refused, RLT for rate limiting).
  • response_code_details for human-readable error descriptions.
  • error_source (originating component) and error_target (upstream address).
  • upstream_status to capture the HTTP status returned from the upstream service.
  • context-specific fields that appear only when relevant: tls_cert_expiry and tls_cert_subject for certificate errors, and circuit_breaker_state for circuit breaker errors.
The full list of response flag codes is available in the Access Logs documentation.
Added new /config and /env endpoints to the Tyk Gateway API to provide programmatic access to runtime configuration and environment variable mappings. This enables targeted troubleshooting and configuration auditing directly through authenticated API calls:
  • Supports both full configuration dumps and targeted single-field queries (e.g., /config?field=storage.host).
  • Automatically redacts sensitive data (passwords, secrets, connection strings) to preserve configuration structure visibility securely.
  • Clarifies configuration precedence and naming conventions from multiple sources.
This feature is disabled by default and is enabled using enable_config_inspection.
This release introduces the ability to bind client certificates to Auth Tokens for APIs secured with a static mTLS allow list. This provides enhanced token security by ensuring tokens are only used with their associated certificates:
  • Added a new mtls_static_certificate_bindings field to the session object, which accepts a list of one or more certificate IDs.
  • Enforces that the certificate presented in the request matches the bound certificate IDs; otherwise, the request is rejected.
  • Supports binding multiple client certificates to a single key (token) to facilitate certificate rotation.
Please note that bound certificates must also be present in the client certificate allow list within the API definition for successful post-handshake validation. This feature maintains full backward compatibility with existing keys that do not specify certificate bindings.
Extended certificate expiry monitoring to include TLS certificates used by the Gateway as the client in connections to upstream services. When a certificate used by the Gateway to authenticate itself with the upstream has expired or is within the configured number of days prior to expiry, an entry will be added to the application log and the appropriate Gateway event will be generated. The new cert_role field in the event metadata indicates whether the certificate was used in client or upstream authentication.With this addition, the certificate expiry monitor now tracks all certificates used to represent the Gateway in TLS handshakes.
This release introduces a new, dedicated configuration structure for Certificate Authentication (formerly Dynamic mTLS) in Tyk OAS API definitions, separating it from Auth Token authentication:
  • Introduced the new authentication.certificateAuth.enabled field to configure Certificate Authentication as a standalone method.
  • Deprecated the legacy authentication.securitySchemes.authToken.enableClientCertificate field (it remains fully supported for backward compatibility).
  • When both the new and deprecated fields are present, the new certificateAuth.enabled field takes precedence.
In Tyk 5.10.0, we introduced API-level configuration for the validity period of the JWKS cache for Tyk OAS APIs. Now we have made the Gateway default (which is applied if no API-level configuration is set) configurable via a new option in the Gateway config file: jwks.cache.timeout or the equivalent environment variable. If this is not set, the timeout will continue to default to 240 seconds. This will be applied to both Tyk Classic and Tyk OAS APIs, simplifying JWKS cache management across large API deployments while providing flexibility for APIs that require specific caching behaviors.
This release introduces improvements to how the Gateway handles policy IDs, particularly in multi-Organisation deployments. These changes ensure that policies are correctly applied and provide better visibility into potential configuration conflicts:
  • The Gateway now correctly discriminates between policies with identical id fields across different Organisations (Orgs), ensuring that policies are only applied to keys within their respective org_id.
  • Added a new warning-level log message that triggers if multiple policies are loaded with the same id within a single Org. The log details the shared id and the individual internal _id values of the conflicting policies to assist with troubleshooting.
These enhancements allow users to safely use custom policy IDs without risking cross-Org conflicts. The new warning logs help administrators identify and resolve legacy configuration issues in which duplicate policy IDs may exist within the same Organisation.
Gateway now includes a list of the loaded APIs and policies in the information it provides to MDCB. This provides a clear picture of what is running on each Gateway in a distributed deployment, simplifying monitoring and troubleshooting of your deployed Data Planes.
This release introduces a usage-aware certificate synchronization system for distributed deployments (MDCB). Data Planes can now be configured to only sync and store certificates that are actually required by their loaded APIs when using the MDCB Synchroniser, rather than pulling all certificates from the Control Plane:
  • Added a new sync_used_certs_only boolean flag to the slave_options configuration.
  • When enabled alongside use_rpc: true, the data plane tracks certificate usage by analyzing loaded API specifications and filters synchronization to only pull required certificates.
  • Reduces memory usage and eliminates log noise caused by expired certificates that are not relevant to the specific Data Plane’s APIs.
This feature is disabled by default (sync_used_certs_only: false) to ensure backward compatibility. When disabled, the Gateway will continue to synchronize all certificates from the Control Plane as before.
Fixed a performance issue introduced in v5.8.7 where bundle verification significantly increased CPU and memory consumption, particularly when using multiple APIs with plugin bundles. We have introduced a new Gateway configuration option skip_verify_existing_plugin_bundle that allows you to skip cryptographic verification when loading signed plugin bundles from disk. When set to true, this option reduces performance overhead in environments with large numbers of APIs using signed bundles, while still maintaining security by validating signatures during initial bundle download. Note: This option only affects signed bundles loaded from disk, unsigned bundles and initial downloads will continue to follow standard verification procedures.
Fixed
Resolved path matching inconsistencies that could lead to Tyk OAS-specific middleware not being executed when expected.These inconsistencies could cause the Request Validation and Mock Response middleware to be skipped in certain scenarios when using Tyk OAS APIs. These scenarios included:
  • Some subpaths, for example, the middleware configured for /users would not execute for /users/123
  • some child API versions
  • wildcard regexes in paths
  • root paths
Now, Tyk will apply the same decisions to these middleware as it does to the rest of the request processing chain.
Resolved an issue where swapping certificates in multi-auth (mTLS + Basic auth) keys prevented the original certificate from being reused. Previously, when updating a key’s certificate, the original certificate remained incorrectly associated with the key internally, causing “key with given certificate already found” errors when attempting to reuse that certificate.Tyk now properly detaches certificates during key updates, allowing certificates to be freely reused across different keys after being removed from their original association.
Enhanced Gateway error logging for JWT authentication failures related to JWKS endpoints. Previously, JWKS configuration issues generated vague error messages that didn’t indicate the root cause, making troubleshooting difficult and time-consuming.The Gateway now provides specific, actionable error messages that clearly identify whether failures stem from Base64 decoding issues, network connectivity problems, or invalid JWKS content.
Resolved an issue where the Gateway could crash with a panic if the API definition contained an illegal reference to a secret in HashiCorp Vault. If the requested path did not exist in Vault, this could cause the Gateway process to exit, resulting in a complete service outage during API loads, hot reloads, or Dashboard saves. The Gateway now gracefully handles the missing Vault path and logs a clear error message.
Resolved a floating-point precision issue where mathematically valid multipleOf values were incorrectly rejected due to binary representation limitations. This could cause incorrect failures when performing Request Validation for Tyk OAS APIs.The Gateway now properly handles floating-point precision in multipleOf validation, ensuring that all mathematically valid decimal multiples pass validation consistently while continuing to correctly reject invalid values.
Resolved an issue where Tyk only validated the first instance of multi-value headers when processing requests to Tyk OAS APIs, allowing invalid header values to bypass schema constraints.The Gateway now properly normalizes and validates all header values according to HTTP standards, ensuring that all values in multi-value headers comply with the defined OpenAPI schema constraints.
Resolved a routing issue where APIs could return HTTP 404 Not Found errors depending on custom domain settings, with differing behavior between Tyk OAS and Tyk Classic APIs. Previously, when APIs had similar listen path prefixes (e.g., /caa and /caas2itsamu0456w2ayl9), the Gateway’s routing logic would incorrectly match requests, causing legitimate API calls to fail. The issue affected Tyk OAS APIs when custom domains were disabled, and Tyk Classic APIs when they were enabled.The Gateway now properly sorts and matches API specifications by listen path length, while correctly considering domain configuration options, ensuring all APIs are accessible via their configured paths regardless of custom domain settings or API type.
Resolved an issue where the Gateway incorrectly logged 0ms duration for error responses, including HTTP 504 Gateway Timeout, HTTP 499 Client Closed Request, and HTTP 500 Internal Server Error, creating gaps in API observability and monitoring. Previously, these error responses were hardcoded with zero-latency values, making it impossible to determine the actual processing time, gateway saturation, or connection utilization for failed requests.The Gateway now accurately calculates and logs the actual request duration from start to error occurrence for all error responses, providing complete timing visibility across successful and failed API requests. This enhancement improves observability for performance monitoring, capacity planning, and troubleshooting workflows.
Resolved an issue where OpenTelemetry traces were missing the “alias” field when using JWT-protected APIs, making it impossible to identify API consumers in tracing data. Previously, while the alias was correctly populated in Redis sessions and pump metrics, it was not included in OTEL spans for JWT-authenticated requests.The Gateway now ensures that OTEL spans include the alias attribute for all authentication methods, enabling proper consumer identification and request attribution in distributed tracing systems.
Resolved an issue where NewRelic OpenTracing integration worked inconsistently in Tyk Gateway. The Gateway now properly mounts NewRelic middleware on all routers, including reused ones, with thread-safe duplicate prevention and improved memory management during router swaps. This fix ensures consistent NewRelic APM visibility across all API calls and gateway versions, supporting both legacy NewRelic configurations and newer OpenTelemetry collector setups.
Resolved an issue where custom authentication plugins failed to execute properly when APIs were configured with Compliant Mode security processing. Previously, switching from Legacy Mode to Compliant Mode caused custom plugins to generate “JSVM isn’t enabled” errors and return 500 Internal Server Error responses, even when JSVM was correctly configured. Custom authentication plugins now function identically in both Legacy and Compliant modes, allowing users to leverage flexible OR/AND authentication logic without breaking existing plugin functionality. Users can now seamlessly switch between authentication modes and use custom plugins with individual authentication methods in Compliant Mode’s OR logic scenarios.
Resolved an issue where the X-RateLimit-Reset header showed an incorrect timestamp on the first API request after rate limit or quota counter initialization. Previously, when quota windows expired and were reset within the distributed lock, the Gateway failed to update its local timestamp variable, causing the first request to return stale timing information while subsequent requests showed correct values.The Gateway now properly synchronizes its internal timer with the storage backend during quota window resets, ensuring that X-RateLimit-Reset headers accurately reflect the correct expiration time from the very first request.
Resolved an issue where policies with identical custom IDs across different organizations could overwrite each other in the Gateway’s memory storage, causing incorrect policy application. Previously, when multiple organizations used the same policy ID, the Gateway would retain only the last loaded policy, potentially applying incorrect rate limits, quotas, or access controls to API requests. The Gateway now properly isolates policies by organization, ensuring that policy lookups correctly match both the policy ID and organization ID. This fix prevents cross-organizational policy conflicts, ensures that keys and JWT tokens apply the correct policies from their respective organizations, and maintains proper tenant isolation in multi-organization deployments. Organizations can now safely use identical policy IDs without risk of policy collision or incorrect access control enforcement.
Resolved an issue where OpenTelemetry traces were missing the alias attribute for JWT-authenticated requests in multi-auth APIs using compliant security processing mode. Previously, while the alias was correctly populated in analytics records and Redis session data (e.g., JWT claims or API key names), it was not included in OpenTelemetry spans for JWT authentication, making request attribution difficult in distributed tracing systems. The fix ensures that OTEL spans now include the alias attribute for all authentication methods in multi-auth configurations, providing consistent identity information across analytics records, pump output, and distributed traces. This enhancement improves observability for APIs using multiple authentication schemes, allowing operators to easily identify request sources in tracing backends like Jaeger, Tempo, or Zipkin when analyzing JWT-authenticated traffic alongside API key requests.
Resolved an issue where data plane gateways failed to load SSL certificates from MDCB during startup, preventing HTTPS listeners from functioning correctly. The fix implements exponential backoff retry logic that waits for the MDCB connection to become available during certificate loading, ensuring SSL certificates are properly retrieved, and HTTPS listeners start correctly. This resolves startup failures for new data plane deployments using HTTPS.
Security Fixes
The Gateway now enforces certificate presence for dynamic mTLS authentication by default, rejecting requests that provide only tokens without valid client certificates. A new configuration option allow_unsafe_dynamic_mtls_token has been added for backward compatibility, but defaults to false to ensure secure behavior. When enabled, this option restores the previous (insecure) behavior of accepting token-only authentication for dynamic mTLS APIs.

​
5.11 Release Notes

​
5.11.1 Release Notes

​
Release 13th February 2026

​
Release Highlights

In this release, we have fixed a memory leak that could occur when using JWT authentication; we have resolved a performance issue with bundle verification that significantly impacted resource consumption when using plugin bundles; and we have fixed some priority CVEs. For a comprehensive list of changes, please refer to the detailed changelog below.

​
Breaking Changes

There are no breaking changes in this release.

​
Dependencies

Compatibility Matrix For Tyk Components
3rd Party Dependencies & Tools
Given the potential time difference between your upgrade and the release of this version, we recommend users verify the ongoing support of third-party dependencies they install, as their status may have changed since the release.

​
Deprecations

There are no deprecations in this patch release.

​
Upgrade instructions

If you are upgrading to 5.11.1, please follow the detailed upgrade instructions.

​
Downloads

Please note that the Tyk Helm Charts are configured to install the LTS version of Tyk Gateway. You will need to modify them to install v5.11.1.

​
Changelog

Fixed
Resolved a memory leak issue that could occur when APIs used JWT authentication with JWKS URL cache.
Fixed a performance issue introduced in v5.8.7 where bundle verification significantly increased CPU and memory consumption, particularly when using multiple APIs with plugin bundles.We have introduced a new Gateway configuration option skip_verify_existing_plugin_bundle that allows you to skip cryptographic verification when loading signed plugin bundles from disk. When set to true, this option reduces the performance overhead for environments with large numbers of APIs using signed bundles, while still maintaining security by validating signatures during the initial bundle download.Note: This option only affects signed bundles loaded from disk, unsigned bundles and initial downloads will continue to follow standard verification procedures.
Security Fixes
Addressed CVEs reported in dependent libraries, providing increased protection against security vulnerabilities, including, but not limited to:

​
5.11.0 Release Notes

​
Release Date 18 December 2025

​
Release Highlights

Tyk 5.11 delivers security enhancements and deeper operational visibility - empowering teams to scale their API programs with confidence and efficiency. Strengthened API Security & Authentication This release advances our security foundation with enhanced JWT authentication capabilities. Teams can now leverage scope-to-policy mapping without requiring default policies, while new support for nested claims enables more granular policy and subject identification. We’ve also added IP spoofing protection through configurable depth selection in X-Forwarded-For headers. Advanced Operational Control Operations teams gain greater flexibility with the ability to temporarily remove targets from upstream load balancers during maintenance windows. Enhanced observability comes through OTel trace propagation to custom gRPC plugins, trace ID inclusion in API traffic logs, and dedicated Gateway latency metrics alongside upstream measurements. Data Plane Gateways now recover more quickly from interruptions to the MDCB link to the Control Plane. Enhanced Stability & Performance This release includes important stability improvements, resolving crash conditions in JWT authentication and concurrent processing scenarios, eliminating blocking operations that could cause significant delays during MDCB connectivity issues, and improving performance for OAuth key retrieval in hybrid deployments. These fixes collectively deliver a more reliable and responsive API gateway experience for enterprise environments. These enhancements collectively strengthen Tyk’s position as the platform of choice for organizations requiring enterprise-scale API management with robust security, operational excellence, and developer productivity. For a comprehensive list of changes, please refer to the detailed changelog.

​
Breaking Changes

There are no breaking changes in this release.

​
Dependencies

Compatibility Matrix For Tyk Components
3rd Party Dependencies & Tools
Given the potential time difference between your upgrade and the release of this version, we recommend users verify the ongoing support of third-party dependencies they install, as their status may have changed since the release.

​
Deprecations

In this release we’ve deprecated the policies.allow_explicit_policy_id configuration option. This was previously added to allow the use of custom policy IDs, which is now the default behaviour so this option is redundant.

​
Upgrade instructions

If you are upgrading to 5.11.0, please follow the detailed upgrade instructions.

​
Downloads

Please note that the Tyk Helm Charts are configured to install the LTS version of Tyk Gateway. You will need to modify them to install v5.11.0.

​
Changelog

Added
Added support for nested JWT claims for subject and policy fields, enabling hierarchical claim structures to be used in authentication and policy application. Now you can configure the subjectClaims, basePolicyClaims, and scopes.claims fields to use nested claim names, such as test.sub or policy.base.
We have enhanced request-level timing by tracking precise timestamps when requests enter the Gateway, enabling accurate end-to-end latency calculations that extend beyond previous proxy-only measurements.
  • Added gateway field to the latency struct in traffic logs to capture Gateway-specific processing time separate from upstream latency.
  • Extended Prometheus and StatsD pumps to expose Gateway-only latency metrics alongside existing total and upstream measurements for improved observability.
We have added support for custom scalar values when working with GraphQL APIs. Custom scalars can accept any valid GraphQL value literal (string, number, boolean, enum, object, list, null, variable), matching the GraphQL specification’s requirements for custom scalars. Existing standard scalar types (Int, Float, String, Boolean, ID) continue to work as before.
We have implemented background monitoring of MDCB endpoint DNS resolution to ensure rapid response to changes without waiting for failures, which block API consumer requests. When a DNS change is detected, Tyk will now automatically reconnect the RPC client to minimise downtime and risk of request blocking. The DNS monitor checks for changes at a configurable interval (default: 30 seconds, minimum: 10 seconds). This can be set using the slave_options.dns_monitor configuration.
You can now temporarily remove upstream targets (servers) from Tyk’s upstream load balancing group. If a target is removed from the group, Tyk will route no traffic to it. This allows temporary target removal for maintenance, troubleshooting or environment issues. Simply set the weight for the target to zero, and it will be removed from the round robin list. Multiple targets can be removed, but at least one must have a non-zero weight and thus will be served traffic.
We’ve removed the need to supply a default policy when using scope-to-policy mapping with JWT Authentication. Now, if you enable scope-to-policy mapping by configuring scopes.claimName, you do not need to provide a policy ID in defaultPolicies. If a request does not contain any valid scopes, it will be rejected with HTTP 403 Forbidden (default deny). You can still provide a default policy if you require a different behaviour.
When OpenTelemetry is enabled, the Trace ID allocated to each request is tagged in traffic logs as trace-id-{traceID} and also exposed in $tyk_context.tyk_trace_id. This makes it easier to correlate traffic logs with OTel traces in observability platforms and also allows transformation middleware and custom plugins to correlate logs with traces.
Added xff_depth configuration parameter to the Gateway’s HTTP server options for improved security. This specifies which entry in the X-Forwarded-For header chain should be considered to contain the real client IP. The value set in xff_depth is used when counting from the rightmost (most trusted) end of the IP chain, where a value of 1 is the first (counting from the right). If xff_depth is set to 0 or not configured, Tyk continues using the first IP address as before, maintaining backward compatibility. We have updated the default configurations across Tyk Demo, Helm Charts, and example files to use xff_depth=1 for enhanced security in new deployments.
Implemented OpenTelemetry trace context propagation to maintain request tracing visibility as requests flow through plugins, with specific support for gRPC plugins. Enhanced the Protocol Buffer definitions and Dispatcher interface to include trace context fields, updated the CoProcessor and GRPCDispatcher to preserve trace information, and added OpenTelemetry gRPC interceptors for seamless context propagation. This eliminates observability blind spots in plugin processing, allowing customers to see complete end-to-end traces of API requests, including all plugin activities.
Fixed
Fixed a bug causing JWT authentication to panic in MDCB emergency mode. When processing tokens with new sub-claims, the gateway returned an uninitialized session missing its KeyID, leading to a crash when generating the session’s KeyHash. The fix ensures the KeyID is preserved in the emergency-mode path, allowing sessions to be created and cached correctly and preventing panics during MDCB outages.
Fixed an issue where Gateways using Redis-based rate limiters would crash when sharing Redis with Gateways using Distributed Rate Limiting (DRL). Non-DRL Gateways now properly ignore DRL update messages instead of attempting to process them, enabling mixed rate-limiter deployments across shared Redis instances.
Fixed an issue where a Data Plane Gateway could fail to load API definitions the MDCB link failed during initialisation. This would lead to client requests returning HTTP 404 errors. The expected behaviour, if MDCB is unavailable, is for the Data Plane Gateway to retrieve policies and API definitions from the local storage (Redis), but this was not occurring in certain scenarios. We have improved the robustness of the Gateway startup so that, if MDCB goes down, it will automatically switch to the local storage (Redis) as expected.
Fixed an issue where Tyk Gateway advertised leaf certificate Subject DNs instead of Certificate Authority DNs during mTLS handshakes, causing connection failures with RFC-compliant TLS clients. The Gateway now properly extracts and advertises CA DNs from certificate chains in the CertificateRequest message, ensuring compatibility with standards-compliant clients like Apache mod_ssl while maintaining backward compatibility with existing configurations.
We fixed a logging bug in the JSON formatter that could cause error logs to fail to serialize when an error message contained very large numeric values (for example a big integer), which sometimes resulted in missing or broken log output; the formatter now writes the error as a plain text string instead of attempting to encode the underlying error object, so logs reliably serialize to JSON.
Fixed an issue where the Gateway would incorrectly retry RPC calls repeatedly when MDCB is unavailable, but the DNS hasn’t changed. This would cause API requests to block for over 90 seconds before returning an error. Now it takes into account the fact that DNS has not changed and so fails fast, entering Emergency Mode after one retry (30 seconds).
Fixed redundant boolean enum definitions in OpenAPI specification by removing unnecessary enum: [true, false] declarations from boolean type fields in swagger.yml files. Boolean parameters now use only type: boolean, following OpenAPI best practices.
Resolved an issue where JWT APIs using Keycloak authentication experienced significant delays on hybrid gateways due to failed local key lookups. The gateway was unable to find OAuth client keys in local Redis and had to fetch them from the control plane on every request, causing performance degradation and “key not found” errors in logs. JWT API requests now retrieve keys efficiently from local storage, eliminating unnecessary round-trip requests and providing consistent response times.
Fixed blocking synchronous RPC calls in the request pipeline that occurred every 10 minutes during organization expiry checks when MDCB was unavailable. The organization expiry validation is now asynchronous and non-blocking, preventing API request timeouts and latency spikes (up to 90 seconds) when MDCB connectivity issues occur. This ensures consistent API response times regardless of MDCB availability status.
Resolved an issue where Tyk Gateway would crash when multiple users simultaneously accessed APIs with JWT claims validation enabled. The Gateway now processes JWT validation configurations once during API startup instead of during each request, eliminating the race conditions that caused service interruptions under concurrent load.
Resolved an issue where API keys continued to process traffic even after being marked as inactive through API updates.

​
5.10 Release Notes

​
5.10.2 Release Notes

​
Release Date 2 December 2025

​
Release Highlights

This is a version bump to align with Dashboard v5.10.2, no changes have been implemented in this release.

​
Breaking Changes

There are no breaking changes in this release.

​
Dependencies

Compatibility Matrix For Tyk Components
3rd Party Dependencies & Tools
Given the potential time difference between your upgrade and the release of this version, we recommend users verify the ongoing support of third-party dependencies they install, as their status may have changed since the release.

​
Deprecations

There are no deprecations in this release.

​
Upgrade instructions

If you are upgrading to 5.10.2, please follow the detailed upgrade instructions.

​
Downloads

Please note that the Tyk Helm Charts are configured to install the LTS version of Tyk Gateway. You will need to modify them to install v5.10.2.

​
Changelog

No changes in this release.

​
5.10.1 Release Notes

​
Release Date 19 November 2025

​
Release Highlights

This patch release contains various bug and security fixes. For a comprehensive list of changes, please refer to the detailed changelog.

​
Breaking Changes

There are no breaking changes in this release.

​
Dependencies

Compatibility Matrix For Tyk Components
3rd Party Dependencies & Tools
Given the potential time difference between your upgrade and the release of this version, we recommend users verify the ongoing support of third-party dependencies they install, as their status may have changed since the release.

​
Deprecations

There are no deprecations in this release.

​
Upgrade instructions

If you are upgrading to 5.10.1, please follow the detailed upgrade instructions.

​
Downloads

Please note that the Tyk Helm Charts are configured to install the LTS version of Tyk Gateway. You will need to modify them to install v5.10.1.

​
Changelog

Fixed
Fixed an issue where Custom Authentication could fall back to a previously configured alternative authentication method if the custom plugin bundle was not loaded. Now this is treated as for any other failed plugin load, and requests to the API will be rejected with HTTP 500 Internal Server Error to prevent access to an improperly configured endpoint.
Fixed an issue where the Gateway would load and attempt to use plugin bundles even when the manifest file was invalid or missing. The Gateway now properly validates bundle manifests and fails safely by rejecting API requests when bundles cannot be properly loaded or verified. This prevents risks from corrupted or tampered bundles and ensures that APIs with invalid plugin configurations are not accessible, maintaining the integrity of authentication and authorization checks implemented by plugins.
Fixed an issue where keys could remain deactivated when a policy applied to them was changed from draft to active status. When an access key/token is presented to Tyk in a request, policies linked to the key will be applied, configuring the authorization for that request. If any policy is in draft state, the key will be rejected. Toggling the policy to the active state should activate any keys to which the policy is applied. Previously, if the policy had never been applied when it was in draft state, there was an issue where keys would incorrectly be marked as inactive. This has now been resolved, and the policy state is correctly mapped to keys.
Added a new configuration option, HttpServerOptions.MaxResponseBodySize to limit the maximum size of the response bodies processed during any response body transformations. When the limit is exceeded, the Gateway returns HTTP 500 Response Body Too Large instead of attempting to process the oversized content.
Fixed an issue where plugin loading failure errors were ignored for gRPC, Python, and Lua plugins, allowing API requests to be processed even when plugins failed to load. The Gateway now properly validates plugin drivers during request processing and fails safely by returning HTTP 500 Internal Server Error when any plugin fails to load, ensuring consistent behavior across all plugin types.
Fixed an issue where a Tyk Classic API with inconsistent versioning configuration would process requests using a random version’s configuration.A non-versioned API should:
  • Contain a single entry in version_data.versions with the API configuration.
  • Have the version_data.not_versioned flag set to true.
Previously, if multiple entries existed in the version_data.versions array while not_versioned was set to true, the Gateway would randomly select one of those versions to process incoming requests.New behavior:When version_data.not_versioned is set to true and multiple versions are present, Tyk now deterministically selects the configuration for the default version instead of picking one at random.Tyk determines the default version as follows:
  • First, it looks for an entry named "Default".
  • If not found, it checks for "default".
  • If neither exists, it checks for an entry with an empty string key ("").
  • If none of these are found, Tyk returns an error, indicating a misconfigured non-versioned API.
Tyk Gateway now validates all file paths in zip bundles before extraction, rejecting bundles that contain invalid paths. Bundle extraction fails immediately upon detecting invalid paths, with detailed error logging, ensuring that only proper bundles with valid relative paths are processed.
Fixed an issue where a Data Plane Gateway could hang for all client requests when the MDCB connection was lost. This was caused by the Gateway incorrectly checking the Organisation quota when TYK_GW_ENFORCEORGQUOTAS was not set. If the Organisation quota cache expired before the Gateway performed a health check, the Gateway could hang.From this release, the Gateway does not check the Organisation quota cache if this is not set. For users relying on Organisation quotas (setting TYK_GW_ENFORCEORGQUOTAS=true), the scenario is different and the lock does not occur.
Security Fixes

​
5.10.0 Release Notes

​
Release Date 13th October 2025

​
Release Highlights

For a comprehensive list of changes, please refer to the detailed changelog.
OpenAPI Compliant Multi-Authentication for Tyk OAS APIs
Tyk Gateway now supports true OpenAPI specification compliant authentication workflows, giving developers the flexibility to implement industry-standard security patterns while maintaining backward compatibility. OpenAPI compliant authentication brings:
  • Multiple authentication paths: Process all entries in the OpenAPI security section, not just the first one
  • Flexible security combinations: Enable authentication scenarios like “OAuth2 OR Auth Token” where clients can choose their preferred method
  • Proprietary method integration: Seamlessly combine standard OpenAPI authentication with Tyk’s proprietary methods (Custom Authentication plugin, HMAC) using the same flexible logic
  • Standards compliance: Follow OpenAPI security specification patterns that developers expect
Backward compatibility guaranteed:
  • Legacy mode preserved: Existing APIs continue to work unchanged with the current AND-only logic
  • Opt-in enhancement: Switch to compliant mode via the securityProcessingMode configuration when ready
  • No breaking changes: Existing multi-security configurations remain functional
Real-world applications
  • Support diverse client authentication capabilities within the same API
  • Implement progressive authentication strategies (basic → advanced security)
  • Align with OpenAPI tooling and documentation expectations
  • Reduce integration complexity for API consumers
Perfect for organizations wanting to leverage standard OpenAPI security patterns while maintaining the flexibility of Tyk’s advanced authentication features. For more details, please see the dedicated Multi Auth section.
Comprehensive JWT Claim Validation for Tyk OAS APIs
Tyk Gateway now provides enterprise-grade JWT validation capabilities exclusively for Tyk OAS APIs, enabling complete control over token validation beyond basic expiry and signature checks. Complete registered claim validation
  • Multi-Identity Provider support: Validate issuer, audience, and subject claims against multiple allowed values
  • Flexible claim mapping: Configure different claim names for subject, policy, and scope mapping to support various Identity Providers (Keycloak, Okta, Auth0, etc.) within the same API
  • JWT ID enforcement: Require unique token identifiers for enhanced security
Advanced custom claim validation
  • Flexible validation rules: Define validation for any JWT claim using required, exact match, or containment rules
  • Rich data type support: Handle strings, numbers, booleans, and arrays with nested claim access using dot notation
  • Non-blocking validation: Monitor claim compliance without rejecting requests, perfect for gradual policy enforcement
Real-world applications
  • Role-based access control with custom permission claims
  • Department or organization-based API access restrictions
  • Multi-tenant scenarios with flexible claim validation
  • Gradual migration from legacy authentication systems
This enhancement makes Tyk’s JWT middleware the primary validation mechanism for complex enterprise authentication scenarios, providing the flexibility needed for modern Identity Provider integrations while maintaining backward compatibility. Ideal for organizations that require sophisticated JWT validation beyond standard token checks. For more details, please see the dedicated JWT Auth section.
Advanced JWKS Cache Management for Tyk OAS APIs
Tyk Gateway now provides comprehensive JWKS (JSON Web Key Set) cache control for Tyk OAS APIs, delivering significant performance improvements and operational flexibility for JWT validation workflows with:
  • Configurable cache timeouts: Set custom cache durations per Identity Provider to match their key rotation schedules
  • On-demand cache invalidation: Instantly refresh cached keys for any API (Classic or OAS) when Identity Providers rotate their signing keys
  • Intelligent pre-fetching: Eliminate first-request latency by fetching JWKS data during Tyk OAS API initialization
Key benefits
  • Faster JWT validation with reduced Identity Provider round-trips
  • Zero cold-start delays for JWT-protected endpoints
  • Immediate response to Identity Provider key rotations
  • Better performance in high-traffic JWT validation scenarios
This enhancement is particularly valuable for organizations migrating to Tyk OAS APIs or those requiring consistent low-latency JWT validation performance with multiple Identity Providers that have different key rotation policies. For more details, please see the JWT Auth section.
Centralized External Service Configuration
Tyk Gateway now provides unified configuration for all external service connections through the new external_services section. This enhancement brings together previously scattered and incomplete configuration options into a single, coherent system that supports:
  • Proxy configuration: Apply proxy settings globally or per service, with automatic support for standard environment variables (HTTP_PROXY, HTTPS_PROXY, NO_PROXY)
  • mTLS certificate management:Centralized certificate configuration for secure connections to external services
  • Comprehensive service coverage: Covers all external integrations, including databases, OAuth providers, and webhook endpoints
This improvement simplifies deployment in enterprise environments where proxy servers and certificate management are critical, while maintaining full backward compatibility with existing configurations. Key benefits
  • Reduced configuration complexity and duplication
  • Better security through centralized certificate management
  • Simplified proxy configuration for containerized deployments
  • Consistent external service connection handling across all Tyk components
For more details, please see the dedicated section.
Proactive Certificate Expiry Monitoring
Tyk Gateway now automatically monitors certificate health and proactively alerts administrators before certificates expire, helping prevent service outages caused by expired mTLS certificates. The new certificate monitoring system provides:
  • Early warning notifications: Configurable alerts when certificates approach expiry (default: 30 days)
  • Immediate expiry detection: Real-time notifications when expired certificates are detected in use
  • Comprehensive coverage: Monitors certificates used in both client-to-Gateway and Gateway-to-upstream connections
  • Smart throttling: Built-in cooldown mechanisms prevent alert flooding while ensuring visibility
These events integrate seamlessly with existing monitoring and alerting systems through Tyk’s standard event framework, enabling teams to set up automated workflows for certificate renewal and replacement. Key benefits
  • Prevent unexpected API outages due to expired certificates
  • Reduce manual certificate monitoring overhead
  • Enable proactive certificate lifecycle management
  • Improve overall API reliability and uptime
Perfect for organizations managing multiple certificates across complex API infrastructures where manual tracking becomes impractical. For more details, please see the dedicated Gateway events section.

​
Breaking Changes

There are no breaking changes in this release.

​
Dependencies

Compatibility Matrix For Tyk Components
3rd Party Dependencies & Tools
Given the potential time difference between your upgrade and the release of this version, we recommend users verify the ongoing support of third-party dependencies they install, as their status may have changed since the release.

​
Deprecations

There are no deprecations in this release.

​
Upgrade instructions

If you are upgrading to 5.10.0, please follow the detailed upgrade instructions.

​
Downloads

Please note that the Tyk Helm Charts are configured to install the LTS version of Tyk Gateway. You will need to modify them to install v5.10.0.

​
Changelog

Added
Added OpenAPI Specification compliant multi-authentication support for Tyk OAS APIs, providing flexible authentication workflows that follow standard OpenAPI security patterns.Compliant mode (new)
  • Processes all entries in the OpenAPI security section sequentially, not just the first entry
  • Supports a local security section in the Tyk vendor extension for proprietary authentication methods (Custom Authentication plugin, HMAC)
  • Uses AND logic within each security entry and OR logic between entries, enabling flexible authentication combinations such as: OAuth2 OR Auth Token
  • Allows clients to authenticate using any of the defined security combinations
Legacy mode (existing behavior)
  • Continues to use only the first entry from the OpenAPI security section
  • Combines all declared methods with proprietary vendor extension methods using AND logic
  • Requires clients to satisfy ALL authentication methods
The authentication processing mode is controlled by the new server.authentication.securityProcessingMode field in the Tyk Vendor Extension, with legacy as the default to ensure backward compatibility. In compliant mode, proprietary authentication methods are configured in the new server.authentication.security section within the vendor extension, following the same array structure as the OpenAPI security section. This prevents breaking changes for existing API definitions that contain multiple entries in the security section but were designed for legacy processing behavior.
Tyk OAS APIs now support comprehensive validation of JWT registered claims, extending beyond basic token validation to provide complete access control capabilities. This enhancement includes:Registered claim validation
  • Subject, issuer, and audience validation: Validate tokens against allowed values with support for multiple entries per claim type
  • JWT ID enforcement: Require presence of unique token identifiers (jti) when needed
  • Flexible claim mapping: Configure different claim names for subject, base policy, and scope-to-policy mapping to support multiple Identity Providers within the same API setup (e.g., Keycloak’s scope vs Okta’s scp)
Custom claim validation framework
  • Flexible validation rules: Define validation for any custom JWT claim using three rule types: required (claim must exist), exact_match (claim equals specific values), or contains (claim contains specific values)
  • Advanced data support: Handle string, number, boolean, and array data types with nested claim access using dot notation (e.g., user.department)
  • Non-blocking validation: Configure rules to log warnings instead of rejecting requests for monitoring and gradual enforcement scenarios
These features enable advanced use cases, such as role-based access control, department validation, and custom permission schemes, while maintaining backward compatibility with existing JWT configurations.Note: Available only for Tyk OAS APIs and configured directly in the API definition via the Tyk Vendor Extension.
Enhanced the JWKS (JSON Web Key Set) caching system with three key improvements to reduce latency and provide better control over JWT validation:Configurable cache timeout - Tyk OAS APIs can now specify custom cache timeout values for JWKS endpoints in their JWT validation configuration, allowing fine-tuned control over cache refresh intervals based on Identity Provider requirements.
  • Cache invalidation API - Administrators can now manually invalidate JWKS cache entries via new Gateway API endpoints (DELETE /tyk/cache/jwks/{apiID} and DELETE /tyk/cache/jwks), either targeting specific APIs or purging all cached JWKS data. This enables immediate cache refresh when Identity Provider keys are rotated.
  • Automatic pre-fetching - For Tyk OAS APIs, JWKS data is now automatically fetched and cached when API definitions are loaded, eliminating cold-start delays for JWT validation. Pre-fetching includes comprehensive logging of fetch attempts and results, and failures do not prevent API initialization.
Note: For Tyk Classic APIs, JWKS caching behavior remains unchanged with on-demand fetching during token validation using the default cache timeout (60 seconds). Cache invalidation via the new API endpoints works for both Classic and OAS APIs.These enhancements improve JWT validation performance for Tyk OAS APIs and provide administrators with better tools for managing JWKS cache lifecycle when Identity Provider keys change.
Added a new external_services section in the Gateway configuration to provide centralized configuration for proxy settings and mTLS certificates when communicating with external services. This includes connections to persistent and temporal storage, OAuth 2.0 Authorization Servers, and webhook targets.Tyk Gateway can now apply proxy settings from standard environment variables (HTTP_PROXY, HTTPS_PROXY, NO_PROXY) or use the new granular configuration options. All existing configuration methods remain supported, including legacy options such as jwt_ssl_insecure_skip_verify and http_proxy.
Introduced a proactive event system to warn administrators when mTLS certificates are approaching expiry. The Gateway now emits two new API events to provide visibility into certificate status:
  • CertificateExpiringSoon - Generated when a certificate is used in an API request (either client-to-Gateway or Gateway-to-upstream) within a configurable time period of its expiry date
  • CertificateExpired - Generated when an attempt is made to use an already expired certificate, in addition to the standard error response sent to the API client
A cooldown mechanism prevents event flooding by throttling the generation of these notifications. The threshold for the CertificateExpiringSoon event and cooldown parameters are configured in the Gateway configuration:
The default threshold is 30 days before expiry.
Changed
Fixed
Fixed an issue where sending certain unexpected query parameters to the GET /tyk/apis/oas/{id} endpoint could cause a panic.
Fixed an issue where importing an OpenAPI description with an apiKey security scheme, while using the authentication query parameter, resulted in the unnecessary generation of a header object within the Tyk Vendor Extension (x-tyk-api-gateway), duplicating information already present in the declared OpenAPI security scheme.
Fixed an issue where Tyk OAS mock response middleware failed to execute when internal API proxying was enabled. Mock responses configured in the target API are now correctly returned when a request is redirected to another API on the same Tyk Gateway instance via internal looping.
Fixed an issue where CORS settings from the base API were incorrectly applied to all versions of a Tyk OAS API, preventing child API versions from using their own CORS configuration. This occurred because the CORS check was performed before the request was routed to the correct API version.The processing order has been corrected so that requests are first routed to the appropriate version (base or child), then the correct CORS settings are applied, allowing each API version to have its own CORS configuration.
Fixed an issue where Response Body Transformation middleware failed to apply to endpoints that used URL rewrite with regex patterns. When the endpoint path contained regex metacharacters (e.g., $, ^, (), []), these characters interfered with the body transformation’s internal pattern-matching process, preventing the middleware from executing.
Resolved an issue where the Gateway automatically converted Readable Duration values (such as uptime test timeouts) in Tyk OAS API definitions from integer-based formats to decimal formats, which triggered schema validation warnings. The effect of this was seen in the Tyk OAS API editor in the Dashboard UI where, for example, a duration of ‘4s500ms’ would be converted to ‘4.5s’ when reopening an API definition.Duration values are now consistently serialized and maintained in their original, integer-based format, preventing these validation errors.
Fixed an issue where Tyk Gateway did not properly apply the configured TLS settings when connecting to Redis for rate limiting operations. This could result in connection failures and incorrect HTTP 429 Too Many Requests responses being returned to clients. The rate limiter now correctly establishes TLS connections to Redis.
Fixed a bug where deleting an API with the Uptime Test feature enabled could cause the Gateway to crash due to a nil pointer dereference during cleanup operations. The Gateway now properly handles memory cleanup when removing APIs with active uptime tests, preventing crashes and ensuring stable API lifecycle management.
Fixed an issue where Gateways could fail to re-register with the Dashboard after a restart, particularly during upgrades or in large-scale deployments. This resulted in Authorization failed (Nonce empty) errors and Gateway crash loops that prevented successful registration.The fix includes an updated license handler with hardened registration logic, enhanced Dashboard authentication retry mechanisms, and support for new “Unlimited Gateway” licenses, ensuring Gateways register reliably without entering failure loops even during heavy churn or rolling upgrades.
Fixed an issue that caused repeated Body decompression error: EOF log messages when analytics were enabled for GraphQL APIs. The problem occurred because the Gateway attempted to decompress the response body after it had already been consumed for analytics processing, resulting in End of File (EOF) errors.The Gateway now properly handles response body consumption for GraphQL APIs with analytics, eliminating the spurious error logs.
Fixed an issue where users could create child Tyk OAS API versions using the /tyk/apis/oas endpoint without specifying a valid version name (new_version_name). The Gateway API now rejects such requests with an HTTP 422 Unprocessable Entity error, ensuring all versions have meaningful identifiers and preventing the creation of unusable or empty version entries.
Fixed an issue where updating a Tyk OAS API via PATCH /tyk/apis/oas/{apiId} did not properly update the Tyk Vendor Extension (x-tyk-api-gateway). When endpoints were removed or modified in the OpenAPI description, their corresponding middleware definitions could persist incorrectly in the vendor extension, leaving the API definition in an inconsistent state.The vendor extension is now correctly rebuilt to reflect all changes made to the OpenAPI description.

​
5.9 Release Notes

​
5.9.2 Release Notes

​
Release Date 5th September 2025

​
Release Highlights

This is a version bump to align with Dashboard v5.9.2, no changes have been implemented in this release. For further information, please see the release notes for Dashboard v5.9.2.

​
Breaking Changes

There are no breaking changes in this release.

​
Dependencies

Compatibility Matrix For Tyk Components
3rd Party Dependencies & Tools
Given the potential time difference between your upgrade and the release of this version, we recommend users verify the ongoing support of third-party dependencies they install, as their status may have changed since the release.

​
Deprecations

There are no deprecations in this release.

​
Upgrade instructions

If you are upgrading to 5.9.2, please follow the detailed upgrade instructions.

​
Downloads

​
Changelog

Since this release was version-bumped only to align with Dashboard v5.9.2, no changes were encountered in this release.

​
5.9.1 Release Notes

​
Release Date 14th August 2025

​
Release Highlights

This release restores the stable /hello health-check behavior for Kubernetes probes. Deployments using /hello for liveness or readiness will now behave consistently again. It also fixes a schema compatibility issue in the URL Rewrite middleware, ensuring that API promotion and validation flows no longer fail due to schema mismatches. For a comprehensive list of changes, please refer to the detailed changelog.

​
Breaking Changes

There are no breaking changes in this release.

​
Dependencies

Compatibility Matrix For Tyk Components
3rd Party Dependencies & Tools
Given the potential time difference between your upgrade and the release of this version, we recommend users verify the ongoing support of third-party dependencies they install, as their status may have changed since the release.

​
Deprecations

There are no deprecations in this release.

​
Upgrade instructions

If you are upgrading to 5.9.1, please follow the detailed upgrade instructions.

​
Downloads

​
Changelog

Fixed

​
5.9.0 Release Notes

​
Release Date 4th August 2025

​
Release Highlights

This release builds on the recent release of Tyk 5.8.3, adding a collection of new capabilities. For a comprehensive list of changes, please refer to the detailed changelog.
Accept JSON Web Tokens (JWTs) Issued By Multiple Identity Providers
Tyk can now validate JWTs against multiple JSON Web Key Set (JWKS) endpoints, allowing you to use different IdPs to issue JWTs for the same API. Previously, we supported only a single JWKS endpoint in the source field, but now you can register multiple JWKS endpoints in the Tyk OAS API definition. When a request is received bearing a JWT, Tyk will retrieve JWKS from all registered IdPs to check the token’s validity, for full details of how to use this powerful feature see the improved JWT Authentication section. Please note that this functionality is not available for Tyk Classic APIs.
Compatibility with Valkey
Tyk is now fully compatible with Valkey, the open-source (BSD) high-performance key/value datastore backed by the Linux Foundation, as an alternative to Redis.
Enhancements to Tyk Streams for Enterprise Edition
We’ve added support for additional processors, inputs and outputs for Tyk Streams event driven APIs, extending the flexibility of this powerful feature.

​
Breaking Changes

1. Modified /hello endpoint behavior affects kubernetes deployments In Tyk Gateway version 5.9.0, we introduced a breaking change to the /hello health check endpoint behavior. Previously, this endpoint would always return HTTP 200 during normal operations, regardless of Redis connectivity. The change made the endpoint return HTTP 503 when Redis was unavailable (which shouldn’t be the case), which caused issues for Kubernetes deployments using this endpoint for liveness probes.
Impact
  • Kubernetes pods may be unnecessarily terminated when Redis becomes temporarily unavailable
  • Deployments using /hello for both liveness and readiness probes experience disruption
  • This contradicts the documented behavior that the Gateway continues functioning when Redis is unavailable
Expected Fix Version
This issue will be fixed in Tyk Gateway version 5.9.1, where we will:
  • Revert the /hello endpoint to its pre-5.8.3 behavior (always return HTTP 200 during normal operations)
  • Ensure backward compatibility for existing Kubernetes deployments
2. URL rewrite rules now require explicit negate field A breaking change has been identified in Tyk 5.9.0 regarding URL rewrite rules. The negate field, which was optional in previous versions, is now mandatory in all URL rewrite rule configurations.
What Changed
In Tyk 5.8.2 and earlier, the negate field in URL rewrite rules included an omitempty tag, making it optional in JSON. If not provided, it would default to false In Tyk 5.9.0, this omitempty tag has been removed, making the negate field mandatory in all URL rewrite rule configurations.
Impact
API definitions that worked in Tyk 5.8.2 will fail validation in Tyk 5.9.0 if they contain URL rewrite rules without an explicit negate field. This may cause API updates, or promotion between environments failures between environments with error messages similar to:
Workarounds
When using Tyk 5.9.0, you must explicitly include the negate field in all URL rewrite rules:
Set negate: false for standard matching behavior, or negate: true
Expected fix version
This issue will be fixed in Tyk 5.9.1, where we’re going to make negate field optional again.

​
Dependencies

Compatibility Matrix For Tyk Components
3rd Party Dependencies & Tools
Given the potential time difference between your upgrade and the release of this version, we recommend users verify the ongoing support of third-party dependencies they install, as their status may have changed since the release.

​
Deprecations

There are no deprecations in this release.

​
Upgrade instructions

If you are upgrading to 5.9.0, please follow the detailed upgrade instructions.

​
Downloads

​
Changelog

Added
Added compatibility with Valkey database as an alternative to Redis. This is for fresh environments, with no migration support from Redis.
Added support for configuration of multiple JWKS (JSON Web Key Set) endpoints in the Tyk OAS API definition. This enables the Gateway to authenticate JSON Web Tokens (JWTs) in multi-identity provider environments. The JWKS endpoints are configured in the new jwksURIs array in the JWT Auth securityScheme. This will take precedence over the existing source field, and existing API definitions will be automatically migrated to use the new field, while maintaining backward compatibility in case of rollback.
Enabled configuration for GraphQL SSE subscriptions to use POST requests instead of GET, addressing compatibility issues with upstream servers that require POST. We’ve added a new option proxy.sse_use_post which can be set if proxy.subscription_type=sse to cause Tyk to issue POST requests. This allows for larger subscription payloads and keeps the subscription payload out of the URL.
Added support for AMQP (0.9 and 1.0) and MQTT to be used for input and output methods when constructing Tyk Streams APIs.
Added support for Bloblang to be used as a new processor option for Tyk Streams APIs.
Added the missing KeyID field to the coprocess SessionState proto, allowing gRPC plugins to access it and aligning it with the Go SessionState struct. This enables full feature parity for custom authentication and session management in gRPC plugins.
Changed

​
5.8 Release Notes

​
5.8.15 Release Notes

​
Release Date 30 June 2026

​
Release Highlights

This patch implements several changes and fixes to improve the stability and correct the behavior of the Gateway. The default content of application logs has been updated with RFC3339 format timestamp and consistent formatting with other components. This could be a breaking change for any user whose tooling relies on the specific content of application logs. A legacy mode is available, as described below. For a comprehensive list of changes, please refer to the detailed changelog below.

​
Breaking Changes

Changes to application logs This release makes changes to the format of Tyk Gateway application logs so that output is consistent with other Tyk components and aligned with industry observability standards.
This is only a breaking change if you specifically rely on the current log format: for example, if your monitoring, parsing, or alerting tools are built around the existing timestamp format or the entire message.
Mitigation: A new legacy option has been added to the log_format configuration. This setting preserves the format used prior to Tyk Gateway 5.8.15, with the historical timestamp format and lack of a field identifying for the originating API.

​
Dependencies

Compatibility Matrix For Tyk Components
3rd Party Dependencies & Tools
Given the potential time difference between your upgrade and the release of this version, we recommend users verify the ongoing support of third-party dependencies they install, as their status may have changed since the release.

​
Deprecations

There are no deprecations in this release.

​
Upgrade instructions

If you are upgrading to 5.8.15, please follow the detailed upgrade instructions.

​
Downloads

​
Changelog

Fixed
We have made changes to the format of Tyk Gateway application logs to make them consistent with logs generated by other Tyk components and aligned with industry observability standards.
  • RFC3339 timestamps: Log entries now consistently use the industry-standard RFC3339 timestamp format (e.g. 2024-12-12T13:59:08Z), previously a mix of timestamp formats was used.
ConfigurationThe log_format configuration option now accepts three explicit values:
  • text: plain-text logs in the new format introduced in this release (new default).
  • json: JSON logs in the new format.
  • legacy: preserves the format used prior to Gateway 5.8.15, with the historical timestamp format.
This is a breaking change for any user whose monitoring or log-parsing tools rely on the specific format of the Tyk Gateway application logs. If you require the previous timestamp format, you should set log_format to legacy.
When the Gateway control API is moved to a separate port via control_api_port, requests to the proxy/data API port that did not match any configured API (generating an HTTP 404 response) were silently dropped: no log entry was generated even with track_404_logs enabled. This has been fixed; 404 logs are now correctly emitted for unmatched requests on all listening ports.Additionally, a host field has been added to 404 log entries (when using text or json log_format). This records the Host header from the request, allowing users to distinguish whether the unmatched request was directed at the proxy API or the control API.
Resolved a risk of unbound memory consumption for APIs using gRPC plugins. The leak was due to an internal regular-expression cache that could grow without limit when Session access rights contained per-user URL patterns, and excessive memory churn when copying large sessions on every request. The fix bounds the maximum size of the cache and reuses Session objects to eliminate the churn. The Gateway now also aligns GOMAXPROCS with the container’s CPU quota at startup.This fix introduces the following new configuration options:
Under sustained high-concurrency traffic to OIDC, JWT, or Auth-key protected APIs - particularly when the local session cache was disabled - the Gateway could crash with a fatal concurrent map iteration and map write panic. This caused unexpected pod restarts, in-flight request loss, and intermittent cluster instability.This has been fixed. The temporary workaround of enabling the local session cache (disable_cached_session_state: false) is no longer required.
The Gateway’s min_token_length configuration is intended to prevent the use of API tokens (keys) that are insecure due to their length. All tokens presented during a request to an API are checked against this value and immediately rejected with HTTP 403 if shorter than the configured minimum length.Previously, a token with length equal to min_token_length would be rejected with HTTP 403, which is non-intuitive and can lead to wasted debugging time.Also, it was possible to create a custom key shorter than the configured minimum length. The Session would be created, but the key would be unusable as any attempt to use it in a request would be rejected due to the token’s length.Now, tokens with length exactly equal to min_token_length are correctly accepted and an attempt to create a custom key shorter than min_token_length fails immediately with a 400 Bad Request.
Resolved an issue where, when a GraphQL API was configured with strip_auth_data set to false, the client’s authentication header (for example Authorization, or a custom header such as X-API-KEY) was not forwarded to the upstream service. This affected all GraphQL execution modes (proxy-only (including WebSocket subscriptions), subgraph, Universal Data Graph, and supergraph) leaving upstream services that require the header unable to authenticate the request.The active authentication method’s header is now propagated upstream across all execution modes, with only the active method’s header forwarded. In addition, upstream WebSocket connections for subscriptions are no longer reused across clients presenting different credentials, so each subscription carries its own authentication header, and one client’s token can no longer leak to another. When strip_auth_data is true, no authentication headers are forwarded, as before.
Tyk 5.8.14 introduced a change in the behavior of the health endpoints when Tyk Gateway is deployed in the Control Plane. If Redis goes down and the Tyk Dashboard is still available, the Gateway’s health endpoints can incorrectly report that everything is healthy.The Gateway regularly polls for the availability of Dashboard and Redis, caching the status and reporting this when the health endpoints are called. The cache is only updated once both checks are complete and, as a side effect of the fix applied in 5.8.14 to address an issue with the Gateway registration with Dashboard, it was possible for the checks to loop infinitely until Redis was available, such that the cached status was never updated with a “Redis down” message.The Control Plane Gateway’s health endpoints now correctly report the most recent snapshot of Dashboard and Redis availability.
Tyk 5.8.1 introduced a fix for an issue where an enforced timeout set for a specific API endpoint could be overruled by the configured proxy_default_timeout. A side effect of this fix was to uncover a race condition seen when an API has multiple endpoints with different enforced timeouts. The Gateway could incorrectly set the request timeout for all endpoint paths based on the first request received. This has now been resolved and requests to each endpoint are assigned the expected timeout.
Security Fixes

​
5.8.14 Release Notes

​
Release Date 21 May 2026

​
Release Highlights

This patch implements several changes and fixes to improve the stability and correct the behavior of the Gateway. The default minimum and maximum TLS versions are now inherited directly from the underlying Go library, ensuring that Tyk users will benefit from best practice. If non-standard defaults are required, these must be deliberately configured. We have fixed an issue that was preventing CORS preflight checks from running properly if an allow list was in use and various other issues in observability, internal looping, and Gateway stability. For a comprehensive list of changes, please refer to the detailed changelog below.

​
Breaking Changes

Default maximum and minimum TLS versions are now inherited from the underlying Golang library and so will be TLS 1.3 and TLS 1.2 respectively (previously were both set to TLS 1.2). You must set http_server_options.max_version (or the equivalent environment variable) to 771 if you require an upper limit of TLS 1.2. See here for details how to control TLS version and cipher suites. Query parameters from original request are no longer automatically preserved when looping using tyk:// protocol) We have fixed an inconsistent behavior when using the URL rewrite middleware to loop requests using the Tyk protocol (tyk://api-id/path). Previously, query parameters added to the rewrite_to URL were silently dropped, while original request parameters were automatically preserved in the looped request. This behavior was inconsistent with standard HTTP URL rewrites and prevented proper parameter transformation during internal API routing. Impact
  • Original request query parameters are no longer automatically forwarded through internal loops
  • Existing URL rewrite configurations may lose query parameters that were previously passed through automatically
  • APIs relying on automatic parameter forwarding will receive incomplete requests
Migration Required Update your URL rewrite configurations to explicitly include any original query parameters you want to preserve. For example:
  • Before: "rewrite_to": "tyk://api-123/endpoint" (original params auto-forwarded)
  • After: "rewrite_to": "tyk://api-123/endpoint?param1=$tyk_context.request_data.param1"

​
Dependencies

Compatibility Matrix For Tyk Components
3rd Party Dependencies & Tools
Given the potential time difference between your upgrade and the release of this version, we recommend users verify the ongoing support of third-party dependencies they install, as their status may have changed since the release.

​
Deprecations

There are no deprecations in this release.

​
Upgrade instructions

If you are upgrading to 5.8.14, please follow the detailed upgrade instructions.

​
Downloads

​
Changelog

Fixed
We have resolved an issue where “Client TLS certificate is required” errors were logged at warning level, creating unnecessary noise in production logs.Previously, these common client-side authentication failures generated excessive warning-level log entries that could trigger false alerts and obscure more critical issues. The Gateway now logs these authentication failures at info level, maintaining security visibility while reducing log noise and alert fatigue for operations teams.
We have resolved an issue where a Go plugin returning an error status code would result in malformed response bodies that concatenated the original plugin response with additional Gateway error messages.The Gateway now correctly handles plugin-generated error responses without double-writing headers, ensuring response bodies contain only the payload generated by the plugin and eliminating superfluous warnings in logs.
We have resolved inconsistent query parameter handling in URL rewrites when internally routing using the tyk:// scheme. Previously, custom query parameters specified in the rewrite_to URL were silently dropped, while original request parameters were unexpectedly preserved.What’s Fixed:
  • Query parameters explicitly added to rewrite_to URLs are now correctly passed to target APIs
  • Control parameters (method, loop_limit, check_limits) are properly consumed and removed
  • Behavior now matches URL rewrites using http:// protocol
It is important to note that query parameters provided with the original request are no longer automatically forwarded. You must update your URL rewrite configuration to explicitly include any required parameters in the rewrite_to URL.
We have resolved an issue where a Tyk Gateway acting as a client (using upstream mTLS) would fail to authenticate against another Tyk Gateway acting as the mTLS server, resulting in HTTP 403 Forbidden: Client TLS certificate is required errors.The Gateway now reliably presents the configured upstream client certificate whenever requested by the target server, ensuring seamless mTLS communication between APIs hosted on different Tyk Gateways.
We have resolved an issue where the Tyk Gateway default maximum TLS version was incorrectly set to TLS 1.2 instead of TLS 1.3.Tyk Gateway now follows Go’s native TLS defaults (TLS 1.2 minimum, TLS 1.3 maximum), aligning with industry security standards. This maintains full backward compatibility for existing deployments that explicitly configure TLS versions.To change the maximum TLS version, you must explicitly set TYK_GW_HTTPSERVEROPTIONS_MAXVERSION for client-to-Gateway connections or TYK_GW_PROXYSSLMAXVERSION for Gateway-to-upstream connections.To change the minimum TLS version, you must explicitly set TYK_GW_HTTPSERVEROPTIONS_MINVERSION for client-to-Gateway connections or TYK_GW_PROXYSSLMINVERSION for Gateway-to-upstream connections.For full details of TLS version configuration see here.
We have resolved an issue where CORS preflight OPTIONS requests were incorrectly blocked by the AllowList middleware when options_passthrough was disabled.Previously, when APIs had CORS enabled with Tyk handling OPTIONS requests internally (options_passthrough: false), preflight requests would fail AllowList validation because users typically don’t explicitly define OPTIONS endpoints in their AllowList configurations, causing “Requested endpoint is forbidden” errors.The Tyk Gateway now properly recognizes CORS preflight requests and allows them to bypass AllowList middleware checks when Tyk is configured to handle OPTIONS internally, restoring the expected behavior where CORS preflight handling works automatically without requiring explicit OPTIONS endpoint definitions.
We have resolved an issue where Tyk OAS APIs with mock endpoints stopped generating analytics data. This functionality was inadvertently broken while fixing an unrelated internal API proxying issue in Tyk Gateway 5.8.6.Note that analytics are not generated for mock endpoints in Tyk Classic APIs as has always been the case.
We have resolved an issue where OpenTelemetry settings could only be set using environment variables and not the Gateway configuration file (tyk.conf).Now OpenTelemetry can be configured via the opentelemetry section in the Gateway config file (including enabled, exporter, and endpoint fields) or their equivalent environment variables.
We have fixed an issue where the Gateway could fail to load APIs and policies if the Control Plane database was temporarily unavailable during startup (either directly or via MDCB). The Gateway will now automatically retry loading configurations with exponential backoff until successful, restoring self-healing capabilities without requiring a manual restart.
We have resolved an issue where requests with the application/soap+xml Content-Type received JSON-formatted error responses instead of the expected XML format. The Gateway now correctly returns XML-formatted errors for SOAP requests.
We have resolved a set of related issues affecting Gateway registration with the Dashboard at scale for deployments using an unlimited node license. During mass registrations or rolling upgrades, a combination of lock contention, excessive Redis load, and incorrect handling of 409 Conflict responses could leave Gateways stuck in registration loops without the credentials needed to serve traffic.Gateway registration is now significantly more robust at scale: registration requests are no longer serialized across the fleet, Gateways recover cleanly from transient 409 Conflict responses instead of looping, and the Redis load generated during registration storms is substantially reduced.A dedicated fix for limited node license deployments will be provided in an upcoming release.
Resolved an issue where the Distributed Rate Limiter’s cache cleanup stopped running after its first execution. This could cause unbounded memory growth on APIs using rate limits with high-cardinality keys (such as per-client-IP rate limiting or custom plugins generating unique keys), and could briefly reset active rate-limit buckets shortly after Gateway startup, allowing requests that should have been blocked to pass through. Memory usage now stays bounded, and rate limits are enforced as configured.
Security Fixes
We have addressed CVEs reported in dependent libraries, providing increased protection against security vulnerabilities, including, but not limited to:

​
5.8.13 Release Notes

​
Release Date 22 April 2026

​
Release Highlights

Tyk Gateway has been updated to Go 1.25 and Debian 13 (Trixie) for enhanced security and performance, including updated FIPS-compliant images. This release addresses multiple CVEs in dependent libraries and resolves a path matching inconsistency for Tyk OAS APIs. It also resurrects two fixes that have been missing since Tyk 5.8.6. For a comprehensive list of changes, please refer to the detailed changelog.

​
Breaking Changes

There are no breaking changes in this release

​
Dependencies

Compatibility Matrix For Tyk Components
3rd Party Dependencies & Tools
Given the potential time difference between your upgrade and the release of this version, we recommend users verify the ongoing support of third-party dependencies they install, as their status may have changed since the release.

​
Deprecations

No deprecations in this release.

​
Upgrade instructions

If you are upgrading to 5.8.13, please follow the detailed upgrade instructions.

​
Downloads

​
Changelog

Changed
The Tyk Gateway has been updated to Golang 1.25, improving security by staying up-to-date with Go versions.
Updated the Docker images for Tyk Gateway to Debian 13 (Trixie) to address multiple vulnerabilities in the underlying operating system.
Fixed
Resolved an issue where parameterized paths could incorrectly take precedence over static paths when using the Request Validation or Mock Response middleware in Tyk OAS APIs. Static paths will now correctly bypass these middleware if not explicitly configured, restoring the expected routing behavior.
Reverted the change introduced in versions 5.9.0 and 5.8.3 to the /hello health check endpoint, restoring its original functionality. This fix resolves an issue where the endpoint returned a 503 error when Redis was down. The /hello endpoint now correctly returns HTTP 200 during normal operations, ensuring compatibility with Kubernetes liveness and readiness probes.This issue was originally fixed in Tyk 5.8.4 but then was omitted from Tyk 5.8.6 onwards
Security Fixes
Addressed the following CVEs, providing increased protection against security vulnerabilities, including, but not limited to:

​
5.8.12 Release Notes

​
Release Date 11 March 2026

​
Release Highlights

In this release, we have fixed some discrepancies in the path matching decision making for different middleware when using Tyk OAS APIs. This corrects a number of unexpected behaviors and ensures consistent application of the expected transformations and checks to API requests. We have also addressed several issues that improve API reliability, observability, and user experience. For a comprehensive list of changes, please refer to the detailed changelog.

​
Breaking Changes

A change has been made to improve security of the Auth Token + Dynamic mTLS method for securing access to APIs deployed on Tyk. This removes the option to authenticate using only the auth token and enforces the mTLS handshake. Previously API clients could authenticate without presenting the client certificate or holding the client’s private key. For any user relying on that behavior, we have added a new Gateway configuration option: allow_unsafe_dynamic_mtls_token. Unless deliberately configured in the config file or environment, this is set to false to ensure that Tyk is secure by default.

​
Dependencies

Compatibility Matrix For Tyk Components
3rd Party Dependencies & Tools
Given the potential time difference between your upgrade and the release of this version, we recommend users verify the ongoing support of third-party dependencies they install, as their status may have changed since the release.

​
Deprecations

No deprecations in this release.

​
Upgrade instructions

If you are upgrading to 5.8.12, please follow the detailed upgrade instructions.

​
Downloads

​
Changelog

Fixed
Resolved path matching inconsistencies that could lead to Tyk OAS-specific middleware not being executed when expected.These inconsistencies could see the Request Validation and Mock Response middleware being skipped in certain scenarios when using Tyk OAS APIs.These scenarios included:
  • some subpaths, for example the middleware configured for /users would not execute for /users/123
  • some child API versions
  • wildcard regexes in paths
  • root paths
Now Tyk will apply the same decisions for these middleware as for the rest of the request processing chain.
Enhanced Gateway error logging for JWT authentication failures related to JWKS endpoints. Previously, JWKS configuration issues generated vague error messages that didn’t indicate the root cause, making troubleshooting difficult and time-consuming.The Gateway now provides specific, actionable error messages that clearly identify whether failures stem from Base64 decoding issues, network connectivity problems, or invalid JWKS content.
Resolved an issue where the Gateway could crash with a panic if the API definition contained an illegal reference to a secret in HashiCorp Vault. If the requested path did not exist in Vault, the Gateway process could exit, resulting in a complete service outage during API loads, hot reloads, or Dashboard saves. The Gateway now gracefully handles the missing Vault path and logs a clear error message.
Resolved an issue where Tyk only validated the first instance of multi-value headers when processing requests to Tyk OAS APIs, allowing invalid header values to bypass schema constraints.The Gateway now properly normalizes and validates all header values according to HTTP standards, ensuring that all values in multi-value headers comply with the defined OpenAPI schema constraints.
Resolved a routing issue where APIs could return HTTP 404 Not Found errors depending on custom domain settings, with differing behavior between Tyk OAS and Tyk Classic APIs. Previously, when APIs had similar listen path prefixes (e.g., /caa and /caas2itsamu0456w2ayl9), the Gateway’s routing logic would incorrectly match requests, causing legitimate API calls to fail. The issue affected Tyk OAS APIs when custom domains were disabled, and Tyk Classic APIs when they were enabled.The Gateway now properly sorts and matches API specifications by listen path length, while correctly considering domain configuration options, ensuring all APIs are accessible via their configured paths regardless of custom domain settings or API type.
Resolved an issue where the Gateway incorrectly logged 0ms duration for error responses, including HTTP 504 Gateway Timeout, HTTP 499 Client Closed Request, and HTTP 500 Internal Server Error, creating gaps in API observability and monitoring. Previously, these error responses were hardcoded with zero-latency values, making it impossible to determine the actual processing time, gateway saturation, or connection utilization for failed requests.The Gateway now accurately calculates and logs the actual request duration from start to error occurrence for all error responses, providing complete timing visibility across successful and failed API requests. This enhancement improves observability for performance monitoring, capacity planning, and troubleshooting workflows.
Resolved an issue where OpenTelemetry traces were missing the “alias” field when using JWT-protected APIs, making it impossible to identify API consumers in tracing data. Previously, while the alias was correctly populated in Redis sessions and pump metrics, it was not included in OTEL spans for JWT-authenticated requests.The Gateway now ensures that OTEL spans include the alias attribute for all authentication methods, enabling proper consumer identification and request attribution in distributed tracing systems.
Resolved an issue where NewRelic OpenTracing integration worked inconsistently in Tyk Gateway. The Gateway now properly mounts NewRelic middleware on all routers, including reused ones, with thread-safe duplicate prevention and improved memory management during router swaps. This fix ensures consistent NewRelic APM visibility across all API calls and gateway versions, supporting both legacy NewRelic configurations and newer OpenTelemetry collector setups.
Resolved an issue where the X-RateLimit-Reset header showed an incorrect timestamp in the response to the first API request after rate limit or quota counter initialization. Previously, when quota windows expired and were reset within the distributed lock, the Gateway would return stale timing information in the first response.The Gateway now properly synchronizes its internal timer with the storage backend during quota window resets, ensuring that X-RateLimit-Reset headers accurately reflect the correct expiration time from the very first response.
Resolved a floating-point precision issue where mathematically valid multipleOf values were incorrectly rejected due to binary representation limitations. This could cause incorrect failures when performing Request Validation for Tyk OAS APIs.The Gateway now properly handles floating-point precision in multipleOf validation, ensuring that all mathematically valid decimal multiples pass validation consistently while continuing to correctly reject invalid values.
Resolved an issue where data plane gateways failed to load SSL certificates from MDCB during startup, preventing HTTPS listeners from functioning correctly. The fix implements exponential backoff retry logic that waits for the MDCB connection to become available during certificate loading, ensuring SSL certificates are properly retrieved, and HTTPS listeners start correctly. This resolves startup failures for new data plane deployments using HTTPS.
Security Fixes
The Gateway now enforces the mutual TLS handshake when an API is secured using Auth Token with Dynamic mTLS. The client must therefore present a valid client certificate in the request. Previously Dynamic mTLS would permit authentication using only the Auth Token and the mTLS handshake was not enforced.A new configuration option allow_unsafe_dynamic_mtls_token has been added for any users relying on the legacy behavior. This defaults to false.A new Gateway configuration option allow_unsafe_dynamic_mtls_token has been added for backward compatibility, but defaults to false to ensure secure behavior. When enabled, this option restores the previous (insecure) behavior of accepting token-only authentication for APIs secured with Auth Token + Dynamic mTLS.

​
5.8.11 Release Notes

​
Release Date 12 February 2026

​
Release Highlights

In this release, we have resolved a performance issue with bundle verification that significantly impacted resource consumption when using plugin bundles, and we have fixed some priority CVEs. For a comprehensive list of changes, please refer to the detailed changelog.

​
Breaking Changes

There are no breaking changes in this release.

​
Dependencies

Compatibility Matrix For Tyk Components
3rd Party Dependencies & Tools
Given the potential time difference between your upgrade and the release of this version, we recommend users verify the ongoing support of third-party dependencies they install, as their status may have changed since the release.

​
Deprecations

No deprications in this release.

​
Upgrade instructions

If you are upgrading to 5.8.11, please follow the detailed upgrade instructions.

​
Downloads

​
Changelog

Fixed
Fixed a performance issue introduced in v5.8.7 where bundle verification significantly increased CPU and memory consumption, particularly when using multiple APIs with plugin bundles.We have introduced a new Gateway configuration option skip_verify_existing_plugin_bundle that allows you to skip cryptographic verification when loading signed plugin bundles from disk. When set to true, this option reduces the performance overhead for environments with large numbers of APIs using signed bundles, while still maintaining security by validating signatures during the initial bundle download.Note: This option only affects signed bundles loaded from disk. Unsigned bundles and initial downloads will continue to follow standard verification procedures.
Security Fixes
Addressed CVEs reported in dependent libraries, providing increased protection against security vulnerabilities, including, but not limited to:

​
5.8.10 Release Notes

​
Release Date 23 December 2025

​
Release Highlights

This patch release addresses a CVE present in 5.8.9 and fixes an issue where API keys remained active when set to inactive status. For a comprehensive list of changes, please refer to the detailed changelog.

​
Breaking Changes

There are no breaking changes in this release.

​
Dependencies

Compatibility Matrix For Tyk Components
3rd Party Dependencies & Tools
Given the potential time difference between your upgrade and the release of this version, we recommend users verify the ongoing support of third-party dependencies they install, as their status may have changed since the release.

​
Deprecations

In this release we’ve deprecated the policies.allow_explicit_policy_id configuration option. This was previously added to allow the use of custom policy IDs, which is now the default behaviour so this option is redundant.

​
Upgrade instructions

If you are upgrading to 5.8.10, please follow the detailed upgrade instructions.

​
Downloads

​
Changelog

Fixed
Resolved an issue where API keys continued to process traffic even after being marked as inactive through API updates.
Security Fixes
Fixed the following high-priority CVE, providing increased protection against security vulnerabilities:

​
5.8.9 Release Notes

​
Release Date 12 December 2025

​
Release Highlights

This patch release contains various bug fixes and introduces enhanced DNS monitoring for MDCB deployments. For a comprehensive list of changes, please refer to the detailed changelog.

​
Breaking Changes

There are no breaking changes in this release.

​
Dependencies

Compatibility Matrix For Tyk Components
3rd Party Dependencies & Tools
Given the potential time difference between your upgrade and the release of this version, we recommend users verify the ongoing support of third-party dependencies they install, as their status may have changed since the release.

​
Deprecations

In this release we’ve deprecated the policies.allow_explicit_policy_id configuration option. This was previously added to allow the use of custom policy IDs, which is now the default behaviour so this option is redundant.

​
Upgrade instructions

If you are upgrading to 5.8.9, please follow the detailed upgrade instructions.

​
Downloads

​
Changelog

Added
We have implemented background monitoring of MDCB endpoint DNS resolution to ensure rapid response to changes without waiting for failures, which block API consumer requests. When a DNS change is detected, Tyk will now automatically reconnect the RPC client to minimise downtime and risk of request blocking. The DNS monitor checks for changes at a configurable interval (default: 30 seconds, minimum: 10 seconds). This can be set using the slave_options.dns_monitor configuration.
Fixed
Fixed a bug causing JWT authentication to panic in MDCB emergency mode. When processing tokens with new sub-claims, the gateway returned an uninitialized session missing its KeyID, leading to a crash when generating the session’s KeyHash. The fix ensures the KeyID is preserved in the emergency-mode path, allowing sessions to be created and cached correctly and preventing panics during MDCB outages.
Fixed an issue where Gateways using Redis Rate Limiters would crash when sharing Redis with Gateways using Distributed Rate Limiting (DRL). Non-DRL Gateways now properly ignore DRL update messages instead of attempting to process them, enabling mixed rate-limiter deployments across shared Redis instances.
Fixed redundant boolean enum definitions in OpenAPI specification by removing unnecessary enum: [true, false] declarations from boolean type fields in swagger.yml files. Boolean parameters now use only type: boolean, following OpenAPI best practices.
Fixed an issue where a Data Plane Gateway could return HTTP 404 errors to client requests if the MDCB link failed during initialisation. The expected behaviour, if MDCB is unavailable, is for the Data Plane Gateway to retrieve policies and API definitions from the local storage (Redis), but this was not occurring in certain scenarios.We have improved the robustness of the Gateway startup so that, if MDCB goes down, it will automatically switch to the local storage (Redis) as expected.
Resolved an issue where JWT APIs using Keycloak authentication experienced significant delays on hybrid gateways due to failed local key lookups. The Gateway was unable to find OAuth client keys in local Redis and had to fetch them from the Control Plane for every request, causing performance degradation and “key not found” errors in logs.JWT API requests now retrieve keys efficiently from local storage, eliminating unnecessary round-trip requests and providing consistent response times.
Fixed an issue where Tyk Gateway advertised leaf certificate Subject DNs instead of Certificate Authority DNs during mTLS handshakes, causing connection failures with RFC-compliant TLS clients. The Gateway now properly extracts and advertises CA DNs from certificate chains in the CertificateRequest message, ensuring compatibility with standards-compliant clients like Apache mod_ssl while maintaining backward compatibility with existing configurations.
We fixed a logging bug in the JSON formatter that could cause error logs to fail to serialize when an error message contained very large numeric values (for example a big integer), which sometimes resulted in missing or broken log output; the formatter now writes the error as a plain text string instead of attempting to encode the underlying error object, so logs reliably serialize to JSON
Fixed an issue where the request pipeline could be blocked by synchronous RPC calls when MDCB was unavailable. The Gateway check for Organisation expiry every 10 minutes is now asynchronous and non-blocking, so it no longer causes API request timeouts and latency spikes (up to 90 seconds) when MDCB is unavailable. Previously this validity check would block the Gateway. This fix ensures consistent API response times regardless of MDCB availability.
Fixed an issue where the Gateway would incorrectly retry RPC calls repeatedly when MDCB is unavailable, but the DNS hasn’t changed. This would cause API requests to block for over 90 seconds before returning an error. Now it takes into account the fact that DNS has not changed and so fails fast, entering Emergency Mode after one retry (30 seconds).

​
5.8.8 Release Notes

​
Release Date 20th November 2025

​
Release Highlights

This patch release fixes some high-priority CVEs. For a comprehensive list of changes, please refer to the detailed changelog.

​
Breaking Changes

There are no breaking changes in this release.

​
Dependencies

Compatibility Matrix For Tyk Components
3rd Party Dependencies & Tools
Given the potential time difference between your upgrade and the release of this version, we recommend users verify the ongoing support of third-party dependencies they install, as their status may have changed since the release.

​
Deprecations

There are no deprecations in this release.

​
Upgrade instructions

If you are upgrading to 5.8.8, please follow the detailed upgrade instructions.

​
Downloads

​
Changelog

Security Fixes
Fixed the following high-priority CVEs, providing increased protection against security vulnerabilities:

​
5.8.7 Release Notes

​
Release Date 29 October 2025

​
Release Highlights

This patch release contains various bug fixes. For a comprehensive list of changes, please refer to the detailed changelog.

​
Breaking Changes

There are no breaking changes in this release.

​
Dependencies

Compatibility Matrix For Tyk Components
3rd Party Dependencies & Tools
Given the potential time difference between your upgrade and the release of this version, we recommend users verify the ongoing support of third-party dependencies they install, as their status may have changed since the release.

​
Deprecations

There are no deprecations in this release.

​
Upgrade instructions

If you are upgrading to 5.8.7, please follow the detailed upgrade instructions.

​
Downloads

​
Changelog

Fixed
Fixed an issue where Custom Authentication could fall back to a previously configured alternative authentication method if the custom plugin bundle was not loaded. Now this is treated as for any other failed plugin load, and requests to the API will be rejected with HTTP 500 Internal Server Error to prevent access to an improperly configured endpoint.
Fixed an issue where sending certain unexpected query parameters to the Gateway’s GET /tyk/apis/oas/{apiID} endpoint could cause a panic instead of returning a proper HTTP 400 Bad Request response. The Gateway now handles unexpected query parameters gracefully without crashing, improving system stability and providing appropriate error responses to clients.
Fixed an issue where the Gateway would load and attempt to use plugin bundles even when the manifest file was invalid or missing. The Gateway now properly validates bundle manifests and fails safely by rejecting API requests when bundles cannot be properly loaded or verified.This prevents risks from corrupted or tampered bundles and ensures that APIs with invalid plugin configurations are not accessible, maintaining the integrity of authentication and authorization checks implemented by plugins.
Fixed an issue where keys could remain deactivated when a policy applied to them was changed from draft to active status. When an access key/token is presented to Tyk in a request, policies linked to the key will be applied, configuring the authorization for that request. If any policy is in draft state, the key will be rejected.Toggling the policy to the active state should activate any keys to which the policy is applied. Previously, if the policy had never been applied when it was in draft state, there was an issue where keys would incorrectly be marked as inactive. This has now been resolved, and the policy state is correctly mapped to keys.
Added a new configuration option, HttpServerOptions.MaxResponseBodySize to limit the maximum size of the response bodies processed during any response body transformations. When the limit is exceeded, the Gateway returns HTTP 500 Response Body Too Large instead of attempting to process the oversized content.
Fixed an issue where plugin loading failure errors were ignored for gRPC, Python, and Lua plugins, allowing API requests to be processed even when plugins failed to load. The Gateway now properly validates plugin drivers during request processing and fails safely by returning HTTP 500 Internal Server Error when any plugin fails to load, ensuring consistent behavior across all plugin types.
Tyk Gateway now validates all file paths in zip bundles before extraction, rejecting bundles that contain invalid paths. Bundle extraction fails immediately upon detecting invalid paths, with detailed error logging, ensuring that only proper bundles with valid relative paths are processed.
Fixed an issue where a Tyk Classic API with inconsistent versioning configuration would process requests using a random version’s configuration.A non-versioned API should:
  • Contain a single entry in version_data.versions with the API configuration.
  • Have the version_data.not_versioned flag set to true.
Previously, if multiple entries existed in the version_data.versions array while not_versioned was set to true, the Gateway would randomly select one of those versions to process incoming requests.New behavior:When version_data.not_versioned is set to true and multiple versions are present, Tyk now deterministically selects the configuration for the default version instead of picking one at random.Tyk determines the default version as follows:
  • First, it looks for an entry named "Default".
  • If not found, it checks for "default".
  • If neither exists, it checks for an entry with an empty string key ("").
  • If none of these are found, Tyk returns an error, indicating a misconfigured non-versioned API.
Fixed an issue where the mock response middleware generated incorrect warning-level messages stating session not found, sending inappropriate rate-limit headers in the Gateway system logs.This warning was introduced incorrectly and caused confusion, as mock responses don’t require session objects by design. The Gateway now returns to the previous behavior where mock response requests execute without generating spurious warning messages, reducing log noise.
Fixed an issue where a Data Plane Gateway could hang for all client requests when the MDCB connection was lost. This was caused by the Gateway incorrectly checking the Organisation quota when TYK_GW_ENFORCEORGQUOTAS was not set. If the Organisation quota cache expired before the Gateway performed a health check, the Gateway could hang.From this release, the Gateway does not check the Organisation quota cache if this is not set. For users relying on Organisation quotas (setting TYK_GW_ENFORCEORGQUOTAS=true), the scenario is different and the lock does not occur.

​
5.8.6 Release Notes

​
Release Date 25th September 2025

​
Release Highlights

This patch release contains various bug fixes. For a comprehensive list of changes, please refer to the detailed changelog.

​
Breaking Changes

There are no breaking changes in this release.

​
Dependencies

Compatibility Matrix For Tyk Components
3rd Party Dependencies & Tools
Given the potential time difference between your upgrade and the release of this version, we recommend users verify the ongoing support of third-party dependencies they install, as their status may have changed since the release.

​
Deprecations

There are no deprecations in this release.

​
Upgrade instructions

If you are upgrading to 5.8.6, please follow the detailed upgrade instructions.

​
Downloads

​
Changelog

Changed
Fixed
Fixed an issue that caused repeated Body decompression error: EOF log messages when analytics were enabled for GraphQL APIs. The problem occurred because the Gateway attempted to decompress the response body after it had already been consumed for analytics processing, resulting in EOF (End of File) errors. The Gateway now correctly handles response body consumption for GraphQL APIs with analytics, eliminating the spurious error logs.
Fixed an issue where Gateways could fail to re-register with the Dashboard after a restart, particularly during upgrades or in large-scale deployments. This resulted in Authorization failed (Nonce empty) errors and Gateway crash loops that prevented successful registration. The fix includes an updated license handler with hardened registration logic, enhanced Dashboard authentication retry mechanisms, and support for new “Unlimited Gateway” licenses, ensuring Gateways register reliably without entering failure loops even during heavy churn or rolling upgrades.
Fixed a bug where deleting an API with the Uptime Test feature enabled could cause the Gateway to crash due to a nil pointer dereference during cleanup operations. The Gateway now properly handles memory cleanup when removing APIs with active uptime tests, preventing crashes and ensuring stable API lifecycle management.
Fixed an issue where Tyk Gateway did not properly apply the configured TLS settings when connecting to Redis for rate limiting operations. This could result in connection failures and incorrect HTTP 429 Too Many Requests responses being returned to clients. The rate limiter now correctly establishes TLS connections to Redis.
Fixed an issue where Response Body Transformation middleware failed to apply to endpoints that used URL rewrite with regex patterns. When the endpoint path contained regex metacharacters (e.g., $, ^, (), []), these characters interfered with the body transformation’s internal pattern-matching process, preventing the middleware from executing.
Fixed an issue where CORS settings from the base API were incorrectly applied to all versions of a Tyk OAS API, preventing child API versions from using their own CORS configuration. This occurred because the CORS check was performed before the request was routed to the correct API version. The processing order has been corrected so that requests are first routed to the appropriate version (base or child), then the correct CORS settings are applied, allowing each API version to have its own CORS configuration.
Fixed an issue where Tyk OAS mock response middleware failed to execute when internal API proxying was enabled. Mock responses configured in the target API are now correctly returned when a request is redirected to another API on the same Tyk Gateway instance via internal looping.
Fixed an issue where importing an OpenAPI description with an apiKey security scheme, while using the authentication query parameter, resulted in the unnecessary generation of a header object within the Tyk Vendor Extension (x-tyk-api-gateway), duplicating information already present in the declared OpenAPI security scheme.
Resolved an issue where the Gateway automatically converted Readable Duration values (such as uptime test timeouts) in Tyk OAS API definitions from integer-based formats to decimal formats, which triggered schema validation warnings. The effect of this was seen in the Tyk OAS API editor in the Dashboard UI where, for example, a duration of ‘4s500ms’ would be converted to ‘4.5s’ when reopening an API definition. Duration values are now consistently serialized and maintained in their original integer-based format to prevent these validation errors.
Fixed an issue where users could create child Tyk OAS API versions using the /tyk/apis/oas endpoint without specifying a valid version name (new_version_name). The Gateway API now rejects such requests with an HTTP 422 Unprocessable Entity error, ensuring all versions have meaningful identifiers and preventing the creation of unusable or empty version entries.
Fixed an issue where updating a Tyk OAS API via PATCH /tyk/apis/oas/{apiId} did not properly update the Tyk Vendor Extension (x-tyk-api-gateway). When endpoints were removed or modified in the OpenAPI description, their corresponding middleware definitions could persist incorrectly in the vendor extension, leaving the API definition in an inconsistent state. The vendor extension is now correctly rebuilt to reflect all changes made to the OpenAPI description.

​
5.8.5 Release Notes

​
Release Date 18th August 2025

​
Release Highlights

Gateway 5.8.5 was version bumped only to align with Dashboard 5.8.5. Subsequently, no changes were encountered in release 5.8.5. For further information, please see the release notes for Dashboard v5.8.5.

​
Breaking Changes

There are no breaking changes in this release.

​
Dependencies

Compatibility Matrix For Tyk Components
3rd Party Dependencies & Tools
Given the potential time difference between your upgrade and the release of this version, we recommend users verify the ongoing support of third-party dependencies they install, as their status may have changed since the release.

​
Deprecations

There are no deprecations in this release.

​
Upgrade instructions

If you are upgrading to 5.8.5, please follow the detailed upgrade instructions.

​
Downloads

​
Changelog

Since this release was version-bumped only to align with Dashboard v5.8.5, no changes were encountered in this release.

​
5.8.4 Release Notes

​
Release Date 13th August 2025

​
Release Highlights

This release restores the stable /hello health-check behavior for Kubernetes probes. Deployments using /hello for liveness or readiness will now behave consistently again. It also fixes a schema compatibility issue in the URL Rewrite middleware, ensuring that API promotion and validation flows no longer fail due to schema mismatches. For a comprehensive list of changes, please refer to the detailed changelog.

​
Breaking Changes

There are no breaking changes in this release.

​
Dependencies

Compatibility Matrix For Tyk Components
3rd Party Dependencies & Tools
Given the potential time difference between your upgrade and the release of this version, we recommend users verify the ongoing support of third-party dependencies they install, as their status may have changed since the release.

​
Deprecations

There are no deprecations in this release.

​
Upgrade instructions

If you are upgrading to 5.8.4, please follow the detailed upgrade instructions.

​
Downloads

​
Changelog

Fixed

​
5.8.3 Release Notes

​
Release Date 15th July 2025

​
Release Highlights

This patch release contains various bug fixes. For a comprehensive list of changes, please refer to the detailed changelog below.

​
Breaking Changes

1. Modified /hello endpoint behavior affects kubernetes deployments In Tyk Gateway version 5.8.3, we introduced a breaking change to the /hello health check endpoint behavior. Previously, this endpoint would always return HTTP 200 during normal operations, regardless of Redis connectivity. The change made the endpoint return HTTP 503 when Redis was unavailable (which shouldn’t be the case), which caused issues for Kubernetes deployments using this endpoint for liveness probes.
Impact
  • Kubernetes pods may be unnecessarily terminated when Redis becomes temporarily unavailable
  • Deployments using /hello for both liveness and readiness probes experience disruption
  • This contradicts the documented behavior that the Gateway continues functioning when Redis is unavailable
Expected Fix Version
This issue will be fixed in Tyk Gateway version 5.8.4, where we will:
  • Revert the /hello endpoint to its pre-5.8.3 behavior (always return HTTP 200 during normal operations)
  • Ensure backward compatibility for existing Kubernetes deployments
2. URL rewrite rules now require explicit negate field A breaking change has been identified in Tyk 5.8.3 regarding URL rewrite rules. The negate field, which was optional in previous versions, is now mandatory in all URL rewrite rule configurations.
What Changed
In Tyk 5.8.2 and earlier, the negate field in URL rewrite rules included an omitempty tag, making it optional in JSON. If not provided, it would default to false In Tyk 5.8.3, this omitempty tag has been removed, making the negate field mandatory in all URL rewrite rule configurations.
Impact
API definitions that worked in Tyk 5.8.2 will fail validation in Tyk 5.8.3 if they contain URL rewrite rules without an explicit negate field. This may cause API updates, or promotion between environments failures between environments with error messages similar to:
Workarounds
When using Tyk 5.8.3, you must explicitly include the negate field in all URL rewrite rules:
Set negate: false for standard matching behavior, or negate: true
Expected fix version
This issue will be fixed in Tyk 5.8.4, where we’re going to make negate field optional again.

​
Dependencies

Compatibility Matrix For Tyk Components
3rd Party Dependencies & Tools
Given the potential time difference between your upgrade and the release of this version, we recommend users verify the ongoing support of third-party dependencies they install, as their status may have changed since the release.

​
Deprecations

There are no deprecations in this release.

​
Upgrade instructions

If you are upgrading to 5.8.3, please follow the detailed upgrade instructions.

​
Downloads

​
Changelog

Added
Fixed
Fixed support for dns:/// protocol for load balancing when using gRPC plugins. Setting the new configuration option TYK_GW_COPROCESSOPTIONS_GRPCROUNDROBINLOADBALANCING to true will cause Tyk to balance the load between multiple gRPC servers; the default behavior (false) is to use a sticky connection to a single server.
Fixed an issue introduced in Tyk 5.8.1 where several previously supported cipher suites were no longer recognized when configured, causing them to be silently skipped for clients relying on those ciphers. The issue was only visible with debug-level logging, making it difficult to diagnose in production environments. Support for these cipher suites has now been restored.
Gateway no longer returns HTTP 500 when calling an invalid path on a streams API and will instead return HTTP 404 as expected.
Fixed an issue where Tyk has trouble proxying a GraphQL edge case; a request that includes an argument on an interface leads to errors proxying.
Gateway no longer produces endless “unsupported protocol scheme” errors for Tyk Streams APIs
Fixed a panic triggered by starting GraphQL subscriptions and resolved an issue where Kafka messages failed to resolve correctly.
Gateway no longer tries to start a garbage collection task after deleting a Tyk Streams API
Fixed an issue where the payload (request body) was not included in detailed traffic logs for the following scenarios:
  • Content-Type "application/x-www-form-urlencoded"
  • Transfer-Encoding: chunked
Browser clients can now reliably consume streams outputs (SSE and WebSocket)
Fixed an issue when using Tyk OAS where the API definition was not accessible from Response Plugins unless a Request Plugin was also loaded. The issue was caused by the ctx.GetOASDefinition(req) function not consistently returning the proper OpenAPI Specification (OAS).

​
5.8.2 Release Notes

​
Release Date 1st July 2025

​
Release Highlights

This patch release contains fixes to some bugs experienced when using MDCB and distributed data planes. For a comprehensive list of changes, please refer to the detailed changelog below.

​
Breaking Changes

There are no breaking changes in this release.

​
Dependencies

Compatibility Matrix For Tyk Components
3rd Party Dependencies & Tools
Given the potential time difference between your upgrade and the release of this version, we recommend users verify the ongoing support of third-party dependencies they install, as their status may have changed since the release.

​
Deprecations

There are no deprecations in this release.

​
Upgrade instructions

If you are upgrading to 5.8.2, please follow the detailed upgrade instructions.

​
Downloads

​
Changelog

Fixed
The Data Plane could lose connectivity to MDCB when DNS records changed (for example due to ELB updates). The RPC address became stale and the Gateways could not reconnect. We have improved the RPC connection handling in the gateway to properly detect and respond to DNS changes, ensuring seamless reconnection when remote IPs become unavailable.
Fixed a bug where a timeout in an RPC call to MDCB could lead to policies not being synchronised to the data plane.

​
5.8.1 Release Notes

​
Release Date 9 May 2025

​
Release Highlights

This patch release contains various bug fixes. For a comprehensive list of changes, please refer to the detailed changelog below.

​
Breaking Changes

There are no breaking changes in this release.

​
Dependencies

Compatibility Matrix For Tyk Components
3rd Party Dependencies & Tools
Given the potential time difference between your upgrade and the release of this version, we recommend users verify the ongoing support of third-party dependencies they install, as their status may have changed since the release.

​
Deprecations

There are no deprecations in this release.

​
Upgrade instructions

If you are upgrading to 5.8.1, please follow the detailed upgrade instructions.

​
Downloads

​
Changelog

Fixed
Addressed an issue for UDG APIs where caching led to the forwarding of stale values for headers that contained content variables towards the upstream of the UDG apis.
Resolved an issue where requests could be routed incorrectly due to inverted prioritisation of dynamically declared paths over those with similar static paths. Now, statically declared paths take priority in the path matching algorithm, so if API1 has listen path /path/{param}/endpoint and API2 has listen path /path/specific/endpoint a request to /path/specific/endpoint/resource will be correctly routed to API2.
Fixed an issue where an enforced timeout set for a specific API endpoint could be overruled by the configured proxy_default_timeout. Now if an endpoint-level timeout is set then this will be honoured, regardless of any default timeout that is configured.
Resolved a race condition in self-managed deployments which occasionally lead to fewer Gateways registering with the Dashboard than the number that had been licensed. Now Tyk Self-Managed deployments will allow the licensed number of Gateways to register and serve traffic.
Resolved a bug where allowed_types from multiple policies were incorrectly merged using intersection logic. Policies now correctly merge fields to allow access to any fields listed across the applied policies.

​
5.8.0 Release Notes

​
Release Date 28 March 2025

​
Release Highlights

With Tyk 5.8.0 we are delighted to unlock the power and flexibility of Tyk OAS for all users, with full feature parity with the legacy Tyk Classic API definition. We are also bringing other updates and improvements, delivering more control, flexibility, and performance. For a comprehensive list of changes, please refer to the detailed changelog below.
Full support for Gateway configuration using Tyk OAS
We have completed the journey with Tyk OAS that started in Tyk 4.1 - and now anything that you can configure using the Tyk Classic API definition is also available in the Tyk OAS API definition. Tyk OAS is now the recommended API style for all REST services, with Tyk Classic recommended for use only for GraphQL and TCP services. With Tyk OAS we combine the industry standard OpenAPI description with the Tyk Vendor Extension, which encapsulates all of the Tyk Gateway settings that cannot be inferred from the OpenAPI Specification (OAS). You can keep your service description (OAS) as source of truth and update the OpenAPI description part of a Tyk OAS API independently from the Tyk Vendor Extension - no need to unpick distributed vendor extensions from your OAS. For more details, please see the documentation.

​
Breaking Changes

There are no breaking changes in this release.

​
Dependencies

Compatibility Matrix For Tyk Components
3rd Party Dependencies & Tools
Given the potential time difference between your upgrade and the release of this version, we recommend users verify the ongoing support of third-party dependencies they install, as their status may have changed since the release.

​
Deprecations

There are no deprecations in this release.

​
Upgrade instructions

If you are upgrading to 5.8.0, please follow the detailed upgrade instructions.

​
Downloads

​
Changelog

Added
In Tyk 5.8.0, we have added configuration of the following features into the Tyk OAS API definition, so that anything you can configure for a REST API via Tyk Classic you can also configure using Tyk OAS:
  • IP access control
  • API-Level request size limit
  • API-level ignore endpoint case
  • Skip rate limit middleware
  • Skip quota middleware
  • Skip quota reset on key creation
  • Custom analytics tags
  • Custom analytics retention period
  • Custom analytics plugins
  • Preserve client Host header
  • Gateway HTTP settings
  • Upstream uptime testing
  • Upstream load balancing
  • Upstream SSL configuration
  • Upstream authentication: HMAC request signing
  • Event handling: custom JS handler
  • Event handling: custom log Handler
  • Batch requests
Tyk Gateway now supports transaction logs, providing structured access logs for API requests. This improves debugging and observability without the overhead of enabling debug mode in production. Logs can be output in JSON format and customized via a template, ensuring flexibility while maintaining performance. Find more details in our Transaction Logs documentation.
We have added GODEBUG flags to enable deprecated insecure ciphers by default for backward compatibility. Existing users will not be affected. New users or those who wish to override these settings can do so at runtime using environment variables.
Changed
Tyk Gateway now runs on Golang 1.23, bringing security and performance improvements. Key changes include:
  • unbuffered Timer/Ticker channels
  • removal of 3DES cipher suites
  • updates to X509KeyPair handling.
You may need to adjust your setup for compatibility. For more detail please see the official Go release notes.
We have updated the library that supports JSON schema validation in the Tyk Classic Validate JSON middleware. This introduces improved error messaging when a request does not match the expected schema, reporting where the error exists in the request payload.
Modified the default values of allow_explicit_policy_id and enable_duplicate_slugs to true in all example configuration files, ensuring consistency and alignment with recommended settings.
Fixed
We have fixed an issue where authentication was incorrectly handled for the Internal API when URL Rewrite middleware was used to redirect a request using the tyk:// protocol. This fix ensures that when API A redirects to API B, authentication with API B will use the method configured for API B, improving access control and preventing access denials. Users can now rely on the expected authentication flow, providing a predictable experience when routing to internal APIs.
Resolved initialization errors that caused unnecessary error logging during gateway startup, improving PID file handling and Redis connection state management.
Fixed an issue where the gateway stopped processing traffic when restarted while MDCB was unavailable. Instead of entering “emergency” mode and loading APIs and policies from the Redis backup, the gateway remained unresponsive, continuously attempting to reconnect. With this fix, the gateway detects connection failure and enters emergency mode, ensuring traffic processing resumes even when MDCB is down.
Improved the performance of ctx.GetOASDefinition() in custom plugins by replacing the deep copy operation with a more efficient cloning method. This optimization reduces memory usage by 95% and CPU consumption by 46%, significantly speeding up API definition retrieval.Thanks to @sebkehr for identifying this issue and providing valuable feedback to enhance Tyk’s performance.
Multi-value response headers were previously lost after synchronization with coprocess middleware, as only the first value was retained. This has been resolved, ensuring all response headers are properly synchronized and preserved
Resolved an issue where the gateway incorrectly selected the OAuth upstream authentication flow when both client credentials and password flows were configured. The gateway now correctly respects the allowedAuthorizeTypes setting, ensuring the intended authentication flow is used.

​
5.7 Release Notes

​
5.7.3 Release Notes

​
Release Date 05 June 2025

​
Release Highlights

This patch release contains a bug fix. For a comprehensive list of changes, please refer to the detailed changelog below.

​
Dependencies

Compatibility Matrix For Tyk Components
3rd Party Dependencies & Tools
Given the potential time difference between your upgrade and the release of this version, we recommend users verify the ongoing support of third-party dependencies they install, as their status may have changed since the release.

​
Deprecations

There are no deprecations in this release.

​
Upgrade instructions

If you are upgrading to 5.7.3, please follow the detailed upgrade instructions.

​
Downloads

​
Changelog

Fixed

​
5.7.2 Release Notes

​
Release Date 19 February 2025

​
Release Highlights

This patch release contains a bug fix. For a comprehensive list of changes, please refer to the detailed changelog below.

​
Breaking Changes

There are no breaking changes in this release.

​
Dependencies

Compatibility Matrix For Tyk Components
3rd Party Dependencies & Tools
Given the potential time difference between your upgrade and the release of this version, we recommend users verify the ongoing support of third-party dependencies they install, as their status may have changed since the release.

​
Deprecations

There are no deprecations in this release.

​
Upgrade instructions

If you are upgrading to 5.7.2, please follow the detailed upgrade instructions.

​
Downloads

​
Changelog

Fixed

​
5.7.1 Release Notes

​
Release Date 31 December 2024

​
Release Highlights

This release focuses mainly on bug fixes. For a comprehensive list of changes, please refer to the detailed changelog below.

​
Breaking Changes

There are no breaking changes in this release.

​
Dependencies

Compatibility Matrix For Tyk Components
3rd Party Dependencies & Tools
Given the potential time difference between your upgrade and the release of this version, we recommend users verify the ongoing support of third-party dependencies they install, as their status may have changed since the release.

​
Deprecations

There are no deprecations in this release.

​
Upgrade instructions

If you are upgrading to 5.7.1, please follow the detailed upgrade instructions.

​
Downloads

​
Changelog

Fixed
Resolved an issue where the response body could be only partially recorded in the traffic log if a custom response plugin modified the payload. This was due to Tyk using the original, rather than the modified, content-length of the response when identifying the data to include in the traffic log.
Fixed a bug that prevented the control plane Gateway from loading APIs that use custom plugin bundles. The control plane Gateway is used to register OAuth clients and generate access tokens so this could result in an API being loaded to the data plane Gateways but clients unable to obtain access tokens. This issue was introduced in v5.3.1 as a side-effect of a change to address a potential security issue where APIs could be loaded without their custom plugins.
Addressed an issue where shared loggers caused debug logs to misidentify the middleware source, complicating debugging. Log entries now correctly indicate which middleware generated the log, ensuring clearer and more reliable diagnostics
Fixed an issue where a malformed listen path could cause the Gateway to crash. Now, such listen paths are properly validated, and if validation fails, an error is logged, and the API is skipped—preventing Gateway instability.
Resolved a bug that prevented upstream server-sent events (SSE) from being sent when OpenTelemetry was enabled, and fixed a gateway panic that occurred when detailed recording was active while SSE was in use. This ensures stable SSE streaming in configurations with OpenTelemetry.
Resolved an issue where API access keys remained valid even if all associated policies were deleted. The Gateway now attempts to apply all linked policies to the key when it is presented with a request. Warning logs are generated if any policies cannot be applied (for example, if they are missing). If no linked policy can be applied, the Gateway will reject the key to ensure no unauthorized access.
Resolved an issue where APIs using the Transfer-Encoding: chunked header alongside URL Rewrite or Validate Request middleware would lose the response payload body. The payload now processes correctly, ensuring seamless functionality regardless of header configuration.
OAuth 2.0 access tokens can now be issued even when data plane gateways are disconnected from the control plane. This is achieved by saving OAuth clients locally within the data plane when they are pulled from RPC.
Tyk now supports RSA-PSS signed JWTs (PS256, PS384, PS512), enhancing security while maintaining backward compatibility with RS256. No configuration changes are needed—just use RSA public keys, and Tyk will validate both algorithms seamlessly.
Resolved a problem in the request size limit middleware that caused GET and DELETE requests to fail validation.The middleware incorrectly expected a request body (payload) for these methods and blocked them when none was present.
Fixed an issue where GraphQL queries using variables for custom scalar types, such as UUID, failed due to incorrect input handling. Previously, the query would return an error when a variable was used but worked when the value was directly embedded in the query. This update ensures that variables for custom scalar types are correctly inferred and processed, enabling seamless query execution.

​
5.7.0 Release Notes

​
Release Date 03 December 2024

​
Release Highlights

We are thrilled to announce new updates and improvements in Tyk 5.7.0, bringing more control, flexibility, and performance. For a comprehensive list of changes, please refer to the detailed changelog below.
Tyk Streams - asynchronous API management with Tyk
Tyk is now entering the asynchronous API management space with a bang by delivering Tyk Streams to our users! Many API management solutions fail to fully support event-driven architectures, causing fragmented management, inconsistent security practices, and increased operational complexity. With event-driven architectures on the rise recently, keeping everything under control and enforcing standards at the organizational level has become a challenge. Tyk Streams is an event streaming solution available within the Tyk API Management Platform, which applies proven API management principles to simplify event and streams handling. This release brings capabilities to stream data and events using Kafka, Websocket, SSE and HTTP protocols. It also becomes possible to mediate the message format between Avro and JSON on the fly.
  • Merge together various sources of events to present to consumers as a unified stream.
  • Apply authentication and authorization to streams of messages, just as you do for your RESTful APIs
  • Expose async APIs via Tyk Portal, so that they are easily discoverable
All of this possible in self-managed and k8s deployments of Tyk!

​
Breaking Changes

There are no breaking changes in this release.

​
Dependencies

Compatibility Matrix For Tyk Components
3rd Party Dependencies & Tools
Given the potential time difference between your upgrade and the release of this version, we recommend users verify the ongoing support of third-party dependencies they install, as their status may have changed since the release.

​
Deprecations

In 5.7.0, we have deprecated the dedicated External OAuth (Tyk Classic: external_oauth, Tyk OAS: server.authentication.securitySchemes.externalOAuth) and OpenID Connect (Tyk Classic: auth_configs.oidc, Tyk OAS: server.authentication.oidc) authentication methods. We advise users to switch to JWT Authentication.

​
Upgrade instructions

If you are upgrading to 5.7.0, please follow the detailed upgrade instructions.

​
Downloads

​
Changelog

Added
Added to Streams analytics capability to capture and report common error scenarios, including broker connectivity issues and standard HTTP errors, ensuring comprehensive request tracking for Streams-processed requests.
Connected the new OAS validator to the /streams endpoint, adding proper error handling and validation responses for invalid stream configurations.
Extended the OAS validator to include Streams configuration validation, enforcing allowlisted components and validating nested broker configurations while implementing schema validation for Streams configurations.
Introduced a new validator derived from the existing OAS schema, adapting it for Streams validation with modified requirements for upstreamURL and x-tyk-streaming fields. This validator is now used by both the Dashboard API streams endpoint and streams configuration validator.
Refined streams logging behavior to match Tyk’s logging patterns, reducing unnecessary log output and improving log clarity.
Implemented allowlist-based validation for components in streams configurations, replacing the previous blocklist approach. Supported components now include Kafka, WebSocket, SSE, and HTTP for both inputs and outputs (including broker combinations), along with JSON-Avro bidirectional conversion processors, while other components like scanners, caches, and buffers are blocked by default. This validation is enforced consistently across Gateway, Dashboard API, and UI.
Fixed
When using Tyk Streams and sending input via http, the requests sometimes timed out causing a problem for the consumers. The issue has been fixed and now inputs via http for Tyk Streams work as intended.
Fixed a backwards compatibility issue with Tyk OAS API schema validation. When downgrading from a Tyk version, schema validation could fail if new fields had been added to the Tyk OAS API definition. This change relaxes the strictness of validation to allow additional properties.
Resolved a bug where path-based permissions in policies were not preserved when policies were combined, potentially omitting URL values and incorrectly restricting access. The updated behavior ensures that URL access rights from all applicable policies are merged, regardless of policy order, allowing seamless enforcement of combined permissions.
Fixed a routing issue that caused incorrect API matching when dealing with APIs that lacked a trailing slash, used custom domains, or had similar listen path patterns. Previously, the router prioritized APIs with longer subdomains and shorter listen paths, leading to incorrect matches when listen paths shared prefixes. This fix ensures accurate API matching, even when subdomains and listen paths overlap.
Fixed an issue that caused increased memory consumption when proxying large response payloads. The Gateway now handles large payloads more efficiently in terms of speed and memory usage.

​
5.6 Release Notes

​
5.6.1 Release Notes

​
Release Date 18 October 2024

​
Release Highlights

This patch release for Tyk Gateway addresses critical stability issues for users running Tyk Gateway within the data plane, connecting to the control plane or Tyk Hybrid. Affected users should upgrade immediately to version 5.6.1 to avoid service interruptions and ensure reliable operations with the control plane or Tyk Hybrid. For a comprehensive list of changes, please refer to the detailed changelog below.

​
Breaking Changes

There are no breaking changes in this release.

​
Dependencies

Compatibility Matrix For Tyk Components
3rd Party Dependencies & Tools
Given the potential time difference between your upgrade and the release of this version, we recommend users verify the ongoing support of third-party dependencies they install, as their status may have changed since the release.

​
Deprecations

There are no deprecations in this release.

​
Upgrade instructions

If you are upgrading to 5.6.1, please follow the detailed upgrade instructions.

​
Downloads

​
Changelog

Fixed

​
5.6.0 Release Notes

​
Release Date 10 October 2024

Important Update

Date: 12 October 2024
Topic: Gateway panic when reconnecting to MDCB control plane or Tyk Cloud
Workaround: Restart Gateway
Affected Product: Tyk Gateway as an Edge Gateway
Affected versions: v5.6.0, v5.3.6, and v5.0.14
Issue Description:

We have identified an issue affecting Tyk Gateway deployed as a data plane connecting to the Multi-Data Center Bridge (MDCB) control plane or Tyk Cloud. In the above mentioned Gateway versions a panic may occur when gateway reconnect to the control plane after the control plane is restarted.

Our engineering team is actively working on a fix, and a patch (versions 5.6.1, 5.3.7, and 5.0.15) will be released soon.

Recommendations:
For users on versions 5.5.0, 5.3.5, and 5.0.13
We advise you to delay upgrading to the affected versions (5.6.0, 5.3.6, or 5.0.14) until the patch is available.For users who have already upgraded to 5.6.0, 5.3.6, or 5.0.14 and are experiencing a panic in the gateway:
Restarting the gateway process will restore it to a healthy state. If you are operating in a Kubernetes environment, Tyk Gateway instance should automatically restart, which ultimately resolves the issue.

We appreciate your understanding and patience as we work to resolve this. Please stay tuned for the upcoming patch release, which will address this issue.

​
Release Highlights

We are thrilled to announce new updates and improvements in Tyk 5.6.0, bringing more control, flexibility, and performance. For a comprehensive list of changes, please refer to the detailed changelog below.
Per endpoint Rate Limiting for clients
Building on the per-endpoint upstream rate limits introduced in Tyk 5.5.0 we have now added per-endpoint client rate limits. This new feature allows for more granular control over client consumption of API resources by associating the rate limit with the access key, enabling you to manage and optimize API usage more effectively.
Gateway logs in JSON format
You can now output Tyk Gateway system logs in JSON format. This allows for easier integration with logging systems and more structured log data.
Go upgrade to 1.22
We’ve upgraded the Tyk Gateway to Golang 1.22, bringing improved performance, better security, and enhanced stability to the core system.

​
Breaking Changes

There are no breaking changes in this release.

​
Dependencies

Compatibility Matrix For Tyk Components
3rd Party Dependencies & Tools
Given the potential time difference between your upgrade and the release of this version, we recommend users verify the ongoing support of third-party dependencies they install, as their status may have changed since the release.

​
Deprecations

There are no deprecations in this release.

​
Upgrade instructions

If you are upgrading to 5.6.0, please follow the detailed upgrade instructions.

​
Downloads

​
Changelog

Added
Changed
Fixed
We have enhanced the initial synchronization of Data Plane gateways with the Control Plane to ensure more reliable loading of policies and APIs on start-up. A synchronous initialization process has been implemented to avoid sync failures and reduce the risk of service disruptions caused by failed loads. This update ensures smoother and more consistent syncing of policies and APIs in distributed deployments.
We have fixed an issue where the quota limit was not being consistently respected during request spikes, especially in deployments with multiple gateways. The problem occurred when multiple gateways cached the current and remaining quota counters at the end of quota periods. To address this, a distributed lock mechanism has been implemented, ensuring coordinated quota resets and preventing discrepancies across gateways.
We have fixed an issue where API-level rate limits set in multiple policies were not correctly applied to the same key. With this update, when multiple policies configure rate limits for a key, the key will now receive the highest rate limit from the combined policies, ensuring proper enforcement of limits.
We have addressed a performance regression where key creation for policies with a large number of APIs (100+) became significantly slower in Tyk 4.0.13/5.0.1. The operation, which previously took around 1.5 seconds, has been taking over 20 seconds since versions 4.0.13/5.0.1. This issue has been resolved by optimizing Redis operations during key creation, restoring the process to the previous duration, even with a large number of APIs in the policy.
Security Fixes

​
5.5 Release Notes

​
5.5.2 Release Notes

​
Release Date 03 October 2024

​
Release Highlights

This release replaces Tyk Gateway 5.5.1 which was accidentally released as a non-distroless image.

​
Breaking Changes

There are no breaking changes in this release.

​
Dependencies

Compatibility Matrix For Tyk Components
3rd Party Dependencies & Tools
Given the potential time difference between your upgrade and the release of this version, we recommend users verify the ongoing support of third-party dependencies they install, as their status may have changed since the release.

​
Deprecations

There are no deprecations in this release.

​
Upgrade instructions

If you are upgrading to 5.5.2, please follow the detailed upgrade instructions.

​
Downloads

​
5.5.1 Release Notes

​
Release Date 26 September 2024

​
Release Highlights

This release fixes some issues related to the way that Tyk performs URL path matching, introducing two new Gateway configuration options to control path matching strictness. For a comprehensive list of changes, please refer to the detailed changelog below.

​
Breaking Changes

There are no breaking changes in this release.

​
Dependencies

Compatibility Matrix For Tyk Components
3rd Party Dependencies & Tools
Given the potential time difference between your upgrade and the release of this version, we recommend users verify the ongoing support of third-party dependencies they install, as their status may have changed since the release.

​
Deprecations

There are no deprecations in this release.

​
Upgrade instructions

If you are upgrading to 5.5.1, please follow the detailed upgrade instructions.

​
Downloads

​
Changelog

Added
Fixed

​
5.5.0 Release Notes

​
Release Date 12 August 2024

​
Release Highlights

We are thrilled to introduce Tyk Gateway 5.5, bringing advanced rate-limiting capabilities, enhanced certificate authentication, and performance optimizations. For a comprehensive list of changes, please refer to the changelog below.
Per Endpoint Rate Limiting
Now configure rate limits at the endpoint level for both Tyk OAS and Tyk Classic APIs, providing granular protection for upstream services against overloading and abuse.
Root CA Support for Client Certificates
Simplify certificate management with support for root Certificate Authority (CA) certificates, enabling clients to authenticate using certificates signed by the configured root CA.
Optimised AST Document Handling
Experience improved performance with optimised creation and usage of Abstract Syntax Tree (AST) documents in our GQL library, reducing memory usage and enhancing efficiency.

​
Breaking Changes

Docker images are now based on distroless. No shell is shipped in the image.

​
Dependencies

Compatibility Matrix For Tyk Components
3rd Party Dependencies & Tools
Given the potential time difference between your upgrade and the release of this version, we recommend users verify the ongoing support of third-party dependencies they install, as their status may have changed since the release.

​
Deprecations

There are no deprecations in this release.

​
Upgrade instructions

If you are upgrading to 5.5.0, please follow the detailed upgrade instructions.

​
Downloads

​
Changelog

Added
We’ve added support for you to register Certificate Authority (CA) certificates in your API definitions when using static mutual TLS (mTLS). Tyk can now authenticate clients presenting certificates signed by the registered root CA, simplifying certificate management for multiple clients sharing a common CA.
Optimised the creation and usage of AST documents in our GQL library to reduce significant memory allocations caused by pre-allocations during initial creation. These optimizations free up resources more efficiently, minimising performance penalties with increased requests to the Gateway.
Introduced new more granular controls for request rate limiting. Rate limits can now be configured at the endpoint level in Tyk OAS and Tyk Classic API definitions.
When using the URL path to indicate the API version (for example /v1/my-api) it is common to strip the version identifier (e.g. /v1) from the path before proxying the request to the upstream. If the client doesn’t provide any version identifier this could lead to an invalid target URL and failed requests, rather than correctly redirecting to the default version. We have introduced an optional configuration url_versioning_pattern where you can specify a regex that Tyk will use to identify if the URL contains a version identifier and avoiding the accidental stripping of valid upstream path.
Fixed
Fixed an issue when using Tyk OAS APIs where nested API endpoints, such as ‘/test’ and ‘/test/abc’, might incorrectly apply middleware from the parent path to the nested path. The fix ensures that API endpoint definitions are correctly ordered so that the standard behaviour of Tyk is followed, whereby path matching is performed starting from the longest path, preventing middleware misapplication and ensuring both the HTTP method and URL match accurately.
Previously, key creation or reset led to an exponential number of Redis DeleteRawKey commands; this was especially problematic for access lists with over 100 entries. The key creation sequence now runs only once, eliminating redundant deletion of non-existent keys in Redis. This optimization significantly reduces deletion events, enhancing performance and stability for larger access lists.
Addressed a bug that caused Server Side Event (SSE) streaming responses to be considered for caching, which required buffering the response and prevented SSE from being correctly proxied.
Resolved an issue where Host and Latency fields (Total and Upstream) were not correctly reported for Tyk Gateways in MDCB data planes. The fix ensures accurate Host values and Latency measurements are now captured and displayed in the generated traffic logs.
Security Fixes

​
5.4 Release Notes

​
5.4.0 Release Notes

​
Release Date 2 July 2024

​
Breaking Changes

Attention: Please read this section carefully We have fixed a bug in the way that Tyk calculates the key-level rate limit when multiple policies are applied to the same key. This fix alters the logic used to calculate the effective rate limit and so may lead to a different rate limit being applied to keys generated from your existing policies. See the change log for details of the change.

​
Dependencies

Compatibility Matrix For Tyk Components
The above table needs reviewing and updating if necessary
3rd Party Dependencies & Tools
Given the potential time difference between your upgrade and the release of this version, we recommend users verify the ongoing support of third-party dependencies they install, as their status may have changed since the release. The above table needs reviewing and updating if necessary

​
Deprecations

There are no deprecations in this release.

​
Upgrade instructions

If you are upgrading to 5.4.0, please follow the detailed upgrade instructions. Add upgrade steps here if necessary.

​
Release Highlights

We’re thrilled to introduce exciting enhancements in Tyk Gateway 5.4, aimed at improving your experience with Tyk Gateway. For a comprehensive list of changes, please refer to the change log below.
Enhanced Rate Limiting Strategies
We’ve introducing a Rate Limit Smoothing option for the spike arresting Redis Rate Limiter to give the upstream time to scale in response to increased request rates.
Fixed MDCB Issue Relating To Replication Of Custom Keys To Dataplanes
Resolved an issue encountered in MDCB environments where changes to custom keys made via the Dashboard were not properly replicated to data planes. The issue impacted both key data and associated quotas, in the following versions:
  • 5.0.4 to 5.0.12
  • 5.1.1 and 5.1.2
  • 5.2.0 to 5.2.6
  • 5.3.0 to 5.3.2
Action Required
Customers should clear their edge Redis instances of any potentially affected keys to maintain data consistency and ensure proper synchronization across their environments. Please refer to the item in the fixed section of the changelog for recommended actions.
Fixed Window Rate Limiter
Ideal for persistent connections with load-balanced gateways, the Fixed Window Rate Limiter algorithm mechanism ensures fair handling of requests by allowing only a predefined number to pass per rate limit window. It uses a simple shared counter in Redis so requests do not need to be evenly balanced across the gateways.
Event handling with Tyk OAS
We’ve added support for you to register webhooks with your Tyk OAS APIs so that you can handle events triggered by the Gateway, including circuit breaker and quota expiry. You can also assign webhooks to be fired when using the new smoothing rate limiter to notify your systems of ongoing traffic spikes.
Enhanced Header Handling in GraphQL APIs
Introduced a features object in API definitions for GQL APIs, including the use_immutable_headers attribute. This allows advanced header control, enabling users to add new headers, rewrite existing ones, and selectively remove specific headers. Existing APIs will have this attribute set to false by default, ensuring no change in behavior. For new APIs, this attribute is true by default, facilitating smoother migration and maintaining backward compatibility.

​
Downloads

​
Changelog

Added
Introduced a Fixed Window Rate Limiting mechanism to handle rate limiting for load balancers with keep-alives. This algorithm allows the defined number of requests to pass for every rate limit window and blocks any excess requests. It uses a simple shared counter in Redis to count requests. It is suitable for situations where traffic towards Gateways is not balanced fairly. To enable this rate limiter, set enable_fixed_window_rate_limiter in the gateway config or set the environment variable TYK_GW_ENABLEFIXEDWINDOWRATELIMITER=true.
Implemented Rate Limit Smoothing as an extension to the existing Redis Rate Limiter to gradually adjust the rate based on smoothing configuration. Two new Gateway events have been created (RateLimitSmoothingUp and RateLimitSmoothingDown) which will be triggered as smoothing occurs. These can be used to assist with auto-scaling of upstream capacity during traffic spikes.
We’ve added the use_immutable_headers option to the GraphQL API configuration, offering advanced header transformation capabilities. When enabled, users can add new headers, rewrite existing ones, and selectively remove specific headers, allowing granular control without altering the original request. Existing APIs will default to false, maintaining current behavior until ready for upgrade.
Introduced an option for users to manually provide GQL schemas when creating APIs in Tyk, eliminating the dependency on upstream introspection. This feature enables the creation and editing of GQL APIs in Tyk even when upstream introspection is unavailable, providing flexibility for schema management as upstream configurations evolve over time.
The new GraphQL engine, version 3-preview, is now available in Tyk Gateway. It can be used for any GQL API by using the following enum in raw API definition: “version”: “3-preview”. This experimental version offers optimized GQL operation resolution, faster response times, and a more efficient data loader. It is currently not recommended for production use and will be stabilised in future releases, eventually becoming the default for new GQL APIs in Tyk.
Enhanced request headers handling in API definitions for GQL APIs by introducing a features object. Users can now set the use_immutable_headers attribute, which defaults to false for existing APIs, ensuring no change in header behavior. For new APIs, this attribute is true by default, facilitating smoother migration and maintaining backwards compatibility.
We’ve added some more features to the Tyk OAS API, moving closer to full parity with Tyk Classic. In this release we’ve added controls that allow you: to enable or prevent generation of traffic logs at the API-level and to enable or prevent the availability of session context to middleware. We’ve also added the facility to register webhooks that will be fired in response to Gateway events.
Fixed
Resolved a critical issue affecting MDCB environments, where changes to custom keys made via the dashboard were not properly replicated to data planes. This affected both the key data and associated quotas. This issue was present in versions:
  • 5.0.4 to 5.0.12
  • 5.1.1 and 5.1.2
  • 5.2.0 to 5.2.6
  • 5.3.0 to 5.3.2
Action RequiredCustomers are advised to clear their edge Redis instances of any keys that might have been affected by this bug to ensure data consistency and proper synchronization across their environments. There are several methods available to address this issue:
  1. Specific Key Deletion via API: To remove individual buggy keys, you can use the following API call:
Replace {tyk-hybrid-port}, my-custom-key and {dashboard-key} with your specific configuration details. This method is safe and recommended for targeted removals without affecting other keys.
  1. Bulk Key Deletion Using Redis CLI: For environments with numerous affected keys, you might consider using the Redis CLI to remove keys en masse:
This method can temporarily impact the performance of the Redis server, so it should be executed during a maintenance window or when the impact on production traffic is minimal.
  1. Complete Redis Database Flush: If feasible, flushing the entire Redis database offers a clean slate:
Implications Regardless of the chosen method, be aware that quotas will be reset and will need to resynchronize across the system. This may temporarily affect reporting and rate limiting capabilities.
Addressed an issue with service discovery where an IP returned by Consul wasn’t parsed correctly on the Gateway side, leading to unexpected errors when proxying requests to the service. Typically, service discovery returns valid domain names, which did not trigger the issue.
Fixed an issue where GQL Open Telemetry semantic conventions attribute names that lacked the ‘graphql’ prefix, deviating from the community standard. All attributes now have the correct prefix.
Corrected an issue where GraphQL OTel attributes were missing from spans when request validation failed in cases where detailed_tracing was set to false. Traces now include GraphQL attributes (operation name, type, and document), improving debugging for users.
Fixed a gateway panic issue observed by users when using the Persist GQL middleware without defined arguments. The gateway will no longer throw panics in these cases.
Fixed an issue with GraphQL API’s Cross-Origin Resource Sharing (CORS) configuration, which previously caused the API to fail in respecting CORS settings. This resulted in an inability to proxy requests to upstream servers and handle OPTIONS/CORS requests correctly. With this fix, users can now seamlessly make requests, including OPTIONS method requests, without encountering the previously reported error.
Fixed an issue where the Gateway did not respect API domain settings when there was another API with the same listen path but no domain. This could lead to the custom domain API not functioning correctly, depending on the order in which APIs were loaded. APIs with custom domains are now prioritised before those without custom domains to ensure that the custom domain is not ignored.
Addressed a problem with nested field mapping in UDG for GraphQL (GQL) operations. Previously, querying a single nested field caused an error, while including another normal field from the same level allowed the query to succeed. This issue has been fixed to ensure consistent behavior regardless of the query composition.
Fixed a long-standing bug in the algorithm used to determine the effective rate limit when multiple policies are applied to a key. If more than one policy is applied to a key then Tyk will apply the highest request rate permitted by any of the policies that defines a rate limit.Rate limits in Tyk are defined using two elements: rate, which is the number of requests and per, which is the period over which those requests can be sent. So, if rate is 90 and per is 30 seconds for a key, Tyk will permit a maximum of 90 requests to be made using the key in a 30 second period, giving an effective maximum of 180 requests per minute (or 3 rps).Previously, Tyk would take the highest rate and the highest per from the policies applied to a key when determining the effective rate limit. So, if policy A had rate set to 90 and per set to 30 seconds (3rps) while policy B had rate set to 100 and per set to 10 seconds (10rps) and both were applied to a key, the rate limit configured in the key would be: rate = 100 and per = 30 giving a rate of 3.33rps.With the fix applied in Tyk 5.4.0, the Gateway will now apply the highest effective rate to the key - so in this example, the key would take the rate limit from policy B: rate = 100 and per = 10 (10rps).Note that this corrected logic is applied when access keys are presented in API requests. If you are applying multiple policies to keys, there may be a change in the effective rate limit when using Tyk 5.4.0 compared with pre-5.4.0 versions.
Security Fixes

​
5.3 Release Notes

​
5.3.13 Release Notes

​
Release Date 18 May 2026

​
Release Highlights

This release resolves a set of related issues affecting Gateway registration with the Dashboard at scale for deployments using an unlimited node license, where mass registrations or rolling upgrades could leave Gateways stuck in registration loops. For a comprehensive list of changes, please refer to the detailed changelog below.

​
Breaking Changes

There are no breaking changes in this release.

​
Dependencies

Compatibility Matrix For Tyk Components
Third-party Dependencies & Tools

​
Deprecations

There are no deprecations in this release.

​
Upgrade instructions

If you are upgrading to 5.3.13, please follow the detailed upgrade instructions.

​
Downloads

Tyk Helm Charts are configured to install the LTS version of Tyk Gateway. You will need to modify them to install v5.3.13.

​
Changelog

Changed
Updated the Tyk Gateway to use Golang 1.24, reducing exposure to potential security vulnerabilities in older versions.
Fixed
We have resolved a set of related issues affecting Gateway registration with the Dashboard at scale for deployments using an unlimited node license. During mass registrations or rolling upgrades, a combination of lock contention, excessive Redis load, and incorrect handling of 409 Conflict responses could leave Gateways stuck in registration loops without the credentials needed to serve traffic.Gateway registration is now significantly more robust at scale: registration requests are no longer serialized across the fleet, Gateways recover cleanly from transient 409 Conflict responses instead of looping, and the Redis load generated during registration storms is substantially reduced.

​
5.3.12 Release Notes

​
Release Date 12th September 2025

​
Release Highlights

This patch release contains bug fixes. For a comprehensive list of changes, please refer to the detailed changelog below.

​
Dependencies

Compatibility Matrix For Tyk Components
3rd Party Dependencies & Tools
Given the potential time difference between your upgrade and the release of this version, we recommend users verify the ongoing support of third-party dependencies they install, as their status may have changed since the release.

​
Deprecations

There are no deprecations in this release.

​
Upgrade instructions

If you are upgrading to 5.3.12, please follow the detailed upgrade instructions.

​
Downloads

​
Changelog

Fixed
Resolved an issue introduced in Tyk 5.3.10 where Gateways in distributed Data Planes failed to cache TLS certificates correctly in the local Redis, resulting in potential service disruptions if MDCB became unavailable. Data plane gateways now reliably serve HTTPS and mTLS traffic even if MDCB is unavailable.
We’ve fixed an issue where RPC connections remained stale when DNS records changed (such as ELB IP updates), leading to timeout errors. Based on direct customer reports, we’ve enhanced DNS resolution so all connections in the RPC pool now properly reconnect when endpoint IPs change. This eliminates service disruptions during infrastructure updates and ensures more resilient connectivity.
Fixed a bug where a timeout in an RPC call to MDCB would lead to policies not being synchronised to the data plane.
We’ve resolved an issue that could cause Gateways to fail re-registration when restarting under certain licensing configurations during upgrades. This fix introduces support for new “Unlimited Gateway” licenses, enhances Gateway’s Dashboard authentication retry logic, and ensures a smoother upgrade experience for large-scale deployments. Gateways now register reliably without entering failure loops, even under heavy churn or rolling upgrades.

​
5.3.11 Release Notes

​
Release Date 7 May 2025

​
Release Highlights

This patch release contains various bug fixes. For a comprehensive list of changes, please refer to the detailed changelog below.

​
Breaking Changes

This release has no breaking changes.

​
Dependencies

Compatibility Matrix For Tyk Components
3rd Party Dependencies & Tools
Given the potential time difference between your upgrade and the release of this version, we recommend users verify the ongoing support of third-party dependencies they install, as their status may have changed since the release.

​
Deprecations

There are no deprecations in this release.

​
Upgrade instructions

If you are upgrading to 5.3.11, please follow the detailed upgrade instructions.

​
Downloads

​
Changelog

Added
Fixed
Addressed an issue for UDG APIs where caching led to the forwarding of stale values for headers that contained content variables towards the upstream of the UDG apis.
Resolved an issue where requests could be routed incorrectly due to inverted prioritisation of dynamically declared paths over those with similar static paths. Now, statically declared paths take priority in the path matching algorithm, so if API1 has listen path /path/{param}/endpoint and API2 has listen path /path/specific/endpoint a request to /path/specific/endpoint/resource will be correctly routed to API2.
Fixed an issue where an enforced timeout set for a specific API endpoint could be overruled by the configured proxy_default_timeout. Now if an endpoint-level timeout is set then this will be honoured, regardless of any default timeout that is configured.
Resolved a race condition in self-managed deployments which occasionally lead to fewer Gateways registering with the Dashboard than the number that had been licensed. Now Tyk Self-Managed deployments will allow the licensed number of Gateways to register and serve traffic.
Resolved a bug where Gateway pods in Kubernetes would enter a crash loop on restart if MDCB was down. The issue occurred due to the HTTP router failing to initialize properly during cold start. This fix ensures stable Gateway recovery even when MDCB is offline.
Multi-value response headers were previously lost after synchronization with coprocess middleware, as only the first value was retained. This has been resolved, ensuring all response headers are properly synchronized and preserved

​
5.3.10 Release Notes

​
Release Date 19 February 2025

​
Release Highlights

In this release, we upgraded the Golang version to v1.23 for security enhancement and fixed an API authentication issue with redirects. For a comprehensive list of changes, please refer to the detailed changelog below.

​
Breaking Changes

This release has no breaking changes.

​
Dependencies

Compatibility Matrix For Tyk Components
3rd Party Dependencies & Tools
Given the potential time difference between your upgrade and the release of this version, we recommend users verify the ongoing support of third-party dependencies they install, as their status may have changed since the release.

​
Deprecations

There are no deprecations in this release

​
Upgrade Instructions

If you are upgrading to 5.3.10, please follow the detailed upgrade instructions.

​
Downloads

​
Changelog

Fixed
Fixed an issue where the gateway stopped processing traffic when restarted while MDCB was unavailable. Instead of entering “emergency” mode and loading APIs and policies from the Redis backup, the gateway remained unresponsive, continuously attempting to reconnect. With this fix, the gateway detects connection failure and enters emergency mode, ensuring traffic processing resumes even when MDCB is down.
Tyk Gateway now runs on Golang 1.23, bringing security and performance improvements. Key changes include unbuffered Timer/Ticker channels, removal of 3DES cipher suites, and updates to X509KeyPair handling. Users may need to adjust their setup for compatibility.
This fix ensures that when API A redirects to API B using the tyk:// scheme, API B will now correctly authenticate using its own credentials, improving access control and preventing access denials. Users can now rely on the expected authentication flow without workarounds, providing a smoother experience when integrating APIs.

​
5.3.9 Release Notes

​
Release Date 31 December 2024

​
Release Highlights

This release contains bug fixes. For a comprehensive list of changes, please refer to the detailed changelog below.

​
Breaking Changes

This release has no breaking changes.

​
Dependencies

Compatibility Matrix For Tyk Components
3rd Party Dependencies & Tools
Given the potential time difference between your upgrade and the release of this version, we recommend users verify the ongoing support of third-party dependencies they install, as their status may have changed since the release.

​
Deprecations

There are no deprecations in this release

​
Upgrade Instructions

If you are upgrading to 5.3.9, please follow the detailed upgrade instructions.

​
Downloads

​
Changelog

Fixed