Teleport Upcoming Releases
Teleport releases a new major version once per year, and provides security-critical support for the current and previous major version. We support each major version for 24 months.
The most recent major version of Teleport, referred to as the current version, is the only major version of Teleport that will receive new features. The previous major version, referred to as the stable Version, will only receive bug fixes and security patches.
Teleport
Supported releases
We continue to support the following major versions of Teleport:
| Version | Release | Release Date | EOL | Minimum tsh version |
|---|---|---|---|---|
| Current | v18.x | July 3, 2025 | August 2027 | v17.0.0 |
| Stable | v17.x | November 16, 2024 | August 2026 | v16.0.0 |
Upcoming releases
We plan to release the following versions in the coming months:
| Version | Date |
|---|---|
| 18.3.0 | Week of October 27, 2025 |
| 18.4.0 | Week of November 10, 2025 |
| 19.0.0 | August 2026 |
18.3.0
Web UI Workload ID
Teleport's web UI will list all workload identity resources registered in the cluster.
Relay Service
Teleport will ship with a new Relay Service that acts as a lightweight Proxy Service, receiving connections from both SSH clients and agents.
The Relay Service can be used to avoid routing SSH connections through the broader Teleport control plane, providing the ability to optimize network flows in large or complex deployments.
Multi-cluster Discovery
Teleport EC2 auto-discovery will support a use-case in which multiple Teleport clusters discover the same EC2 instances without interfering with each other.
Kubernetes Health Checks
The Kubernetes service will perform regular health checks for registered Kubernetes clusters. Health status will be reported in the Teleport web UI and reflected in kube_server resources. Teleport will prioritizes healthy services when routing user connections to Kubernetes clusters.
ElastiCache Serverless
Teleport will support connecting to ElastiCache Serverless databases.
18.4.0
Streamable-HTTP and SSE support for MCP Zero-Trust Access
MCP Zero-Trust Access users will be able to secure and audit connections to MCP servers that use HTTP-based transport protocols in addition to stdio.
Improved Bot Instances Dashboard
The Bot Instances dashboard will now provide a more intuitive interface for managing a fleet of Machine & Workload Identity bot instances. This will include improved filtering, sorting and searching capabilities, and a high-level overview of the versions of all bot instances in the cluster.
Kubernetes support for Relay Service
The relay service will be extended to facilitate Kubernetes connections.
Teleport Cloud
The key deliverables for Teleport Cloud in the next quarter:
| Week of | Description |
|---|---|
| October 20, 2025 | Teleport 18.3 will begin rollout on Cloud. |
| October 20, 2025 | Teleport 18.3 agents will begin rollout to eligible tenants. |
Production readiness
Teleport follows semantic versioning for pre-releases and releases.
Pre-releases
Pre-releases of Teleport (versions with suffixes like -alpha, -beta, -rc)
should not be run in production environments.
Pre-releases of Teleport are great for testing new features, breaking changes, and backwards incompatibility issues either in development or staging environments.
Major Releases
Major releases look like 19.0.0.
Major releases of Teleport contain many large new features and may contain breaking changes.
Due to the scope and quantity of changes in a major release, we encourage deploying to staging first to verify your usage pattern has not changed.
Minor Releases
Minor releases look like 19.X.0.
Minor releases of Teleport typically contain smaller features and improvements. Minor releases can typically be deployed directly to production.
Most customers upgrade to the next major version of Teleport during the first minor release, such as 19.1.0.
Patch Releases
Patch releases contain small bug fixes and can typically be deployed directly to production.
Version compatibility
Teleport uses Semantic Versioning. Version numbers
include a major version, minor version, and patch version, separated by dots.
When running multiple teleport binaries within a cluster, the following rules
apply:
- Servers support clients that are one major version behind, but do not support
clients that are on a newer major version. For example, an 17.x.x Proxy
Service instance is compatible with 16.x.x agents and 16.x.x
tsh, but a 17.x.x agent will not work with an 16.x.x Proxy Service instance. This also means you must not attempt to upgrade from 16.x.x straight to 18.x.x. You must upgrade to 17.x.x first. - Proxy Service instances and agents do not support Auth Service instances that are on an older major version, and will fail to connect to older Auth Service instances by default. For example, an 18.x.x Proxy Service or agent is not compatible with an 17.x.x Auth Service.
- Auth Service instances should always be the first component of the cluster that is upgraded, and you must upgrade all Auth Service instances to the target version before proceeding to upgrade Proxy Service instances, other agents, and client tools (tsh, tctl, tbot, Connect, etc).