Release Notes for Confluent Platform 8.4

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

This page lists every 8.4.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 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.

For more information about the Confluent Platform 8.4 release, see the release blog.

Ready to build?

Sign up for Confluent Cloud with your cloud marketplace account and unlock $1000 in free credits: AWS Marketplace, Google Cloud Marketplace, or Microsoft Azure Marketplace.

Kafka brokers

Confluent Platform 8.4 includes Kafka 4.4. Before you upgrade to Confluent Platform 8.4, review the Upgrade Confluent Platform guide and the Kafka 4.4 upgrade guide. 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.4, new features include:

• KIP-1170 Unify cluster metadata bootstrapping: Kafka now writes cluster metadata to the zero checkpoint file (00000000000000000000-0000000000.checkpoint) instead of the separate bootstrap.checkpoint file, and kafka-storage no longer creates bootstrap.checkpoint. If a log directory already has an existing checkpoint file, formatting fails unless you pass --ignore-formatted.

• KIP-1312 Support unregistering controllers: Adds an UnregisterController Admin API and RPC so you can remove a controller from the KRaft quorum without manual metadata surgery. A cluster with a stale controller registration can’t unregister it until every controller is upgraded to a metadata version that supports the new record.

• KIP-1291 Extended I/O metrics collection: Adds five new broker gauges, linux-disk-rchar, linux-disk-wchar, linux-disk-syscr, linux-disk-syscw, and linux-disk-cancelled-write-bytes, under the kafka.server MBean for monitoring disk read/write activity. This is purely additive and requires no configuration to enable.

• KIP-1276 CIDR-based host patterns for ACLs: kafka-acls --allow-host and --deny-host now accept CIDR notation (IPv4 prefixes 0-32, IPv6 0-128) in addition to individual host addresses. Once a CIDR-based ACL exists, the cluster cannot downgrade below the metadata version that supports it until that ACL is removed.

• KIP-1191 Dead-letter queues for share groups: Messages in a share group that repeatedly fail processing now move to a dead-letter queue instead of blocking the group or being lost. The new errors.deadletterqueue.group.enable topic-level configuration (default false) turns this on. The group-level errors.deadletterqueue.topic.name and errors.deadletterqueue.copy.record.enable configurations control what gets copied and where, and the cluster-level errors.deadletterqueue.auto.create.topics.enable (default false) and errors.deadletterqueue.topic.name.prefix (default dlq.) configurations control automatic topic creation. This requires every broker in the cluster to support the share.version=2 feature version before it activates.

For a full list of KIPs, features, and bug fixes, see the Apache Kafka 4.4 release notes.

Clients

This release updates client libraries with the following improvements:

• KIP-1242 Detection and handling of misrouted connections: Adds the client configuration metadata.cluster.check.enable (default true), which validates that a client is talking to the cluster it expects and can trigger a REBOOTSTRAP_REQUIRED response instead of silently misrouting requests. Existing clients and older brokers are unaffected.

• KIP-1332 Dynamic memory allocation for the Kafka producer: The new buffer.memory.allocation.strategy configuration (default full) adds an incremental value, supported only when compression.type is none. Under the default strategy the producer reserves the full batch.size for every partition it writes to. Incremental allocation instead scales memory with actual throughput and linger time, which matters most for high-cardinality keyed workloads spread across many low-volume partitions. This is opt-in, and the default preserves current behavior.

• KIP-1123 Rack-aware partitioning for Kafka Producer: Adds the producer configuration partitioner.rack.aware (default false), which uses the existing client.rack setting to keep produced traffic within a rack where possible. This is opt-in, and the default preserves current partitioning behavior.

• KIP-909 DNS resolution failure should not fail the clients: Adds the client configuration bootstrap.resolve.timeout.ms (default 0). The default preserves synchronous DNS resolution. A positive value enables asynchronous resolution with a retry budget instead of failing the client outright. Applications that opt in need to handle the new BootstrapResolutionException, thrown on resolution failure. This exception can’t be retried.

• KIP-1323 Initialization of share group offsets from a specific offset or a file: kafka-share-groups adds --to-offset, --to-current, --export, and --from-file so you can migrate an existing consumer group’s position onto a share group instead of reprocessing from the beginning or skipping the backlog. These options work against share groups on Kafka 4.2 or later.

Security

KRaft controllers now apply dynamic updates to the audit log configuration without a restart. For more information, see Use Properties Files to Configure Audit Logs in Confluent Platform.

Cluster management

Confluent for Kubernetes

For Confluent for Kubernetes release notes, see Confluent for Kubernetes Release Notes.

Ansible Playbooks for Confluent Platform

For Ansible Playbooks for Confluent Platform release notes, see the Ansible Playbooks for Confluent Platform.

Confluent Private Cloud

