DigitalOcean Kubernetes Supported Releases

DigitalOcean Kubernetes (DOKS) is a managed Kubernetes service. Deploy Kubernetes clusters with a fully managed control plane, high availability, autoscaling, and native integration with DigitalOcean Load Balancers and volumes. DOKS clusters are compatible with standard Kubernetes toolchains and the DigitalOcean API and CLI.

This section outlines DigitalOcean Kubernetes (DOKS) release process and when we end support for unsupported upstream Kubernetes releases. You can find version availability and deprecation announcements in the Kubernetes changelog and release notes.

We release new minor versions of DOKS as soon as possible (usually a month) after an upstream Kubernetes release. We release new patch versions of DOKS, which integrate new upstream patches as well as improvements to DOKS-specific components, about once a month. When an upstream Kubernetes release becomes unsupported, we stop updating the DOKS patch releases for that release.

Currently, you can create new clusters on the three most recent minor releases. In addition, you can keep existing clusters on older minor releases and apply patch upgrades to them.

Supported Releases Policy

To help you take advantage of the latest upstream Kubernetes features and bug fixes, and for us to provide you better support and security, we are announcing some upcoming changes to our release process and support policy. Starting 1 September 2021:

  • We will require that you upgrade clusters that are on unsupported releases. During their scheduled maintenance windows, clusters will be automatically upgraded to the next minor release 30 days after the release they are running becomes unsupported. You can manually trigger an upgrade any time before or during this window. You will receive notification emails 30 days, 7 days, and a day before an automatic upgrade.

Clusters are upgraded using the upgrade process and follow the end-of-support timeline.

We will upgrade clusters running on unsupported versions regardless of whether you have enabled auto upgrades for those clusters.
  • We will provide support for clusters running unsupported releases during the 30-day window on a best-effort basis.

  • If a serious security vulnerability is identified in the version your cluster is running, we may end support for that patch version and schedule an upgrade to the latest patch version of the cluster’s current minor version. You will be notified at least 7 days before the upgrade, as well as the day before the upgrade starts.

  • You can continue to create new clusters on any currently-supported Kubernetes minor release. When a release goes beyond its support window, we will immediately disable creation of new clusters on that release.

End-of-Support Timeline

The following table shows the end-of-support timeline for all DOKS releases that are currently in use. The table follows the upstream end of maintenance support.

DOKS Release Initial DOKS Release End of Support Upgrades Begin
1.11-1.14 21 May 2019 (DOKS GA) 1 September 2021 1 October 2021
1.15 12 August 2019 1 September 2021 1 October 2021
1.16 5 November 2019 1 September 2021 1 October 2021
1.17 7 May 2020 1 September 2021 1 October 2021
1.18 20 July 2020 1 September 2021 1 October 2021
1.19 27 October 2020 1 September 2021 30 October 2021
1.20 2 February 2021 28 March 2022 27 April 2022
1.21 29 June 2021 28 June 2022 27 July 2022
1.22 3 March 2022 28 October 2022 27 November 2022
1.23 26 July 2022 28 February 2023 27 March 2023
1.24 30 August 2022 28 July 2023 27 August 2023
1.25 6 December 2022 27 October 2023 26 November 2023
1.26 22 March 2023 28 February 2024 27 March 2024
1.27 30 May 2023 28 June 2024 27 July 2024
1.28 18 September 2023 28 October 2024 27 November 2024
1.29 17 January 2024 28 February 2025 27 March 2025
1.30 21 May 2024 28 June 2025 27 July 2025
Clusters running releases 1.17 and earlier will be automatically upgraded multiple times after 1 October 2021. Upgrades will occur during the scheduled maintenance window until the cluster reaches a supported release. For example, a cluster running a 1.11 release will be upgraded in 8 consecutive maintenance windows to reach a supported release 1.19.