Skip to main content
Version: 17.x (unreleased)

Upgrading Compatibility Overview

Since Teleport is a distributed system with a number of services that run on potentially many hosts, you should take care when upgrading the cluster to ensure that all components remain compatible.

This guide provides an overview of how to upgrade the components in your Teleport cluster while preserving compatibility.

Component 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:

  • Patch and minor versions are always compatible, for example, any 8.0.1 component will work with any 8.0.3 component and any 8.1.0 component will work with any 8.3.0 component.
  • Servers support clients that are one major version behind, but do not support clients that are on a newer major version. For example, an 8.x.x Proxy Service instance is compatible with 7.x.x agents and 7.x.x tsh, but we don't guarantee that a 9.x.x agent will work with an 8.x.x Proxy Service instance. This also means you must not attempt to upgrade from 6.x.x straight to 8.x.x. You must upgrade to 7.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. You can override version checks by passing --skip-version-check when starting agents and Proxy Service instances.

In Teleport Enterprise Cloud, we manage the Auth and Proxy Services for you. You can determine the current version of these services by running the following command, where mytenant is the name of your Teleport Enterprise Cloud tenant:

$ curl -s https://mytenant.teleport.sh/webapi/ping | jq '.server_version'

Upgrading a self-hosted Teleport cluster​

Because of the component compatibility guarantees we described in the previous section, you must adhere to the following sequence when upgrading a self-hosted Teleport cluster:

  1. Back up your Teleport cluster state as a precaution against any unforeseen incidents while upgrading the Auth Service, which may perform data migrations on its backend. Follow the instructions in Backup and Restore.

  2. If several Auth Service instances are running in a high availability configuration (for example, in an AWS Auto Scaling group), you must shrink the group to just one Auth Service before performing an upgrade.

  3. Upgrade the Auth Service to the next major version first. If there are data format changes introduced in the new version, the Auth Service performs the necessary migrations. After the upgrade, start the Auth Service and CONFIRM that it's in a healthy state before continuing.

  4. Upgrade Proxy Service instances to the same version number as the Auth Service. Proxy Service instances are stateless and can be upgraded in any sequence or at the same time.

  5. Upgrade your Teleport agents to the same version number as the Auth Service. You can upgrade resource agents in any sequence or at the same time.

    If you are upgrading more then one version number, repeat these steps until you reach your target major version number.

Upgrading multiple Teleport clusters​

When upgrading multiple Teleport clusters with a trust relationship, you must upgrade in the following sequence to avoid compatibility issues.

You must upgrade all clusters one major version at a time. For example, if you would like to upgrade your clusters from v10 to v12, you must follow the sequence below to upgrade clusters from v10 to v11, then repeat the sequence to upgrade from v10 to v11.

  1. Upgrade the root cluster—that is, the cluster that other clusters trust—first.
  2. Verify the upgrade was successful.
  3. Upgrade the trusted leaf clusters.

Next steps​

Return to the Upgrading Introduction for how to upgrade individual components within your Teleport cluster.