Confluent Private Cloud 8.4 introduces multi-tenancy, which enables platform teams to run multiple isolated logical Kafka clusters on a single shared physical Kafka cluster managed through Confluent for Kubernetes. For more information, see the Confluent Private Cloud Release Notes.

Confluent Control Center

Confluent Control Center 2.7 includes multi-tenancy support for Confluent Private Cloud deployments. For more information, see the Control Center Next-Gen Release Notes.

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 documentation and the Control Center Next-Gen Release Notes.

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.

Kafka Streams

Kafka Streams includes the following changes in Confluent Platform 8.4.

• KIP-892 Transactional semantics for state stores: Kafka Streams applications using exactly-once semantics can now opt into transactional state stores with enable.transactional.statestores (default false). Uncommitted writes are held in a buffer, capped by statestore.uncommitted.max.bytes (default 64 MB), and discarded on an unclean shutdown instead of forcing a full changelog restore, which speeds up recovery on large state stores. Interactive queries can request an isolation level with StateQueryRequest.withIsolationLevel(), defaulting to READ_UNCOMMITTED unless default.interactive.query.isolation.level is changed. This is opt-in with no on-disk format change, and downgrade is supported without a state restore.

• KIP-1331 Streams Group Topology Description Plugin: Adds a broker-side plugin interface, configured with group.streams.topology.description.plugin.class, that lets the broker serve a running application’s topology description back through the Admin API. Streams clients push their topology automatically unless topology.description.push.enabled is set to false.

• KIP-1357 Broker-side custom assignors for streams groups: Streams groups can now use a custom task assignor registered broker-side through group.streams.assignors, with a group selecting one by name through streams.assignor.name. If you have a custom task.assignor.class under the classic protocol, you must reimplement it against the new broker-side assignor interface to migrate.

• KIP-1285 DSL opt-in support for headers-aware state stores: The DSL can now opt into headers-aware KeyValue, Window, and Session state stores. Versioned state store DSL support is not included in this release.

• KIP-1340 Expose both mapped key and stream key in Streams-GlobalKTable joins: Adds four new KStream.join/leftJoin overloads that expose both the mapped key and the original stream key to the value joiner. The four existing ValueJoinerWithKey-based overloads are deprecated. Migrating is a one-line lambda change.

• KIP-1356 Introduce IQv2 for headers-aware state stores: Adds TimestampedKeyWithHeadersQuery and three related range/window query classes so interactive queries can read stored headers back out. Queries against natively built header stores that previously returned UNKNOWN_QUERY_TYPE now succeed with header-stripped results.

• KIP-1284 Introduce CloseOptions.DEFAULT for Kafka Streams: The no-argument KafkaStreams.close() now delegates to the new CloseOptions.DEFAULT instead of close(CloseOptions.REMAIN_IN_GROUP). CloseOptions.DEFAULT adapts to the active protocol and membership type: under the Streams protocol with dynamic membership, the member now leaves the group on close, but under the classic protocol or static membership, it still remains in the group. If you explicitly set CloseOptions.REMAIN_IN_GROUP, that choice is now honored in every case. Previously it was silently ignored under the Streams protocol.

• KIP-1321 Headers-aware StreamPartitioner: StreamPartitioner gains a headers-aware partitions() method, added as a default method so existing implementations keep compiling and running unchanged. The built-in DefaultStreamPartitioner now passes record headers into key serialization. If your key serializer’s output varies based on headers, partition assignment can shift on upgrade and break co-partitioning with pre-upgrade data. To preserve the previous behavior, implement a custom StreamPartitioner that passes empty headers to the serializer. The header-less partitions() overload is deprecated for removal in 5.0.

Schema Registry

Schema Registry includes the following changes in Confluent Platform 8.4.

• Schema Registry supports Logical Types, which let you define a schema with SQL types, such as STRUCT, INT, and VARCHAR, and skip writing Avro, Protobuf, or JSON Schema directly. Schema Registry translates the schema to the format you register it in and back on request. Logical Types include a VARIANT type for semi-structured data and CHECK constraints for data quality.

• Adds the LOGICAL compatibility policy, which you can set alongside STRICT and LENIENT. The policy adds checks based on how Apache Flink® or Iceberg maps a schema to SQL, catching changes that pass the existing checks but still corrupt data after that mapping. LOGICAL conflicts with the FORWARD and FORWARD_TRANSITIVE compatibility types. Before you set it globally, check which subjects inherit the global policy.

• Data contracts add inline data quality rules, which embed a rule in the schema text at the message or field level. Inline rules run only when the client sets validation.rules.execution, and only during serialization. The CEL and CEL_FIELD rule executors also add functions for Decimal, timestamp, and Variant values.

