This section describes our version policy for Elasticsearch Service, including:
Available Elastic Stack versionsedit
Elastic Stack versions are denoted as
X is the major version,
Y is the minor version, and
Z is the patch level or maintenance release (version 7.12.1, for example).
We make the two latest minor versions of the latest major version available for provisioning. In addition, the latest minor version of the previous major version is also available.
Previous maintenance releases are removed as new ones becomes available. Only the latest maintenance release within an available minor version is available.
You might sometimes see additional versions listed in the user interface beyond what we guarantee to be available, such as release candidate builds. If a version is listed in the Elasticsearch Service Console, it can be deployed.
New Elastic Stack versionsedit
Whenever a new Elastic Stack version is released, we do our best to provide the new version on our hosted service at the same time. We send you an email and add a notice to the console, recommending an upgrade. You’ll need to decide whether to upgrade to the new version with new features and bug fixes or to stay with a version you know works for you a while longer.
There can be breaking changes in some new versions of Elasticsearch that break what used to work in older versions. Before upgrading, you’ll want to check if the new version introduces any changes that might affect your applications. A breaking change might be a function that was previously deprecated and that has been removed in the latest version, for example. If you have an application that depends on the removed function, the application will need to be updated to continue working with the new version of Elasticsearch.
To learn more about upgrading to newer versions of the Elastic Stack on our hosted service, see Upgrade Versions.
Upgrades for critical issuesedit
We reserve the right to force upgrade a cluster immediately and without notice in advance if there is a critical security or stability issue. Such upgrades happen only within minor versions.
A forced upgrade might become necessary in a situation that:
- Bypasses Shield, where knowing only the cluster endpoint is sufficient to gain access to data.
- Disrupts our ability to effectively manage a cluster in disaster scenarios
- Impairs stability to the point where we cannot guarantee cluster node or data integrity
- Impairs or risks impairing our infrastructure
Release candidates and cutting-edge releasesedit
Interested in kicking the tires of Elasticsearch releases at the cutting edge? We sometimes make release candidate builds and other cutting-edge releases available in Elasticsearch Service for you to try out.
Remember that cutting-edge releases are used to test new function fully. These releases might still have issues and might be less stable than the GA version. There’s also no guaranteed upgrade path to the GA version when it becomes available.
If you’re interested in trying out one of these cutting-edge releases, we don’t recommended upgrading an existing deployment directly. Instead, use a copy of your existing data with a test deployment, first.
Cutting-edge releases do not remain available forever. Once the GA version of Elasticsearch is released, your deployment needs to be removed after a grace period. We cannot guarantee that you will be able to upgrade to the GA version when it becomes available.
We follow the Elastic official end-of-life (EOL) policy for the Elastic Stack. This means that we support each major release of our products for 18 months from the General Availability date, and we actively maintain the last minor release of the two most recent major branches of the Elastic Stack, in accordance with the Elastic Product End of Life Dates.
We give you six months advance notice before a minor version nears its end-of-life, effectively providing you with six months time to upgrade to a newer version yourself. Advance notice is given by email to the primary contact registered in the Elasticsearch Service Console.
If you do not upgrade to an available newer minor version by the end-of-life date, you will be force-upgraded to the latest available minor version within your current major version:
- For Gold and Platinum subscriptions, we communicate with you through a support case and attempt to perform the upgrade in coordination with you.
- For Standard subscriptions, we notify you by email and provide a deadline by which the upgrade will happen if you do not upgrade your cluster yourself.
We do not force upgrades across major versions. For major versions that reach end-of-life:
- We continue to provide support for up to 6 months after EOL for the last minor version of a major version (sometimes referred to as extended-end-of-life (EEOL) or end-of-extended-support).
- After six months have passed, the cluster goes out of support. To continue receiving support, you must upgrade your cluster first.