Here are the highlights:

Connection Expiration Filter

Thanks to the work of May-Abo, a new filter joins the family! The Connection Expiration filter closes client connections after a configurable maximum age. This is perfect for dynamic environments like Kubernetes where you want to rebalance connections across proxy instances as pods scale up or down.

Entity Isolation Filter

Multi-tenancy gets even better with the Entity Isolation filter. Initially supporting groupId and transactionalId entity types, this filter helps you enforce isolation boundaries between tenants sharing a cluster.

Record Validation Filter - Apicurio v3 Upgrade

• Record validation just got a major upgrade with Apicurio v3. The default schema identification has changed from globalId to contentId for better interoperability with Confluent-based Kafka clients. To support migrations, you can still use the old behavior by setting wireFormatVersion to V2, though this mode is deprecated and will be removed in a future release.
• The schema validation filter can now connect to a schema registry protected by internally signed TLS certificates. One less obstacle for air-gapped or enterprise environments.

Kubernetes Operator Enhancements

Two improvements for Kubernetes users:

• OpenShift Route Support: Enable external access to Virtual Clusters via OpenShift Routes using KafkaProxyIngress.spec.openShiftRoute. Off-cluster client access is now a breeze on OpenShift.
• Server-Side Apply: The operator now uses Server-Side Apply for all dependent resources. Existing deployments are unaffected, and externally-applied patches (like annotations from observability tooling) will now survive operator reconciles.

Javadocs on the Website

Public API Javadocs are now published alongside version-specific documentation on kroxylicious.io, making it easier to explore our APIs without leaving your browser.

Configuration Improvements

• Configurable Netty shutdown: New shutdownQuietPeriod and shutdownTimeout fields give you fine-grained control over Netty shutdown behavior with Go-style durations.
• Duration serialization: Filter Config classes can now use Duration types that automatically serialize to/from Go-style strings (e.g., “1h”) without any annotations.

Artefacts

Binary distributions and container images are available on the download page.

Feedback

We’d love to hear from you! Whether you’re kicking the tyres, running Kroxylicious in production, or just find the project interesting — drop by and say hello. You can reach us through Slack, GitHub or even bsky), or tell us in person on one of our upcoming community calls.

Key Takeaways:

• Zero Client Changes: Kroxylicious is wire-protocol compatible. Your applications keep using their existing Kafka clients without knowing a proxy is in the middle.
• Centralized Control: Instead of chasing down policy updates across different languages and teams, you enforce them at the proxy layer.
• Plug-and-Play Filters: Use the built-in Filter mechanism to intercept and transform traffic. For example, our Record Encryption Filter can automatically handle PII encryption before data ever touches the broker.

Ready to see it in action? Head over to kroxylicious.io or jump straight into our quickstarts. We’ve also conveniently recorded a video demonstration of the Proxy Quickstart.

We’ve always believed that open-source success is built on transparency, community trust, and a shared vision. The project continues to evolve, and our governance model needs to change with it while ensuring the project remains truly vendor-neutral.

Decoupling Roles: Introducing Committers and Project Managers

Previously, we relied on a flat “Code Owner” structure. While this worked well in the early days, we realised it was starting to make it harder to scale the project: In order to grow, we are going to need more people able to review and merge contributions. But those people might not always be interested, or able to make a commitment to helping ensure the project’s long term sustainability.

To solve this, we have split these duties into two distinct roles:

• Committers focus on code quality and technical output. They have write access to our repositories and are responsible for reviewing and merging contributions.
• Project Managers (PMs) focus on the long-term health and sustainability of the project. They manage the governance files, handle community elections, and ensure the project remains aligned with its goals and deal with our interactions with the CommonHaus foundation.

We hope that by decoupling these roles, we’ll be better able to scale our number of Committers to match our review volume without burdening them with administrative overhead. It creates a clearer pathway for contributors to take on leadership roles based on their interests, whether that’s deep technical work or project stewardship.

