Apache Kafka End of Life: Which Kafka Versions Are Supported

Apache Kafka has no fixed end-of-life dates. The project supports its three most recent releases with bug fixes, and as of September 2026 those are Kafka 4.3, 4.2 and 4.1. Every Kafka 3.x release, every 2.x release and Kafka 4.0 are archived: they receive no further fixes from the Apache project. If you run Confluent Platform or Amazon MSK, the vendor keeps a separate support window, covered below.

The Apache Kafka EOL policy, in the project's own words

The Kafka release plan sets a goal of three releases a year, which means a release every four months. The time-based release plan then states the EOL policy in two sentences: the community tests that a rolling upgrade can be done from each release in the past year, which is the last three releases, to the latest version, and it will attempt to do bug fix releases as needed for the last three releases. The downloads page confirms it: bug fix releases are made for supported releases only.

So a Kafka version is supported for roughly twelve months. There is no long-term support release, no extended support from the project, and no announcement when a version drops off. It simply stops appearing under supported releases.

Currently supported Apache Kafka versions

Checked against the Apache Kafka downloads page on 21 September 2026. When Kafka 4.4 ships, 4.1 drops out of the supported set.

Why Kafka 3.x end of life is harder than a normal upgrade

Kafka 4.0 removed Apache ZooKeeper. From 4.0 onward a Kafka cluster runs only in KRaft mode, where the brokers manage their own metadata. A cluster still using ZooKeeper cannot upgrade straight to a supported version: it has to reach a late 3.x release, migrate its metadata from ZooKeeper to KRaft, and only then move to 4.x. Kafka 4.0 also raised the Java baseline, to Java 17 for brokers and Java 11 for clients, and removed older client protocol versions, so very old Kafka clients need upgrading first.

That is why so many production estates are sitting on Kafka 3.x past end of support. The upgrade is a migration project with a rollback plan, not a rolling restart. Our Kafka 4 and KRaft production readiness guide and the Kafka migration guide cover the sequence.

Confluent Platform and Amazon MSK keep their own support windows

Confluent Platform bundles a specific Apache Kafka version in each release and publishes its own end of support date per Platform version, longer than the Apache window. If you hold a Confluent subscription, that lifecycle, not the Apache one, governs your support. Amazon MSK publishes an end of support date for each Kafka version it offers and upgrades clusters that remain on a retired version, so on MSK the version support policy is AWS's. Neither changes what the Apache project maintains; they change who is responsible for patching your Kafka brokers.

What running an EOL Kafka version actually risks

• Security updates stop. A vulnerability in the broker, Kafka Connect or Kafka Streams is fixed only in supported releases. On an EOL version it stays open.
• Bug fixes stop. Known defects in replication, the group coordinator or log compaction are fixed forward, not backported.
• Client and version compatibility narrows. New clients drop old protocol versions, and a newer Kafka client may refuse an old broker.
• Audits flag it. Unsupported software in a data pipeline is a finding in most regulated environments.
• The upgrade path gets longer. Every release you fall behind adds a hop, and the ZooKeeper to KRaft migration sits in the middle of it.

The incidents that show up on older Kafka clusters

• Under-replicated partitions that never recover. A broker is slow or a disk is failing, followers fall out of the in-sync replica set, and with min.insync.replicas enforced, producers using acks=all start to fail. On an old version you are also exposed to replication bugs that were fixed years ago in releases you cannot get patches for.
• Consumer group rebalance storms. Consumers exceed max.poll.interval.ms under load, are removed from the group, rejoin, and trigger another rebalance. Lag grows while nothing is processed. Newer clients have cooperative rebalancing and static membership, which older estates often have not adopted.
• Disks filling up. Retention is set by time while volume has tripled, or a compacted topic stops compacting because the log cleaner thread died. A broker with a full log directory goes offline and takes its partitions with it.
• ZooKeeper trouble. Session expirations under garbage collection pauses cause controller elections and brief unavailability for every partition. ZooKeeper-based clusters carry this risk until they are migrated to KRaft.
• Client and broker version drift. Kafka is generous about compatibility, but very old clients miss protocol features, and Kafka 4.0 removed support for the oldest protocol versions, so an upgrade can break a forgotten application.

None of these is caused by end of life. What end of life changes is that a fix, if one is needed in the broker, will only ever ship in a version you are not running. That is the case for having Kafka support in place on the version you have while the upgrade is planned.

Your options

• Upgrade to a supported release. For a KRaft cluster this is routine. For a ZooKeeper cluster, plan the metadata migration first.
• Move to a managed service or Confluent Platform and take on its support window and cost model instead. The trade-offs are in self-hosted vs managed Kafka.
• Get support for the version you run. When the upgrade cannot happen this quarter, independent support covers the gap. AceMQ provides 24/7 Kafka support for open-source Apache Kafka, Confluent Platform and MSK estates, including clusters on end-of-life 2.x and 3.x versions, with a 15-minute emergency SLA and a planned route to a supported release.

Start by finding out what you have. Run kafka-broker-api-versions.sh against each cluster, record the broker version, whether it runs ZooKeeper or KRaft, and the oldest client library still connecting. That inventory decides which of the three options is realistic.