// etcd extended support
etcd 3.4 is end of life.
It still holds the state of your Kubernetes, Patroni or Vitess clusters.
The etcd project shipped v3.4.45 on 1 June 2026 as the final patch for v3.4, which was first released in August 2019. Only v3.5, v3.6 and v3.7 receive fixes now. etcd rarely runs alone: it is the backing store for self-managed Kubernetes, a DCS for Patroni and a topology service for Vitess, so an upgrade has to fit around the system above it. OSSeva ships patched etcd 3.4 and older builds today, and makes sure you can restore from backup before anything moves.
Trusted globally by enterprises
Why etcd 3.4 clusters are still running
etcd is small and quiet, which is why nobody schedules its upgrade.
Upgrades go one minor at a time
etcd's upgrade guide requires a cluster to be on v3.5 or later before it can move to v3.6, and every 3.5 member on 3.5.32 or later. A 3.4 cluster has at least two rolling upgrades ahead of it to reach a current line.
The v2 API is gone in 3.6
etcd 3.6 removed the --enable-v2 flag. Anything still using the v2 protocol, such as Patroni's etcd section, has to move to the v3 API first, and Patroni's documentation warns that v2 and v3 keys are not visible to each other.
The system above sets the pace
On self-managed Kubernetes, etcd is the backing store for all cluster data, and the Kubernetes documentation still lists 3.4.29 as a minimum recommended production version. Patroni and Vitess clusters need a tested failover before their DCS or topology store changes.
The dates that matter
2019-08
etcd v3.4 first released.
2025-05-15
etcd v3.6.0 released. The --enable-v2 flag is removed.
2026-06-01
etcd v3.4.45, the final v3.4 patch. v3.4 reaches end of life.
2026-07-08
etcd v3.7.0 generally available.
2026-09-22
Patch releases v3.7.2, v3.6.15 and v3.5.34 for the three supported branches. Nothing for v3.4.
What OSSeva delivers
Patched etcd 3.4 and older
Security fixes backported to etcd 3.4 and earlier lines, including the Go toolchain and bundled dependencies, shipped as signed binaries and container images. Data format and API stay as they are.
Backup, restore and upgrade path
A tested snapshot schedule with etcdctl snapshot save, a rehearsed restore, and the rolling upgrade from 3.4 through 3.5 to a current line when you are ready. Restores on 3.5 and later use etcdutl, because etcdctl snapshot restore is deprecated.
etcd under the system that uses it
Support for etcd as it actually runs: the Kubernetes control plane on self-managed clusters, the Patroni DCS for PostgreSQL, and the Vitess topology service. 24/7 monitoring of quorum, disk latency and database size is available.
Your options, compared
| Option | What you get | Trade-off |
|---|---|---|
| Upgrade to 3.5, then 3.6 or 3.7 | A community-supported etcd line | Two or more rolling upgrades, and v2 API users must migrate their keys first. |
| Upgrade the platform above it | A newer Kubernetes, Patroni or Vitess release with a newer etcd | The etcd upgrade becomes part of a larger platform upgrade. |
| OSSeva extended support | Patched etcd 3.4 and older, tested backups and an upgrade path | A subscription for as long as the old line runs. |
| Stay unpatched | Nothing | Every advisory after June 2026 stays open on the store that holds your cluster state. |
etcd dates from the etcd blog (June 2026 patch release, etcd 3.6 and 3.7 announcements, September 2026 patch release) and GitHub releases. Upgrade rules from the etcd v3.6 upgrade guide. Backup commands from the etcd v3.5 recovery guide. Kubernetes guidance from kubernetes.io. Patroni protocol notes from the Patroni configuration documentation.
Frequently asked questions
Is etcd 3.4 end of life?
Yes. v3.4.45, released on 1 June 2026, was the final patch for v3.4 and marked its end of support. The supported branches are v3.5, v3.6 and v3.7.
Can I upgrade etcd 3.4 straight to 3.6?
No. etcd's upgrade guide requires the cluster to be on v3.5 or later before upgrading to v3.6, with every member on 3.5.32 or later.
How do I back up and restore etcd?
Take a snapshot with etcdctl snapshot save. On 3.5 and later, restore with etcdutl snapshot restore, since etcdctl snapshot restore is deprecated. A restore gives members a new member ID and cluster ID, so rehearse it before you need it.
Which Kubernetes clusters are affected?
Self-managed clusters whose control plane runs etcd 3.4 or older. Managed Kubernetes services run etcd for you, so the question there is the provider's, not yours.
Does Patroni work with a patched etcd 3.4?
Yes. The build keeps the same API and data format, so Patroni, Vitess and Kubernetes see no difference.
Keep etcd 3.4 patched while the platform above it catches up.
Talk to an engineer about your etcd clusters and what runs on them.