These changes are already reflected in our updated GOVERNANCE.md.

The initial COMMITTERS.md and PMs.md are the same people who were previously code owners and project admins. This revised governance model has not changed anyone’s access.

Moving Beyond CODEOWNERS

We are also moving away from using the GitHub CODEOWNERS file to enforce directory-level restrictions.

We trust Committers to know the limits of their expertise and to pull in the right subject matter experts when a PR spans areas outside their immediate knowledge. This reduces the friction of managing complex ownership files and avoids the pitfalls of stale ownership definitions that don’t match the current team structure.

Strengthening Our Organizational Memory

The 90 day history we have on our free Slack workspace is starting to hurt. As we grow, we need to ensure that important technical decisions aren’t lost.

We think that, even in 2026, mailing lists are the least-worst way to share and record formal technical discussions and voting.

• The barrier to entry is low
• Everyone gets their own copy of the history, but there’s a public archive too
• Everyone can use familiar tools to organise and search history

These features should ensure our decision-making process is archived, searchable, and publicly verifiable.

So we’d like the kroxylicious-dev list to be our primary channel for development discussions, open to all contributors and committers. Meanwhile, Slack remains our home for quick, day-to-day conversation.

So how do you join the kroxylicious-dev list?

• You can read and subscribe to the list on google groups.
• Alternatively, you can subscribe by sending an empty email to kroxylicious-dev+subscribe@googlegroups.com,
• and unsubscribe by sending an empty email to kroxylicious-dev+unsubscribe@googlegroups.com

The project managers will use a private list, but only for communication that needs to remain private. You can contact them by email to kroxylicious-pms@googlegroups.com.

Building Community Connection

Governance isn’t just about documents and voting; it’s about people. We want to ensure that our contributors feel connected to the project’s direction and to each other.

To facilitate more direct and synchronous collaboration, we are launching a regular Community Call that anyone can join.

The Kroxylicious community is spread around the world, and we want to be as inclusive as possible. In particular, we didn’t want the meeting to always be in the middle of the night for someone in an unfortunate timezone. To support this, while the meeting cadence is every two weeks, the meeting time will alternate by ±12 hours every other call. But timezones and daylight savings time makes it a bit tricky to describe in a blog post.

You can see the time of upcoming meetings on the website, and add the meeting schedule to your calendar app.

What’s Next?

We’re excited to continue building Kroxylicious in an environment that is open, inclusive, and built to last. Check out the updated docs and let us know what you think!

Here are the highlights:

Kafka 4.2 Support

Hot off the press — Kroxylicious now bites into Kafka 4.2! We are keeping pace with upstream Kafka releases so your filters can take advantage of new RPCs as they land. All versions of Kroxylicious can be deployed in front of any supported version of Apache Kafka.

Authorizer Filter: Transactional ID Support

The Authorizer Filter just got more powerful. It now covers transactional ID authorization, so you can enforce WRITE and DESCRIBE operations with full parity to Apache Kafka’s own ACL authorization.

Kubernetes Secrets as Trust Anchors

Good news for Kubernetes users: you can now use Kubernetes Secrets in the trustAnchorRef field of KafkaService and VirtualKafkaCluster custom resources. One less thing to manage outside of your cluster.

Filter API: API Version in onResponse

ResponseFilter#onResponse now receives API version information via a new five-argument form. The previous four-argument form is deprecated.

Munching on Idle Connections

Ever wanted to clean up connections that have outstayed their welcome? Kroxylicious can now be configured with idle timeouts for client connections:

• unauthenticatedIdleTimeout — for connections that haven’t authenticated yet
• authenticatedIdleTimeout — for authenticated connections

Both use Go-style duration formats. And to help you keep an eye on things, a new metric kroxylicious_client_to_proxy_disconnects_total tracks why connections are closing — idle timeout, client-initiated, or server-initiated.

Artefacts

Binaries are attached to the GitHub release and available through Maven Central.

