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.6.0 | Week of December 15, 2025 |
| 18.7.0 | Week of January 26, 2026 |
| 19.0.0 | August 2026 |
18.6.0
Identifier-first login enhancements
Teleport will automatically pass the username to the identifier provider when performing Identifier-first login with OIDC or SAML IdPs.
GitHub Actions Kubernetes Wizard
Teleport will ship with a new guided flow for setting up GitHub Actions workflows that connect to Teleport-protected Kubernetes clusters without secrets.
18.7.0
VNet for Linux
Teleport VNet support will be extended to Linux workstations.
Session timeline view for Identity Security
Session player for Identity Security users will receive an enhanced timeline view with per-command session breakdown.
Improvements to access list creation UX
Teleport will provide guided in-product UX for creating common types of access lists centered around granting users permissions to resources and permissions to request access to resources.
Terraform-native flow for configuration of AWS EC2 auto-discovery
Teleport will provide in-product UX for configuring EC2 auto-discovery in a single AWS account using terraform module.
Access requests privilege escalation UX for AWS
Teleport users will be able to see specific IAM roles available to them when requesting elevated access to AWS CLI/console. Future releases will extend support for specific principal selection to access requests for other resource types as well.
RoleV8 support in terraform provider
Teleport terraform provider will support RoleV8 out of the box.
Entra ID integration status page
Teleport users will be able to see status of the configured Entra ID integration in the web UI.
Teleport Cloud
The key deliverables for Teleport Cloud in the next quarter:
| Week of | Description |
|---|---|
| December 1, 2025 | Teleport 18.5 will begin rollout on Cloud. |
| December 1, 2025 | Teleport 18.5 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).