<a id="release-notes"></a>

# Release Notes for Confluent Platform 8.3

8.3 is a major release of Confluent Platform that provides you with Apache Kafka® 4.3,
the latest stable version of Kafka.

This page lists every 8.3.x patch release. Releases that include notable
changes, such as a security fix or a new feature, are described in full.
Releases that contain only dependency updates and bug fixes link directly to
the [Confluent Platform Component Changelogs](changelog.md#cp-changelog) for a complete list of changes.

The following sections summarize the technical details of this release. For component-level changelogs, see [Confluent Platform Component Changelogs](changelog.md#cp-changelog).

For more information about the Confluent Platform 8.3 release, see the
[release blog](https://www.confluent.io/blog/introducing-confluent-platform-8-3/).

<!-- WARNING: THIS IS A SHARED FILE AND THE SOURCE IS LOCATED IN DOCS-COMMON. DO NOT ADD TO ANY OTHER REPO. -->

## Patch releases

The following patch releases are available for 8.3.x:

### Confluent Platform release 8.3.1

* This release adds broker-side protection against memory exhaustion from
  oversized requests. The new `confluent.bounded.request.max.bytes` and
  `confluent.bounded.request.api.keys` broker configurations let you
  reject requests for specified API keys that exceed a configurable size
  limit before the request payload buffer is allocated. Both configurations
  are opt-in and default to `false`.
* This release adds URL validation hardening for Cluster Linking. When a
  cluster link authenticates to a Metadata Service (MDS) or token endpoint using an
  OAuth token login callback handler, the new
  `confluent.cluster.link.token.handler.url.validation.enable` broker
  configuration validates the configured metadata server URLs against the
  `org.apache.kafka.sasl.oauthbearer.allowed.urls` allow list before
  creating an outbound client. This configuration is disabled by default.

  For more information, see [Manage Security for Cluster Linking on Confluent Platform](../multi-dc-deployments/cluster-linking/security.md#cluster-link-security).
* This release adds broker-side protection against a potential
  denial-of-service risk from oversized transactional IDs. The new
  `transaction.id.max.length` broker property rejects `InitProducerId`
  requests with a transactional ID that exceeds a configurable byte limit.
  The default limit is 32,768 bytes (32 KB). To further reduce the risk,
  lower this limit, for example, to 512 bytes. This property is dynamically
  reconfigurable and affects only new transactional IDs. It does not
  affect existing transactional IDs.
* This release adds broker-side protection against memory exhaustion from
  oversized decompressed records. The new `max.decompressed.message.bytes`
  broker configuration, overridable per topic, rejects records whose
  decompressed size exceeds a configurable byte limit before the broker
  allocates memory to decompress them. The default limit is 2,147,483,639
  bytes (2 GiB). Set this limit higher than the largest decompressed record
  your producers write. Uncompressed batches are unaffected and remain bounded
  by `max.message.bytes`. For compacted topics, lowering this configuration
  below the size of already-stored records causes compaction of affected
  partitions to fail until you raise the limit again. This configuration is
  dynamically reconfigurable at both the broker and topic levels.

For a complete list of changes in this release, see the
[8.3.1 changelog](changelog.md#cp-changelog-8-3-1).

## Kafka brokers

Confluent Platform 8.3 includes Kafka 4.3. Before you upgrade to Confluent Platform 8.3, review the [Upgrade Confluent Platform](../installation/upgrade.md#upgrade) guide and
the [Kafka 4.3 upgrade guide](https://kafka.apache.org/documentation/#upgrade). These guides provide detailed,
step-by-step upgrade instructions, rolling upgrade considerations, information about breaking changes,
and compatibility issues.

### Confluent Community software and Kafka

In Confluent Platform 8.3, new features include:

* [KIP-1023 Follower fetch from tiered offset:](https://cwiki.apache.org/confluence/display/KAFKA/KIP-1023%3A+Follower+fetch+from+tiered+offset)
  The new `follower.fetch.last.tiered.offset.enable` broker configuration lets you bootstrap a new follower from the last
  tiered offset. It defaults to `false` and can be set dynamically as a cluster-wide default.
* [KIP-1066 Mechanism to cordon brokers and log directories:](https://cwiki.apache.org/confluence/display/KAFKA/KIP-1066%3A+Mechanism+to+cordon+brokers+and+log+directories)
  The new `cordoned.log.dirs` configuration marks log directories as cordoned so the broker places no new partitions on
  them, which is useful when scaling down or decommissioning brokers or log directories.
* [KIP-1196 Introduce coordinator cached buffer size config:](https://cwiki.apache.org/confluence/display/KAFKA/KIP-1196%3A+Introduce+group.coordinator.append.max.buffer.size+config)
  The new `group.coordinator.append.max.buffer.size` and `share.coordinator.append.max.buffer.size` configurations set
  the maximum append buffer size the group and share coordinators can use, and new metrics let you track buffer usage.
* [KIP-1219 Configurations for KRaft Fetch and FetchSnapshot byte size:](https://cwiki.apache.org/confluence/display/KAFKA/KIP-1219%3A+Configurations+for+KRaft+Fetch+and+FetchSnapshot+Byte+Size)
  The new `controller.quorum.fetch.snapshot.max.bytes` and `controller.quorum.fetch.max.bytes` controller configurations
  control the maximum amount of data `Fetch` and `FetchSnapshot` requests can retrieve. They each default to 1 MiB,
  replacing the previous internal 8 MiB limit so that controllers can join the quorum over slow network connections.
* [KIP-1240 Additional group configurations for share groups:](https://cwiki.apache.org/confluence/display/KAFKA/KIP-1240%3A+Additional+group+configurations+for+share+groups)
  New broker and group configurations give you more control over the behavior of share groups.
* [KIP-1251 Assignment epochs for consumer groups:](https://cwiki.apache.org/confluence/display/KAFKA/KIP-1251%3A+Assignment+epochs+for+consumer+groups)
  The KIP-848 consumer group protocol now uses improved member epoch validation, which avoids unnecessary fencing of
  group members.
* [KIP-1263 Group coordinator assignment batching and offload:](https://cwiki.apache.org/confluence/display/KAFKA/KIP-1263%3A+Group+Coordinator+Assignment+Batching+and+Offload)
  Group coordinator assignment performance improves through two mechanisms. Batching limits how frequently
  assignments are recalculated, and offloading runs assignment computations on the group coordinator executor so that slow
  assignors do not delay request processing.

For a full list of KIPs, features, and bug fixes, see the [Apache Kafka 4.3 release notes](https://archive.apache.org/dist/kafka/4.3.0/RELEASE_NOTES.html).
You can also watch the Kafka 4.3 release video that follows.

<iframe width="560" height="315" src="https://www.youtube.com/embed/lePgrOiX11U" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share" referrerpolicy="strict-origin-when-cross-origin" allowfullscreen></iframe>

## Clients

This release updates client libraries with the following improvements:

* [KIP-1258 Add support for OAuth client assertion to client_credentials grant type:](https://cwiki.apache.org/confluence/display/KAFKA/KIP-1258%3A+Add+Support+for+OAuth+Client+Assertion+to+client_credentials+Grant+Type)
  The `client_credentials` OAuth grant type now supports client assertion authentication, so you can authenticate with a
  signed assertion instead of a plaintext client secret. This improves security and compatibility with OAuth providers.
* [KIP-1274 Deprecate and remove support for the classic rebalance protocol in KafkaConsumer:](https://cwiki.apache.org/confluence/display/KAFKA/KIP-1274%3A+Deprecate+and+remove+support+for+Classic+rebalance+protocol+in+KafkaConsumer)
  A consumer that starts with the classic rebalance protocol now logs an informational message recommending the new
  consumer rebalance protocol. In this first phase, the `group.protocol` default remains `classic`. The classic
  protocol remains functional but is no longer the recommended option.

## Cluster management

### Confluent for Kubernetes

For Confluent for Kubernetes release notes, see [Confluent for Kubernetes Release Notes](https://docs.confluent.io/operator/current/release-notes.html).

### Ansible Playbooks for Confluent Platform

For Ansible Playbooks for Confluent Platform release notes, see the [Ansible Playbooks for Confluent Platform](https://docs.confluent.io/ansible/current/overview.html).

## Confluent Control Center

Starting with Confluent Platform 8.0, Confluent Control Center packages are hosted in a separate repository under the name
`confluent-control-center-next-gen`, beginning with version 2.0. Control Center is now shipped
independently of Confluent Platform releases. For more information, see the [support plans and compatibility](https://docs.confluent.io/platform/current/control-center/installation/overview.html#compatibility-with-cp) documentation
and the [Control Center Next-Gen Release Notes](https://docs.confluent.io/control-center/current/release-notes.html).

Confluent Control Center meets the Web Content Accessibility Guidelines (WCAG) 2.2 standards. For the latest accessibility details, see the revised
[Accessibility Conformance Report](https://confluent.safebase.us/?itemUid=566fae90-6fe1-4c5c-bf54-eaa2b9bae1dd)
on the [Confluent Trust Center](https://confluent.safebase.us/), published January 2026.

## Confluent Platform for Apache Flink

Confluent Platform for Apache Flink® follows separate versioning and has its own documentation. For detailed information, see the
[Flink documentation](https://docs.confluent.io/cp-flink/current/overview.html).

<a id="release-notes-streams"></a>

## Kafka Streams

Kafka Streams includes the following changes in Confluent Platform 8.3.

#### IMPORTANT
Confluent Platform 8.3.0 (Kafka Streams 4.3.0) contains a critical native memory leak in the
RocksDB state store layer
([KAFKA-20616](https://issues.apache.org/jira/browse/KAFKA-20616) and
[KAFKA-20688](https://issues.apache.org/jira/browse/KAFKA-20688)). Under
repeated state store task closes, such as rebalances or error-triggered
recoveries, off-heap memory grows unbounded and can cause out-of-memory
failures. This leak is fixed in the upcoming Confluent Platform 8.3.2 release. As an
alternative, the fix is available now in Kafka 4.3.1.

* [KIP-1035 StateStore managed changelog offsets:](https://cwiki.apache.org/confluence/display/KAFKA/KIP-1035%3A+StateStore+managed+changelog+offsets)
  The `StateStore` API now includes methods for stores to manage their own changelog offsets. The built-in
  `RocksDBStore` tracks these offsets internally instead of using external `.checkpoint` files, which changes
  the default runtime behavior.
* [KIP-1247 Make Bytes utils class part of the public API:](https://cwiki.apache.org/confluence/display/KAFKA/KIP-1247%3A+Make+Bytes+utils+class+part+of+the+public+API)
  The `Bytes` class is now part of the public API and appears in the Javadoc.
* [KIP-1250 Add metric to track size of in-memory state stores:](https://cwiki.apache.org/confluence/display/KAFKA/KIP-1250%3A+Add+metric+to+track+size+of+in-memory+state+stores)
  New metrics track the number of keys in the in-memory state stores.
* [KIP-1259 Add configuration to wipe Kafka Streams local state on startup:](https://cwiki.apache.org/confluence/display/KAFKA/KIP-1259%3A+Add+configuration+to+wipe+Kafka+Streams+local+state+on+startup)
  The new `state.cleanup.dir.max.age.ms` configuration deletes local state older than a set threshold on startup so the
  application rebuilds it from the changelog topic. It defaults to `-1` and is disabled by default.
* [KIP-1270 Extend ProcessingExceptionHandler for GlobalThread:](https://cwiki.apache.org/confluence/display/KAFKA/KIP-1270%3A+Extend+ProcessExceptionalHandler+for+GlobalThread)
  The new `processing.exception.handler.global.enabled` configuration lets the configured `ProcessingExceptionHandler`
  handle exceptions raised during `GlobalKTable` processing instead of shutting down the application. It defaults to
  `false`.
* [KIP-1271 Allow to store record headers in state stores:](https://cwiki.apache.org/confluence/display/KAFKA/KIP-1271%3A+Allow+to+Store+Record+Headers+in+State+Stores)
  The new record headers support lets state stores preserve Kafka record headers as a first-class feature
  for Processor API users. This support is opt-in and allows a single rolling-bounce upgrade for existing applications.
* [KIP-1285 DSL opt-in support for headers-aware state stores:](https://cwiki.apache.org/confluence/display/KAFKA/KIP-1285%3A+DSL+Opt-in+Support+for+Headers-Aware+State+Stores)
  The DSL API now exposes the headers-aware state stores from KIP-1271. To enable them, set the `dsl.store.format`
  configuration to `HEADERS`.

## Schema Registry

Schema Registry includes the following changes in Confluent Platform 8.3.

* Schema IDs can now be carried in a Kafka record header as an alternative to the legacy 5-byte payload prefix,
  which is one magic byte and a 4-byte schema ID. Producers continue to write the schema ID as a payload prefix
  by default and can enable header-based IDs through configuration. Consumers check the header first and fall back
  to the payload prefix, so they decode records produced in either format. This enables a phased producer-side migration
  with no consumer coordination, and unblocks integration with downstream systems that consume raw payloads without
  serialization framing. For more information, see [Wire format](../schema-registry/fundamentals/serdes-develop/index.md#messages-wire-format).

## Kafka Connect

Kafka Connect includes the following changes in Confluent Platform 8.3.

* [KIP-1273 Improve Connect configurable components discoverability:](https://cwiki.apache.org/confluence/display/KAFKA/KIP-1273%3A+Improve+Connect+configurable+components+discoverability)
  All Kafka Connect plugin types now implement a common `ConnectPlugin` interface that exposes each plugin’s
  configuration definition and version through a single contract. This makes it easier to build tooling that discovers,
  validates, and documents plugin configurations across connectors, converters, transformations, predicates, and REST
  extensions. The change is fully backward compatible and requires no changes to existing plugins. For more information, see [Discover plugin configurations](../connect/devguide.md#connect-devguide-plugin-discovery).
* In line with the [Support policy for self-managed connectors](../connect/supported.md#support-lifecycle-policy-sm-connectors), a specific minimum version of connectors is required for support in Confluent Platform 8.3.
  For details, see [Supported Connector Versions in Confluent Platform 8.3](../connect/supported-connector-version.md#minimum-connector-version-8-3).

## Unified Stream Manager

Confluent Platform 8.3 includes USM Agent version 1.2.0, which introduces
support for Red Hat Enterprise Linux (RHEL) 8. This support allows you to run
Confluent Platform on RHEL 8 and deploy and manage your clusters through USM without
changing your operating system baseline.

For the full USM Agent release history, see
[USM Agent release notes](../usm/release-notes.md#usm-agent-release-notes). For the Confluent Platform versions that each agent
version supports, see [Supported Versions and Interoperability for Confluent Platform](../installation/versions-interoperability.md#interoperability-versions). For Unified Stream Manager
(USM) updates in Confluent Cloud, see the [Confluent Cloud release notes](https://docs.confluent.io/cloud/current/release-notes/index.html).

## ksqlDB

ksqlDB continues to be available as part of Confluent Platform 8.3. For more information, see
[Use Docker to Install ksqlDB for Confluent Platform](../ksqldb/operate-and-deploy/installation/install-ksqldb-with-docker.md#ksqldb-install-configure-with-docker).

## Docker base image updates

Starting with Confluent Platform 8.3.0, `cp-base-java-micro` is a new base Docker image
built on `ubi9-micro`. It has the smallest footprint of the Confluent Platform base images. Confluent Platform Docker images shipped in
8.3.0 are built on `cp-base-java-micro`, or on `cp-base-java` for images
that need the additional `ubi9-minimal` utilities.

Because `cp-base-java-micro` is minimal, some packages and tools that were
included in earlier base images, such as `curl`, `awk`, `python`,
`rpm`, and `microdnf`, are no longer present.

For more information about the Confluent Platform base images, see [Docker Image Reference for Confluent Platform](../installation/docker/image-reference.md#image-reference).

## Known issues

Confluent Platform 8.3 has the following known issue.

If you run Kafka metadata version 4.3, do not migrate to the Confluent Platform
8.3 release. A version incompatibility issue prevents the
migration from completing. This issue should be resolved in the
next release. For more information, see [Migrate an Existing Kafka Deployment to Confluent Platform](../installation/migrating.md#migrate-kafka).

## Deprecation warnings

Confluent Platform 8.3 includes the following deprecation warnings.

### `cp-base-new` and `cp-base-lite` Docker base images

Starting with Confluent Platform 8.3.0, the `cp-base-new` and `cp-base-lite` Docker base images are deprecated. All Confluent Platform Docker images
shipped in 8.3.0 are built on `cp-base-java-micro`, which uses `ubi9-micro` with a Java Runtime Environment (JRE), or `cp-base-java`, which uses `ubi9-minimal` with a JRE.
If you build custom images on top of `cp-base-new` or `cp-base-lite`, migrate to `cp-base-java-micro`, or to
`cp-base-java` if you need the additional `ubi9-minimal` utilities. For more information, see [Docker Image Reference for Confluent Platform](../installation/docker/image-reference.md#image-reference). For backward compatibility, both `cp-base-java` and
`cp-base-java-micro` include a `/usr/share/java/cp-base-new` symlink so existing hardcoded paths continue to work.
Both `cp-base-new` and `cp-base-lite` are scheduled for removal in Confluent Platform 8.4.0. They continue to be built and published
for 8.3.x and earlier supported branches.

### `cp-server-connect-base` and `cp-kafka-connect-base` Docker images

Starting with Confluent Platform 8.3.0, the `cp-server-connect-base` and `cp-kafka-connect-base` Docker images are deprecated. These
base images are functionally identical to `cp-server-connect` and `cp-kafka-connect`. If you build custom Docker images
on top of `cp-server-connect-base` or `cp-kafka-connect-base`, migrate to `cp-server-connect` or `cp-kafka-connect`
respectively. For more information, see [Docker Image Reference for Confluent Platform](../installation/docker/image-reference.md#image-reference). Both `cp-server-connect-base` and
`cp-kafka-connect-base` are scheduled for removal in Confluent Platform 8.4.0. They continue to be built and published for 8.3.x and
earlier supported branches until those releases reach end of life.

### Confluent Manager for Apache Flink user interface in Control Center

Starting with Confluent Manager for Apache Flink (CMF) 2.4, the separate Confluent Control Center user interface installation for Flink management is deprecated.
Instead, use the user interface directly from CMF, which reduces setup time and presents a more Flink-oriented view of
your Flink environments, resources, and operations. For more information, see the
[Confluent Platform for Apache Flink documentation](https://docs.confluent.io/cp-flink/current/overview.html).

### Confluent Health+

Confluent Health+ has entered its end-of-life (EOL) process. Health+ is deprecated, and you
should plan to migrate to Unified Stream Manager (USM). While Health+ remains operational for existing
users, it is scheduled to be retired, or to sunset, in 2026. Starting with Confluent Platform version 8.1,
Health+ is discontinued for new deployments and Unified Stream Manager is the recommended alternative for all users.

To begin your migration planning, see [Unified Stream Manager (USM) in Confluent Platform](../usm/overview.md#usm-overview).

## Supported versions and interoperability

Starting with Confluent Platform 8.3, Java 25 is supported, and the base Docker images use
Eclipse Temurin 25, the latest long-term support (LTS) release. Confluent Platform 8.3 supports Java 25, 21, and 17.
For more information, see [Java](../installation/versions-interoperability.md#java-sys-req).

For the full list of supported versions and interoperability of Confluent Platform and its components,
see [Supported Versions and Interoperability for Confluent Platform](../installation/versions-interoperability.md#interoperability-versions).

<a id="release-notes-download"></a>

## How to download

You can download Confluent Platform at [https://confluent.io/download/](https://www.confluent.io/download/#confluent-platform). For detailed information,
see the [Install Confluent Platform On-Premises](../installation/overview.md#installation) section.

#### IMPORTANT
The Confluent Platform package includes Confluent Server by default and requires a
`confluent.license` key in your `server.properties` file.
The Confluent Server broker checks for a license during startup. You must
supply a license string in each broker’s properties file using the
`confluent.license` property as shown in the following code:

```none
confluent.license=LICENCE_STRING_HERE_NO_QUOTES
```

If you want to use the Kafka broker, download the `confluent-community` package.
The Kafka broker is the default in all Debian, RHEL, and CentOS packages.

For more information about migrating to Confluent Server, see [Migrate Confluent Platform to Confluent Server](../installation/migrate-confluent-server.md#migrate-confluent-server).

To upgrade Confluent Platform to a newer version, see the [Upgrade Confluent Platform](../installation/upgrade.md#upgrade) documentation.

<a id="release-notes-question"></a>

## Questions?

If you have questions about this release, you can reach out through the
[community mailing list](https://groups.google.com/forum/?pli=1#!forum/confluent-platform) or
[community Slack](https://slackpass.io/confluentcommunity). If you are a Confluent customer, you are encouraged to
contact [Confluent Support](https://support.confluent.io/).

To provide feedback on the Confluent documentation, click the **Give us feedback** button
located near the footer of each page.