Teleport Upcoming Releases
Teleport releases a new major version approximately every 4 months, and provides security-critical support for the current and two previous major versions. With our typical release cadence, we usually support each major version for 12 months.
Teleport
We plan to release the following versions in the coming months:
| Version | Date |
|---|---|
| 18.3.0 | Week of October 13, 2025 |
| 18.4.0 | Week of October 31, 2025 |
We continue to support the following major versions of Teleport:
| Release | Release Date | EOL | Minimum tsh version |
|---|---|---|---|
| v18.x | July 3, 2025 | August 2026 | v17.0.0 |
| v17.x | November 16, 2024 | February 2026 | v16.0.0 |
| v16.x | June 14, 2024 | October 2025 | v15.0.0 |
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 clients and agents.
The relay service can be used to avoid routing 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.
18.4.0
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.
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.
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 18.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 18.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 18.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).