Red Hat build of Quarkus 3.20: Release highlights for developers

The Red Hat build of Quarkus 3.20 is now generally available, bringing enhanced cloud-native observability, a modern WebSocket extension, and reflection-free Jackson serialization for faster, native-ready applications.

Let’s take a look at the highlights of this release. For a complete list of new features, check out the official Red Hat build of Quarkus 3.20 release notes.

Enhanced observability with OpenTelemetry Logging

The Red Hat build of Quarkus 3.20 enhances support for OpenTelemetry Logging, automatically embedding trace and span IDs into application logs. This integration simplifies the correlation of logs and traces, facilitating faster debugging and streamlined observability in cloud-native environments. It’s a simple way to make troubleshooting and debugging in cloud-native environments a whole lot easier.

From a developer productivity perspective, OpenTelemetry Logging offers:

• Reduced manual effort: No need for developers to manually inject trace or span context into logs.
• Faster debugging: Quickly correlate logs and traces to identify and resolve issues across microservices.
• Simplified observability setup: Native integration minimizes configuration and setup time.
• Improved consistency: Developers experience a unified, reliable view of logs and traces without switching tools.
• Cloud-native readiness: Applications are automatically aligned with observability best practices needed for production Kubernetes and OpenShift environments.

To learn more about OpenTelementry Logging, check out this guide.

WebSocket Next

Quarkus WebSocket Next introduces a simpler, annotation-driven API (@WebSocket, @OnTextMessage, and @OnOpen) tailored for reactive applications. It eliminates the boilerplate and complexity of traditional WebSocket programming while offering better integration with Quarkus’s non-blocking runtime—perfect for building efficient, scalable, real-time features like dashboards, chats, and live data feeds.

Key benefits of WebSockets Next include:​

• Simplified API: Utilizes annotations such as @WebSocket, @OnTextMessage, and @OnOpen to define server and client endpoints with ease.
• Reactive integration: Built to work efficiently with Quarkus's reactive programming model, ensuring optimal performance and scalability. ​
• Lightweight and efficient: Does not implement the Jakarta WebSocket specification, allowing for a more streamlined and modern approach to WebSocket communication.

The current Quarkus WebSocket extension, based on the Jakarta WebSocket specification, continues to be fully supported for Red Hat build of Quarkus 3.x releases.

To get started with Quarkus WebSockets Next, you can follow the official tutorial. For a deeper dive into the capabilities and usage of WebSockets Next, refer to the reference guide.

Performance optimizations: Reflection-free Jackson serialization

Quarkus supports reflection-free Jackson serialization and brings better performance, faster cold starts, and native-readiness, all while maintaining the ease of use developers expect from Jackson. Reflection-free Jackson serialization refers to generating JSON serializers at build time instead of relying on runtime reflection. 

When enabled, Quarkus automatically generates static StdSerializer classes during the build process for REST endpoint payloads, removing the need for runtime reflection.

Key features include:

• Faster startup times: Eliminating reflection improves application boot time—critical for cloud-native and serverless workloads.
• Better native compatibility: Reduces the complexity of building native images with GraalVM, since fewer reflective calls require manual configuration.
• Improved performance: Serialization is faster at runtime because the logic is compiled rather than interpreted via reflection.
• Minimal effort: Developers benefit from improved performance and compatibility without needing to change application code.

For more information, see the JSON serialization section of the Writing REST services with Quarkus REST guide.

Advanced security: Multi-authentication mechanisms

Red Hat build of Quarkus 3.20 supports combining multiple authentication mechanisms—like mutual TLS (mTLS) and OpenID Connect (OIDC) bearer tokens—within a single request. This simplifies the implementation of advanced security patterns, such as access token binding to client certificates, without requiring complex custom logic. Using a simple property, you can configure whether authentication stops at the first success or requires all mechanisms to validate.

By handling these multi-auth scenarios out of the box, Quarkus reduces boilerplate, streamlines security implementation. As a developer, you can focus more on building features and less on managing authentication flows.

To learn more, check out the Red Hat build of Quarkus security architecture guide.

Secure and stable base with UBI 9 

With this release, Quarkus is moving to UBI 9 (Universal Base Image 9) by default, which means a more secure, stable, and future-ready base image, ideal for enterprise-grade Java applications in cloud-native environments. The move to UBI 9 brings several key benefits to Quarkus and its users, particularly in enterprise and cloud-native environments:

• Stronger security posture: UBI 9 is based on RHEL 9, which includes the latest security enhancements, cryptographic updates, and hardened defaults—ensuring Quarkus apps are built on a more secure foundation.
• Longer life cycle and stability: UBI 9 comes with extended Red Hat support, giving Quarkus users confidence in long-term stability for containerized and production deployments.
• Optimized for modern infrastructure: It aligns with modern operating environments, cloud platforms, and toolchains, ensuring better compatibility with OpenShift 4.x+ and cloud-native stacks.
• Smaller and more efficient base: UBI 9 offers a leaner footprint, reducing image size and attack surface, which improves performance and operational efficiency.

Upgrade guide

To make migrating to the Red Hat build of Quarkus 3.20 seamless for users, we have created a migration guide and automated tooling to facilitate this process.

Support

Starting with the Red Hat build of Quarkus 3.2, major releases—including 3.20—receive a 3-year life cycle, aligning with the community's LTS versions to provide long-term stability for users.

For more information on the Red Hat build of Quarkus life cycle and support policies, refer to the Red Hat build of Quarkus Life Cycle and Support Policies.