Container images are available on quay.io:

Feedback

We’d love to hear from you! Whether you’re kicking the tyres, running Kroxylicious in production, or just find the project interesting — drop by and say hello. You can reach us through Slack, GitHub or even bsky), or tell us in person on one of our upcoming community calls.

We’ve refreshed our dependencies, including an essential upgrade to Apache Kafka 4.2.0. We’ve also smoothed out the setup process, ensuring the new Kafka Queues feature works seamlessly straight out of the box.

Feedback

Please let us know, through Slack or GitHub, if you find the extension interesting or helpful.

The main change in this release is the upgrade of Testcontainers dependency from 1.x to 2.x. The Junit 5 Extension uses Testcontainers to create broker instances for your Junit tests (when you choose container-based provisioning). As a user of the Junit 5 Extension, the changes should be completely transparent to you.

Feedback

Please let us know, through Slack or GitHub, if you find the extension interesting or helpful.

The main highlights of this release are:

Filter API Improvements

• Filters now have a convenient mechanism to convert from topic ids KIP-516 to topic names this is based on design proposal#008
• Filters now have access to a Subject API that provides convenient access to the authenticated principals established by the channel. This is a building block for filters that need to enforce authorization checks or want to write an audit trail of Kafka actions. Further details and context can be found in design proposal#009

Authorizer Filter

We’ve added a new Authorizer Filter that can authorize Topic operations using the same semantics as Kafka own Authorization API. This allows you to enforce authorizations rules at the proxy.

Azure KMS integration for Record Encryption

With this release, Record Encryption now has the capability to use Azure Vault for storage of the key material used to encrypt Kafka records.

Feedback

Please let us know if you find the project interesting or helpful, and especially if you have deployed it in production. You can reach us through Slack, GitHub or even bsky).

Feedback

Please let us know, through Slack or GitHub, if you find the extension interesting or helpful.

The main highlights of this release are:

Librdkafka compression Fix

This patch addresses an issue where the proxy failed to relay special handling logic introduced in Apache Kafka broker v4.0. This logic is required for deprecated ProduceRequest versions (v0-v2).

The bug prevented librdkafka clients older than v2.11.0 from enabling compression when connecting through the proxy. As librdkafka supports a wide variety of language bindings we are releasing this fix as a special patch release rather than waiting for v0.18.0.

Feedback

Please let us know if you find the project interesting or helpful, and especially if you have deployed it in production. You can reach us through Slack, GitHub or even bsky).

The main highlights of this release are:

Netty improvements

• Kroxylicious now depends on Netty 4.2, which brings upgrades such as making io_uring a first class transport and an improved memory allocator.
• We now offer some netty-specific metrics which give insights into memory allocation and executor task queues.
• Netty worker thread counts are now configurable.

Filter Archetype

Get started with developing your own Custom Filter for Kroxylicious! You can now create a sample Filter project using a maven archetype to get up and running quickly. The generated project demonstrates how to structure a Filter project, and shows off our powerful integration testing tools which can simplify testing Filters against a real Apache Kafka cluster.

Run mvn archetype:generate -DarchetypeGroupId=io.kroxylicious -DarchetypeArtifactId=kroxylicious-filter-archetype -DarchetypeVersion=0.17.0 to get started!

For a more comprehensive guide to how to work with the Filter Archetype, see the Developer Quickstart.

Kroxylicious 1.0.0 proposal

We are currently discussing a proposal to release Kroxylicious 1.0.0, and formalize our support policy for patch releases. The aims are:

• Move to 1.0.0 to signal production-readiness
• Stronger API/config stability guarantees until 2.0.0
• Clear support policy for patch releases

This will provide more predictability for everyone using Kroxylicious and developing against its APIs. Your feedback is essential to get this right. Please feel free to review and leave feedback on the proposal.

Feedback

Please let us know if you find the project interesting or helpful, and especially if you have deployed it in production. You can reach us through Slack, GitHub or even bsky).