Apache NiFi 2.11.0 - Kafka and Flow Upgrade Changes

Apache NiFi rel/nifi-2.11.0, published August 3, 2026, changes Kafka components to use SSL instead of PLAINTEXT as the default Security Protocol. The release also tightens versioned flow upgrades and synchronization, which matters more to operators than most of the dependency and internal cleanup among its 115 resolved issues.

The full release notes and downloads are on the GitHub release page.

The main configuration change is NIFI 16077: Kafka components now default the Security Protocol to SSL rather than PLAINTEXT. Any flow that depends on the implicit value needs an explicit review before the upgrade. A default is configuration, not proof that broker listeners, trust stores, and certificates are ready.

The winners are installations that already require encrypted Kafka transport. Newly configured components are less likely to start from a plaintext assumption. The risk sits with environments that still expose plaintext listeners or clone components without setting the protocol. Those flows can select a different transport after the upgrade unless the intended value is recorded in their configuration.

ConsumeKafka also gains a hex message format. This gives operators a direct way to inspect binary Kafka payloads without treating arbitrary bytes as text. It is a small processor change, but useful when checking framing, serialization output, or corrupt events at the ingestion boundary.

NiFi 2.11.0 adds initial rebase support to Registry Clients. The word initial matters. Rebase can make flow promotion easier when local and registry state have diverged, but repository specific conflict cases still need staging tests before this becomes part of automated deployment work.

Two fixes reduce failure modes around versioned flows. NIFI 16071 enables newly added controller services during a versioned flow upgrade. This keeps an upgraded flow from arriving with new services present but inactive. NIFI 16085 fixes synchronization when a Parameter Provider backed Parameter Context contains a parameter that is not marked as provided. That case previously stopped flow synchronization instead of accepting the context state.

Together, these changes improve the path from registry revision to runnable flow. They do not remove the need to validate controller service dependencies, parameter resolution, and external credentials after import. They remove two specific sources of avoidable drift and synchronization failure.

The supplied notes do not identify a general breaking change section. The Kafka default is still a behavior change and should be treated as one. Inventory Kafka components where Security Protocol is unset, record whether each target listener expects SSL or PLAINTEXT, and set the value explicitly before moving production flows.

In staging, upgrade a versioned flow that introduces a controller service and uses a Parameter Provider backed context. Confirm that the service is enabled, parameters resolve, and the flow reaches its expected running state. For Registry Client rebase, test at least one clean case and one conflict case, then document the recovery path before adding it to promotion automation.

Capture the effective component values before and after the staging run. Useful evidence includes Kafka connection errors, controller service state after import, parameter resolution during synchronization, and the result of a Registry Client conflict. That record makes rollback decisions based on changed behavior rather than on the release version alone.