• Adds explicit topic-subject associations, which link a topic directly to a subject, independent of the topic’s name. A new topic can then reuse an existing subject’s schema. Create associations with the Schema Registry Associations API. An association affects broker-side schema validation only for a topic whose subject name strategy is AssociatedNameStrategy. For more information about subject name strategies, see Subject name strategy.

Kafka Connect

Kafka Connect includes the following changes in Confluent Platform 8.4.

• In line with the Support policy for self-managed connectors, a specific minimum version of connectors is required for support in Confluent Platform 8.4. For details, see Supported Connector Versions in Confluent Platform 8.4.

Unified Stream Manager

USM Agent 1.3, released alongside Confluent Platform 8.4, includes support for managing self-managed Kafka Connect components through the USM control plane in Confluent Cloud.

For the full USM Agent release history, see Unified Stream Manager Agent release notes. For the Confluent Platform versions that each agent version supports, see Supported Versions and Interoperability for Confluent Platform. For Unified Stream Manager (USM) updates in Confluent Cloud, see the Confluent Cloud release notes.

ksqlDB

ksqlDB continues to be available as part of Confluent Platform 8.4. For more information, see Use Docker to Install ksqlDB for Confluent Platform.

JMX Prometheus exporter upgrade

Confluent Platform 8.4 upgrades the bundled jmx_prometheus_javaagent from 0.20.0 to 1.6.0. This is a major version upgrade and includes breaking changes that might require updates to your existing monitoring configuration.

• The metrics endpoint no longer serves on the root path. Update your Prometheus scrape configuration to use /metrics instead.

• Some JVM metric names changed to conform to the OpenMetrics specification. If your dashboards or alerts reference these JVM metrics, update them to match the new names. For details, see the jmx_exporter migration reference.

• MBean names that normalize to the same metric name now include an additional _objectname label that identifies the source MBean. Existing queries or dashboards that don’t account for this new label might need adjustment.

For the complete list of changes across all intermediate versions, see the jmx_exporter release notes. For the steps to prepare your monitoring configuration before you upgrade, see Preparation.

Deprecation warnings

Confluent Platform 8.4 includes the following deprecation warnings.

• KIP-1232 Deprecate broker.id config: deprecates the broker.id server configuration in favor of node.id. Kafka 4.4 logs a startup warning. broker.id is removed from ServerConfigs in Kafka 5.0, at which point setting only broker.id without node.id throws a ConfigException. Tiered storage plugins reading TopicBasedRemoteLogMetadataManagerConfig.BROKER_ID must migrate to .NODE_ID before then.

• KIP-1200 Deprecate ClientQuotaCallback#updateClusterMetadata: deprecates the ClientQuotaCallback#updateClusterMetadata broker plugin method, marked @Deprecated(forRemoval=true) in Kafka 4.4 with removal in 5.0. This affects custom quota-callback plugin authors only. Behavior is fully backward compatible until removal.

• KIP-1301 Deprecate Yammer-based metrics in GroupCoordinatorMetrics: deprecates seven Yammer-based metrics under kafka.coordinator.group:type=GroupMetadataManager in favor of Kafka Metrics equivalents (group-count, offset-count, classic-group-count). Dashboards built on the old Yammer metric names must migrate before the 5.0 removal.

• KIP-1220 Unify kafka-broker-api-versions tool to cluster-tool: deprecates the kafka-broker-api-versions tool, targeted for removal in the next major version. Use the new kafka-cluster api-versions subcommand instead, which adds --bootstrap-controller support that the deprecated script never had.

• Storing the Confluent license in the _confluent-license topic is deprecated. Confluent Platform 8.5 is expected to stop reading and writing the license there by default and use the _confluent-command topic instead. To migrate now, set confluent.license.topic=_confluent-command on every component that reads the license from the _confluent-license topic. For more information, see License Configurations for Confluent Platform.

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

The cp-server-connect-base and cp-kafka-connect-base Docker images are removed in Confluent Platform 8.4. They are no longer built or published. Previously published -base tags for 8.3.x and earlier supported releases remain available on Docker Hub. These base images were functionally identical to cp-server-connect and cp-kafka-connect. If you build custom 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.

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.

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 overview.

Supported versions and interoperability

Confluent Platform 8.4 supports Java 25, 21, and 17. The base Docker images use Eclipse Temurin 25, the latest long-term support (LTS) release. For more information, see Java.

For the full list of supported versions and interoperability of Confluent Platform and its components, see Supported Versions and Interoperability for Confluent Platform.

How to download

You can download Confluent Platform at https://confluent.io/download/. For detailed information, see the Install Confluent Platform On-Premises 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:

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.

To upgrade Confluent Platform to a newer version, see the Upgrade Confluent Platform documentation.

Questions?

If you have questions about this release, you can reach out through the community mailing list or community Slack. If you are a Confluent customer, you are encouraged to contact Confluent Support.

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