Red Hat Summit Red Hat SummitSupportConsoleDevelopersStart a trialContact

Chapter 1. Release notes for Red Hat build of Quarkus 3.27

Release notes provide information about new features, notable technical changes, features in technology preview, bug fixes, related advisories, and known issues for Red Hat build of Quarkus 3.27.

These include the following notable changes:

Information about upgrading and backward compatibility is also provided to help you make the transition from an earlier release.

1.1. About Red Hat build of Quarkus
Copy link

Red Hat build of Quarkus is a Kubernetes-native Java stack optimized for containers and Red Hat OpenShift Container Platform. Quarkus is designed to work with popular Java standards, frameworks, and libraries such as Eclipse MicroProfile, Eclipse Vert.x, Apache Camel, Apache Kafka, Hibernate ORM with Jakarta Persistence, and Jakarta REST.

As a developer, you can choose the Java frameworks you want for your Java applications, which you can run in Java Virtual Machine (JVM) mode or compile and run in native mode. Quarkus provides a container-first approach to building Java applications. The container-first approach facilitates the containerization and efficient execution of microservices and functions. For this reason, Quarkus applications have a smaller memory footprint and faster startup times.

Quarkus also optimizes the application development process with capabilities such as unified configuration, automatic provisioning of unconfigured services, live coding, and continuous testing, which provides instant feedback on your code changes.

As an application developer, you can access two different versions of Quarkus: the Quarkus community version and the productized version, Red Hat build of Quarkus.

The following table describes the differences between the Quarkus community version and Red Hat build of Quarkus.

Expand
FeatureQuarkus community versionRed Hat build of Quarkus versionDescription

Access to the latest community features

Yes

No

With the Quarkus community version, you can access the latest feature developments.

Red Hat does not release Red Hat build of Quarkus to correspond with every version that the community releases. The cadence of Red Hat build of Quarkus feature releases is approximately every six months.

Enterprise support from Red Hat

No

Yes

Red Hat provides enterprise support for Red Hat build of Quarkus only. To report issues about the Quarkus community version, see Quarkusio/quarkus - issues.

Access to long-term support

No

Yes

The lifecycle for a major release of Red Hat build of Quarkus is divided into two support phases: full support and maintenance support.

For information about the product lifecycle, timelines, and support policies of Red Hat build of Quarkus, see Product Life Cycles for Red Hat build of Quarkus and Red Hat build of Quarkus Life Cycle and Support Policies.

Common Vulnerabilities and Exposures (CVE) fixes and bug fixes backported to earlier releases

No

Yes

With Red Hat build of Quarkus, selected CVE fixes and bug fixes are regularly backported to supported streams.

For more information about maintenance support, see Red Hat build of Quarkus Life Cycle and Support Policies.

Tested and verified with Red Hat OpenShift Container Platform and Red Hat Enterprise Linux (RHEL)

No

Yes

Red Hat build of Quarkus is built, tested, and verified with Red Hat OpenShift Container Platform and RHEL. Red Hat provides both production and development support for supported configurations and tested integrations according to your subscription agreement. For more information, see Red Hat build of Quarkus supported configurations.

Built from source with secure build systems

No

Yes

In Red Hat build of Quarkus, Red Hat provides the core platform and all supported extensions with secure software delivery, which means they are built from source, scanned for security issues, and license usage is verified.

Access to support for JDK and Red Hat build of Quarkus Native builder distribution

No

Yes

Red Hat build of Quarkus supports certified OpenJDK builds and certified native executable builders. See admonition below. For more information, see Red Hat build of Quarkus supported configurations.

Important

To build native Linux executables, Red Hat build of Quarkus supports using the Red Hat Build of Quarkus Native builder image (quarkus/mandrel-for-jdk-21-rhel8), which is based on GraalVM Mandrel.

Red Hat build of Quarkus does not support building native executables by using Oracle GraalVM Community Edition (CE), Mandrel community edition, or any other GraalVM distributions. For more information, see Compiling your Red Hat build of Quarkus applications to native executables.

This section overviews the new features, enhancements, and technical changes introduced in Red Hat build of Quarkus 3.27.

1.3.1. AI/ML
Copy link

Quarkiverse, the Quarkus community extensions hub, introduces Dev Assistant through the Quarkus Chappie extension (quarkus-chappie). Dev Assistant helps you troubleshoot exceptions, generate test code, complete TODO sections, and understand complex code by providing AI-powered assistance during development mode. The feature integrates with OpenAI-compatible services or a local Ollama instance, is configured through the Dev UI, and adds no overhead to production applications.

Note

This extension is not a supported feature in Red Hat build of Quarkus.

For more information, see the Quarkus Dev Assistant guide.

1.3.2. Data
Copy link

In the current release, you can use Hibernate ORM and Hibernate Reactive together in the same persistence unit.

This capability enables applications to combine blocking and reactive persistence, supporting mixed workloads and partial adoption of reactive features alongside imperative code.

For more information, see the GitHub Pull Request #44473.

1.3.2.2. Hibernate ORM: Jakarta Data introduced
Copy link

In the current release, Red Hat build of Quarkus introduces Jakarta Data integration through the Hibernate ORM extension, quarkus-hibernate-orm.

The Jakarta Data API, a Jakarta EE 11 specification, simplifies how you access and interact with databases and other data sources in Java applications. It provides a standardized way of defining repositories and the ability to build queries in a type-safe manner.

Jakarta Data requires an additional runtime dependency to be added to your pom.xml file.

1.3.2.2.1. Getting started
Copy link

  1. Configure the hibernate-processor annotation processor in your build tool: 

    <plugin>
    <artifactId>maven-compiler-plugin</artifactId>
    <configuration>
        <annotationProcessorPathsUseDepMgmt>true</annotationProcessorPathsUseDepMgmt>
        <annotationProcessorPaths>
            <path>
                <groupId>org.hibernate.orm</groupId>
                <artifactId>hibernate-processor</artifactId>
                <!-- No artifact version is required as it is managed by Red&#160;Hat build of Quarkus.  -->
            </path>
            <!-- Other processors that might be required by your application -->
        </annotationProcessorPaths>
        <!-- Other compiler plugin configuration options -->
    </configuration>
</plugin>

     

  2. Add the dependency in your pom.xml file: 

    <dependency>
    <groupId>jakarta.data</groupId>
    <artifactId>jakarta.data-api</artifactId>
</dependency>

     

1.3.2.2.2. Defining repositories
Copy link

With this dependency and the hibernate-processor annotation processor configured, you can create repositories, which you can use as any other bean.

Example:

  1. Assume that you have an entity. For example: 

    @Entity
public class MyEntity {
    @Id
    @GeneratedValue
    public Integer id;
    @Column(unique = true)
    public String name;
}

     

  2. Define a repository for this entity: 

    @Repository
public interface MyRepository extends CrudRepository<MyEntity, Integer> {

    @Query("select e from MyEntity e where e.name like :name")
    List<MyEntity> findByName(String name);

    @Delete
    void delete(String name);

}

     

    In this example:

    • Extending CrudRepository allows you to skip the boilerplate definition of CRUD operations and use one of the available interfaces.
    • The @Query annotation shows how to add custom queries with parameters by providing your query string.
    • The @Delete annotation demonstrates adding a custom operation if basic CRUD operations from the Jakarta Data interfaces do not suffice. This example shows a delete operation that removes `MyEntity`s by name.
1.3.2.2.3. Building queries in a type-safe manner
Copy link

By using Jakarta Data’s static metamodel, you can define some query parameters in a type-safe manner.

For example, when constructing a sort by clause.

  1. Using the entity from the previous example, extend the repository with an additional query method that accepts a sorting parameter: 

    @Repository
public interface MyRepository extends CrudRepository<MyEntity, Integer> {

    // other query methods ...

    @Query("select e from MyEntity e where e.name like :name")
    List<MyEntity> findByName(String name, Order<MyEntity> sorts);
}

     

    In this example, you use the sorts parameter to specify the order of the returned entities when calling this repository method.

  2. Leverage the metamodel classes to pass the order to the method: 

    @Inject MyRepository repository;

public void someMethod(){
    var entities = repository.findByName(
        "some name",
        Order.by(_MyEntity.name.asc())
    );
}

     

    In this example, you use the generated static metamodel class _MyEntity and its name attribute reference to construct the Order clause for the query.

To apply this change to existing code, manually perform any additional steps described in this release note. The automatic update process in the Migrating applications to Red Hat build of Quarkus 3.27 guide do not cover this change.

For more information, see the following resources:

In the current release, Hibernate ORM can start offline without requiring a database connection. Hibernate provides sensible defaults for the database dialect and version. You can configure the dialect, version, and dialect-specific settings when your target database differs from the common defaults.

Because no connection is opened at startup, ensure the database schema has been created correctly before the application starts. A live database connection is required at runtime to persist or query data.

For more information, see the following resources:

1.3.2.4. Hibernate ORM: Upgraded to version 7.1
Copy link

Hibernate ORM is the standard Jakarta Persistence implementation and, in the current release, Hibernate ORM is upgraded to version 7.1 with Jakarta Persistence version 3.2.

The upgrade to the Hibernate ORM 7 release series introduces many new features and enhancements.

For a full list of changes, see the following Hibernate migration documentation:

This upgrade introduces breaking changes in Red Hat build of Quarkus. For information about the breaking changes, see the Hibernate ORM: Upgraded to version 7.1 release note.

For more information, see the following resources:

In the current release, named persistence units and data sources are provided with Hibernate Reactive.

This functionality is available as a Technology Preview scope of support feature.

This capability aligns Hibernate Reactive with Hibernate ORM and enables developers to define and use multiple persistence units or data sources in reactive applications.

For more information, see the following resources:

In the current release, Hibernate Reactive has been upgraded to version 3.1.

For more information, see the following resources:

1.3.2.7. Hibernate Search: Upgraded to version 8.1
Copy link

In the current release, Hibernate Search has been upgraded to version 8.1.

The upgrade to the 8.x series introduces several new features, including improvements to Hibernate Search DSL and aggregations that help simplify the calculation of metric aggregations and create bucket aggregations.

Hibernate Search 8.1 remains compatible with version 7.2.

For more information about Hibernate Search 8.1 features and enhancements, see the following Hibernate documentation:

In the current release, Hibernate Validator extends its integration with Hibernate Reactive. This feature enables validation of entities and allows Hibernate Reactive to enrich the database schema.

For example, a @NotNull annotation on an entity attribute results in a not null clause in the corresponding column definition. This behavior provides consistency with Hibernate ORM and improves data integrity across reactive applications.

Constraint mappings defined in XML (validation.xml) are respected for constraint declarations. Quarkus does not support configuring the ValidatorFactory through XML.

This functionality is available as a Technology Preview scope of support feature. Therefore, some limitations apply. For instance, validation across lazy associations might not function properly.

For more information, see the following resources:

In the current release, Hibernate Validator is upgraded to version 9.0.

Note

Hibernate Validator 9.0 implements Jakarta Validation 3.1 for Jakarta EE 11. An upgrade to Hibernate Validator 9.0 is required if you use Jakarta EE 11.

Hibernate Validator 9.0 removes many deprecated constraints and properties. For information about these removals, see the Hibernate Validator 9.0 migration guide.

For more information, see the following resources:

In the current release, you can configure MongoDB client (quarkus-mongodb-client) connections by using the Quarkus TLS registry:

  • When defined, the TLS configuration can be reused by other Mongo connections and any other clients that support the TLS registry.
  • The TLS registry configuration contains all the TLS related settings such as truststore, keystore, mTLS, and hostname verification.

Example: Configuring MongoDB TLS using the TLS registry

# Configure MongoDB connection
quarkus.mongodb.connection-string=mongodb://localhost:27017?tls=true

# Define a named TLS configuration for MongoDB
quarkus.tls.my-mongo.trust-store.pem.certs=server-cert.pem
quarkus.tls.my-mongo.key-store.pem.0.key=client-key.pem
quarkus.tls.my-mongo.key-store.pem.0.cert=client-cert.pem

# Reference the named configuration in MongoDB client
quarkus.mongodb.tls-configuration-name=my-mongo

# Reuse the same TLS configuration for additional MongoDB connections
# quarkus.mongodb.db2.tls-configuration-name=my-mongo
# quarkus.mongodb.db3.tls-configuration-name=my-mongo

 

Example: Disabling hostname verification

quarkus.tls.my-mongo.hostname-verification-algorithm=NONE
quarkus.mongodb.tls-configuration-name=my-mongo

 

In this example:

  • hostname-verification-algorithm=NONE disables hostname verification.

    Warning

    Use only in development environments.

  • tls-configuration-name takes precedence over any direct TLS properties set on the MongoDB client.

For more information, see the TLS configuration section of the Quarkus "Using the MongoDB Client" guide.

1.3.3. Messaging
Copy link

1.3.3.1. gRPC: Server customization
Copy link

In the current release, the gRPC extension introduces customization of the gRPC server build process.

This capability enables advanced scenarios such as tuning the ServerBuilder instance or server options at runtime.

For more information, see the following resources:

1.3.4. Observability
Copy link

Red Hat build of Quarkus 3.27 introduces the Micrometer-OpenTelemetry Bridge (quarkus-micrometer-opentelemetry) extension, which allows the user to create a Micrometer registry implemented with the OpenTelemetry APIs in Red Hat build of Quarkus applications.

This functionality is available as a Technology Preview scope of support feature.

The quarkus-micrometer-opentelemetry extension helps to streamline integration by incorporating features of both quarkus-opentelemetry and quarkus-micrometer, allowing the normal use of the Micrometer API, but handling metrics through OpenTelemetry.

With this new extension, you can now generate Micrometer metrics, OpenTelemetry tracing, logs, and OpenTelemetry metrics by default.

For more information, see the Quarkus Micrometer and OpenTelemetry extension guide.

To apply this change to existing code, manually perform any additional steps described in this release note. The automatic update process in the Migrating applications to Red Hat build of Quarkus 3.27 guide do not cover this change.

1.3.5. Security
Copy link

1.3.5.1. OIDC bearer token step-up authentication
Copy link

In the current release, the Quarkus OpenID Connect (quarkus-oidc) extension supports the OAuth 2.0 Step Up Authentication Challenge Protocol for OIDC bearer token authentication.

You can configure applications to require stronger authentication levels for accessing sensitive endpoints by completing the following tasks:

  • Enforcing specific Authentication Context Class Reference (ACR) values for individual endpoints.
  • Requiring re-authentication when tokens exceed a maximum age.
  • Returning standardized OAuth 2.0 authentication challenges when requirements are not met.

To configure step-up authentication:

  1. Disable proactive authentication in your application.properties: 

    quarkus.http.auth.proactive=false

     

    Setting proactive=false disables proactive authentication so that the @AuthenticationContext annotation can be matched with the endpoint before Quarkus authenticates incoming requests.

  2. Annotate your endpoints with @AuthenticationContext: 

    @Path("/")
public class SecureResource {

    @Path("sensitive-data")
    @AuthenticationContext(value = "strongAuth", maxAge = "PT5M")
    @GET
    public String getSensitiveData() {
        return "sensitive information";
    }
}

     

If a request does not meet the authentication requirements, the server returns a 401 Unauthorized response with a WWW-Authenticate header that contains the required authentication level.

This feature is supported in the following environments:

  • Jakarta REST endpoints
  • WebSockets Next server endpoints. The @AuthenticationContext annotation must be placed at the class level.

When implementing step-up authentication, note the following:

  • For Jakarta REST endpoints, you can configure ACR requirements at both the method and class levels.
  • For WebSockets Next server endpoints, the @AuthenticationContext annotation must be placed at the class level.
  • Tenant-specific configuration is available through application properties.

For more information, see the Step Up Authentication section in the OpenID Connect (OIDC) authentication guide.

In the current release, you can configure the OpenID Connect (OIDC) client (quarkus-oidc-client) extension to refresh tokens asynchronously in the background, improving performance for critical applications.

By default, the OIDC client refreshes tokens during the current request when it detects expiration or near-expiration. This can cause performance bottlenecks in high-throughput applications. The new asynchronous refresh feature proactively refreshes tokens in the background before they expire, preventing token refresh operations from blocking incoming requests. This is particularly beneficial for applications with strict latency requirements or high request volumes.

Example: Configuring periodic asynchronous token refresh

# Configure OIDC client connection
quarkus.oidc-client.auth-server-url=https://auth.example.com/realms/myrealm
quarkus.oidc-client.client-id=my-client
quarkus.oidc-client.credentials.secret=my-secret

# Enable periodic asynchronous token refresh
quarkus.oidc-client.refresh-interval=1m

# Optional: Configure refresh token time skew
quarkus.oidc-client.refresh-token-time-skew=30s

 

In this example:

  • refresh-interval=1m checks every minute if the current access token is expired and must be refreshed. The refresh occurs asynchronously in the background.
  • refresh-token-time-skew=30s (optional) preemptively refreshes the access token when it will expire in less than 30 seconds, avoiding potential HTTP 401 errors from nearly expired tokens.

For more information, see the Refreshing access tokens section of the OpenID Connect (OIDC) client and token propagation guide.

1.3.5.3. OIDC: Clear-Site-Data support on logout
Copy link

In the current release, the OIDC extension adds the ability to set the Clear-Site-Data HTTP response header on logout.

This header instructs the browser to clear local data such as cookies, cache, and storage when the user logs out, which improves security and privacy for end users.

For more information, see the following resources:

1.3.5.4. OIDC: Health readiness check introduced
Copy link

In the current release, the Quarkus OpenID Connect (quarkus-oidc) extension supports health readiness checks. With this feature, you can verify that your application can connect to your OIDC server before serving requests.

To enable OIDC health checks:

  1. Ensure your project has the quarkus-oidc extension and a health check capability, such as quarkus-smallrye-health, in your project dependencies.

  2. Set the following property in your application.properties file: 

    quarkus.oidc.health.enabled=true

     

The health check is disabled by default. When enabled, it pings each configured OIDC tenant’s discovery endpoint. The check returns UP if at least one tenant reports OK status, and DOWN if no tenants are available or all tenants report non-OK statuses (DISABLED, UNKNOWN, or ERROR).

For more information, see the Create OIDC configuration at request time section of the "Quarkus OpenId Connect (OIDC) Expanded Configuration Reference" guide.

In the current release, both REST Client - OpenID Connect Filter (quarkus-rest-client-oidc-filter) and RESTEasy Client - OpenID Connect Filter (quarkus-resteasy-client-oidc-filter) extensions support automatic token refresh when REST client requests receive a "401 Unauthorized" response. With this feature, you can handle expired or revoked access tokens without manual intervention.

To enable automatic token refresh globally, set the property that matches your extension: 

quarkus.rest-client-oidc-filter.refresh-on-unauthorized=true
quarkus.resteasy-client-oidc-filter.refresh-on-unauthorized=true

 

To enable token refresh for specific client endpoints, create a custom filter:

  • For REST Client: 

    @Priority(Priorities.AUTHENTICATION)
public class OidcClientRequestCustomFilter extends AbstractOidcClientRequestReactiveFilter {
    @Override
    protected boolean refreshOnUnauthorized() {
        return true;
    }
}

     

  • For RESTeasy Client: 

    @Priority(Priorities.AUTHENTICATION)
public class OidcClientRequestCustomFilter extends AbstractOidcClientRequestFilter {
    @Override
    protected boolean refreshOnUnauthorized() {
        return true;
    }
}

     

The feature works with both synchronous and reactive REST clients. When a request returns 401, the filter automatically refreshes the access token and retries the request.

For more information, see the Use OidcClient in RestClient Reactive ClientFilter and Use OidcClient in RestClient ClientFilter sections of the "OpenID Connect (OIDC) client and token propagation" guide.

In the current release, with the Quarkus OIDC (quarkus-oidc) extension, you can configure protected resources to advertise OAuth2 Protected Resource Metadata (RFC 9728) through a well-known endpoint. This endpoint returns metadata that includes the resource identifier and, optionally, the authorization servers that protect it. With this metadata, clients can automatically discover authentication requirements without manual configuration.

To enable this feature, set the following property: 

quarkus.oidc.resource-metadata.enabled=true

 

Warning

The metadata endpoint is disabled by default because exposing authorization server information to public clients can reveal sensitive security information. Enable this feature only when client discovery requirements outweigh the potential security implications.

For more information, see the Protected Resource Metadata section of the "Quarkus OpenId Connect (OIDC) Expanded Configuration Reference" guide.

In the current release, the Quarkus OIDC extension (quarkus-oidc) supports customizing request and response bodies in OIDC filters. With this feature, you can modify OIDC authentication and token exchange data.

To customize OIDC requests or responses:

  1. Create a class implementing OidcRequestFilter or OidcResponseFilter.
  2. Use the @OidcEndpoint annotation to target specific endpoints, such as Type.TOKEN, Type.USERINFO, or Type.INTROSPECTION.
  3. Implement the filter() method to customize the data.

Example: 

@OidcEndpoint(value = Type.TOKEN)
public class TokenRequestFilter implements OidcRequestFilter {
    @Override
    public void filter(OidcRequestContext rc) {
        rc.requestBody(Buffer.buffer(rc.requestBody().toString() +
            "&custom_param=custom_value"));
    }
}

 

OIDC filters enable adding custom parameters, modifying headers, transforming response formats, and implementing validation logic.

For more information, see the following resources:

In the current release, you can use the Quarkus VertX HTTP (quarkus-vertx-http) extension to configure path-specific authorization programmatically using a fluent API. This API uses the io.quarkus.vertx.http.security.HttpSecurity CDI event and provides a more flexible alternative to configuration properties.

This functionality is available as a Technology Preview scope of support feature.

Previously, developers had to use configuration properties to set up path-specific authorizations, which could become verbose and difficult to manage for complex applications. The new fluent API allows you to define authorization rules directly in Java code, making security configurations more maintainable and dynamic. This approach is particularly beneficial for applications with complex authorization requirements or those that need to configure permissions based on runtime conditions.

Example: Configuring path-specific authorization with the fluent API

package org.acme.http.security;

import io.quarkus.vertx.http.security.HttpSecurity;
import jakarta.enterprise.event.Observes;

public class HttpSecurityConfiguration {

    void configure(@Observes HttpSecurity httpSecurity) {
        httpSecurity
                .get("/public/*").permit()
                .path("/roles-secured/*", "/other/*", "/api/*").roles("admin", "user")
                .path("/forbidden").authorization().deny();
    }
}

 

In this example:

  • .get("/public/*").permit() permits all GET requests to paths matching /public/\* without authentication.
  • .path("/roles-secured/*", "/other/*", "/api/*").roles("admin", "user") restricts access to the specified paths to users with either the admin or user role.
  • .path("/forbidden").authorization().deny() denies all access to the /forbidden path.

Additionally, the fluent API can configure specific authentication mechanisms and custom security policies for different paths. You can combine authentication methods like Basic, Bearer token, or Authorization Code Flow with custom authorization policies, including role-based access control and permission checks.

For more information, see the Set up path-specific authorization programmatically section of the "Authorization of web endpoints" guide.

1.3.6. Tooling
Copy link

1.3.6.1. Dev UI: Basic workspace feature
Copy link

In the current release, the Dev UI introduces a basic workspace feature.

In dev mode, you can browse and edit project source files directly in the Dev UI.

For more information, see the following resources:

1.3.6.2. Dev Services: Compose support
Copy link

In the current release, Dev Services adds Compose support.

This capability allows developers to define and orchestrate custom containers for Dev Services by using Compose descriptions with Docker or Podman, and the Dev Services framework automatically manages the startup, configuration, and lifecycle of the services.

For more information, see the following resources:

In the current release, Quarkus improves the test class loading infrastructure. These enhancements make test execution more reliable and consistent across different environments.

For more information, see the GitHub Pull Request #34681.

1.3.7. Web
Copy link

1.3.7.1. SmallRye GraphQL: Virtual thread support
Copy link

In the current release, SmallRye GraphQL supports running operations on Java virtual threads. Annotate blocking operations with @RunOnVirtualThread to run them on virtual threads without tying up platform threads. Use @RunOnVirtualThread for blocking operations and do not combine it with @Blocking or @NonBlocking. Virtual threads can increase concurrency compared to worker threads while keeping code simple; the reactive model remains the most resource-efficient for very high concurrency.

For more information, see the following resources:

1.4. Support and compatibility
Copy link

You can find detailed information about the supported configurations and artifacts that are compatible with Red Hat build of Quarkus 3.27 and the high-level support lifecycle policy on the Red Hat Customer Support portal as follows:

In Red Hat build of Quarkus, a feature release can be either a major release or a minor release:

  • A major release introduces new features and a support life cycle (full and maintenance) for a minimum of 3 years.
  • A minor release introduces new features or changes that do not affect compatibility with earlier releases (breaking changes). The latest minor version is fully supported, and the previous version is considered in maintenance for six months, starting when a new minor version is released.

Red Hat build of Quarkus release version numbers are directly aligned with the Long-Term Support (LTS) versions of the Quarkus community project. For more information, see the Long-Term Support (LTS) for Quarkus blog post.

The version numbering of a Red Hat build of Quarkus feature release matches the Quarkus community version on which it is based.

Important

Red Hat does not release a productized version of Quarkus for every version the community releases. The cadence of the Red Hat build of Quarkus feature releases is about every six months.

Red Hat build of Quarkus provides full support for a feature release right up until the release of a subsequent version. When a feature release is superseded by a new version, Red Hat continues to provide a further six months of maintenance support for the release, as outlined in the following support lifecycle chart [Fig. 1].

Figure 1.1. Feature release cadence and support lifecycle of Red Hat build of Quarkus

Diagram that demonstrates the feature release cadence and support lifecycle of Red Hat build of Quarkus

During the full support phase and maintenance support phase of a release, Red Hat also provides 'service-pack (SP)' updates and 'micro' releases to fix bugs and Common Vulnerabilities and Exposures (CVE).

New features in subsequent feature releases of Red Hat build of Quarkus can introduce enhancements, innovations, and changes to dependencies in the underlying technologies or platforms. For a detailed summary of what is new or changed in a successive feature release, see New features, enhancements, and technical changes.

While most of the features of Red Hat build of Quarkus continue to work as expected after you upgrade to the latest release, there might be some specific scenarios where you need to change your existing applications or do some extra configuration to your environment or dependencies. Therefore, before upgrading Red Hat build of Quarkus to the latest release, always review the Changes that affect compatibility with earlier versions and Deprecated components and features sections of the release notes.

For detailed information about the product lifecycle, timelines, and support policies, see the Red Hat build of Quarkus Life Cycle and Support Policies.

1.4.2. Supported environments
Copy link

Red Hat build of Quarkus 3.27 is supported on Red Hat OpenShift Container Platform 4.19 and 4.12, and on Red Hat Enterprise Linux 8.10.

For a list of supported configurations, log in to the Red Hat Customer Portal and see the Knowledgebase solution Red Hat build of Quarkus Supported configurations.

1.4.3. Development support
Copy link

Red Hat provides development support for the following Red Hat build of Quarkus features, plugins, extensions, and dependencies.

Features

  • Continuous Testing
  • Dev Services
  • Dev UI
  • Local development mode
  • Remote development mode

For more information about development support, see Development Support Scope of Coverage.

1.4.3.1. Development tools
Copy link

Red Hat provides a development support for Quarkus development tools, including the Quarkus CLI and the Maven and Gradle plugins, to prototype, develop, test, and deploy Red Hat build of Quarkus applications.

Red Hat does not support using Quarkus development tools in production environments.

For more information about development support, see Development Support Scope of Coverage.

1.5. Deprecated components and features
Copy link

The components and features listed in this section are deprecated, or contain components and features that are deprecated, with Red Hat build of Quarkus 3.27. They are included and supported in this release. However, no enhancements will be made to these components and features, and they might be removed in the future.

For a list of the components and features that are deprecated in this release, visit the Red Hat build of Quarkus Component details page.

1.6. Technology Preview features
Copy link

This section lists features and extensions that are now available as a Technology Preview in Red Hat build of Quarkus 3.27.

Important

Technology Preview features are not supported with Red Hat production service level agreements (SLAs), might not be functionally complete, and Red Hat recommends that you do not use them in production. These features provide early access to upcoming product features, enabling customers to test functionality and provide feedback during the development process.

For more information, see Technology Preview scope of support.

1.6.1. New Technology Preview features
Copy link

Red Hat build of Quarkus 3.27 introduces the following Technology Preview features:

1.6.2. Continuing Technology Preview features
Copy link

Red Hat build of Quarkus 3.27 continues to provide the following Technology Preview features that were introduced in earlier versions.

Red Hat build of Quarkus 3.20:

Red Hat build of Quarkus 3.15:

This section describes changes in Red Hat build of Quarkus 3.27 that affect the compatibility of applications built with earlier product versions.

Review these breaking changes and take the necessary steps to ensure that your applications continue functioning after updating them to Red Hat build of Quarkus 3.27.

To update your application projects to Red Hat build of Quarkus 3.27, see the Migrating applications to Red Hat build of Quarkus 3.27 guide.

1.7.1. Compatibility
Copy link

In the current release, the QuarkusTransaction.isActive() method is deprecated.

The method’s behavior is ambiguous and does not reliably indicate transaction state.

Use the getStatus() method to determine the current transaction status. Update all existing uses of isActive() to getStatus() to ensure correct behavior.

To apply this change to existing code, manually perform any additional steps described in this release note. The automatic update process in the Migrating applications to Red Hat build of Quarkus 3.27 guide do not cover this change.

For more information, see the Quarkus Migration guide 3.22.

1.7.2. Core
Copy link

In the current release, Quarkus removes support for legacy configuration classes. Applications that rely on extensions, including custom extensions, built on legacy configuration classes, fail to build.

Update affected extensions to versions that use @io.smallrye.config.ConfigMapping, or migrate custom extensions accordingly.

For example, replace the compatibility class GlobalDevServicesConfig with DevServicesConfig.

To apply this change to existing code, manually perform any additional steps described in this release note. The automatic update process in the Migrating applications to Red Hat build of Quarkus 3.27 guide do not cover this change.

For more information, see the following resources:

In the current release, feature toggles in configuration use the .enabled suffix instead of .enable. This change enhances consistency across configuration properties and prevents the mixing of suffixes. The old .enable properties remain recognized for backward compatibility but are deprecated.

Run quarkus update to automatically migrate your configuration. If you update manually, rename keys such as quarkus.log.console.enable to quarkus.log.console.enabled to avoid deprecation warnings. Named logging handlers follow the same rule and use quarkus.log.handler.*."handler-name".enabled.

Example 1.1. Impacted properties include:

  • quarkus.keycloak.policy-enforcer.enable quarkus.keycloak.policy-enforcer.enabled
  • quarkus.log.console.enable quarkus.log.console.enabled
  • quarkus.log.console.async.enable quarkus.log.console.async.enabled
  • quarkus.log.file.enable quarkus.log.file.enabled
  • quarkus.log.file.async.enable quarkus.log.file.async.enabled
  • quarkus.log.syslog.enable quarkus.log.syslog.enabled
  • quarkus.log.syslog.async.enable quarkus.log.syslog.async.enabled
  • quarkus.log.socket.enable quarkus.log.socket.enabled
  • quarkus.log.socket.async.enable quarkus.log.socket.async.enabled
  • quarkus.snapstart.enable quarkus.snapstart.enabled
  • quarkus.smallrye-health.ui.enable quarkus.smallrye-health.ui.enabled
  • quarkus.smallrye-graphql.ui.enable quarkus.smallrye-graphql.ui.enabled
  • quarkus.smallrye-openapi.enable quarkus.smallrye-openapi.enabled
  • quarkus.swagger-ui.enable quarkus.swagger-ui.enabled

To apply this change, run the automatic update process described in the Migrating applications to Red Hat build of Quarkus 3.27 guide.

1.7.2.3. JGit: Dependency removed from quarkus-bom
Copy link

In the current release, the org.eclipse.jgit dependency is no longer managed in the quarkus-bom.

Now, if your application relies on JGit, add the quarkus-jgit extension to your dependencies to ensure native image compatibility and to use a compatible library version.

The quarkus-jgit extension is not supported in Red Hat build of Quarkus.

To apply this change to existing code, manually perform any additional steps described in this release note. The automatic update process in the Migrating applications to Red Hat build of Quarkus 3.27 guide do not cover this change.

For more information, see the Quarkus Migration guide 3.22.

In the current release, a JsonRPCProvidersBuildItem must be produced regardless of the build mode.

Previously, most extensions produced this build item only in dev mode by using @BuildStep(onlyIf = IsDevelopment.class).

Now, the build process requires this item at build time to enable execution model validation on JSON-RPC classes.

The build process uses this item to identify JSON-RPC endpoints, particularly classes that use annotations such as @Blocking, @NonBlocking, or @RunOnVirtualThread.

  • To migrate, replace conditional build steps as follows:

    • Previously used code: 

      @BuildStep(onlyIf = IsDevelopment.class)
JsonRPCProvidersBuildItem createJsonRPCService() {
    return new JsonRPCProvidersBuildItem(...);
}

       

    • Updated code: 

      @BuildStep
JsonRPCProvidersBuildItem createJsonRPCService() {
    return new JsonRPCProvidersBuildItem(...);
}

       

Quarkus previously provided a fallback detection mechanism for JSON-RPC classes. That mechanism is removed in the current release.

To apply this change to existing code, manually perform any additional steps described in this release note. The automatic update process in the Migrating applications to Red Hat build of Quarkus 3.27 guide do not cover this change.

For more information, see the Quarkus Migration guide 3.22: extensions must produce JsonRPCProvidersBuildItem always.

1.7.2.5. Stork: No longer managed by REST Client
Copy link

In the current release, Stork is no longer a built-in dependency of the REST Client.

Now, you must add the quarkus-stork extension to your project dependencies to use Stork with REST Client.

To apply this change to existing code, manually perform any additional steps described in this release note. The automatic update process in the Migrating applications to Red Hat build of Quarkus 3.27 guide do not cover this change.

For more information, see the Quarkus Migration guide 3.22.

Breaking change: The current release removes the long-deprecated quarkus.test.native-image-profile configuration property. Update any configurations that still use the removed property to use the current quarkus.test.integration-test-profile property instead.

The quarkus.test.integration-test-profile property specifies the configuration profile to use when running tests with @QuarkusIntegrationTest:

  • Type: String
  • Default value: prod
  • Environment variable: QUARKUS_TEST_INTEGRATION_TEST_PROFILE
  • Configuration timing: Fixed at build time

To apply this change to existing code, manually perform any additional steps described in this release note. The automatic update process in the Migrating applications to Red Hat build of Quarkus 3.27 guide do not cover this change.

1.7.3. Data
Copy link

1.7.3.1. Apache Derby database support removed
Copy link

In the current release, support for the Apache Derby database has been removed from Red Hat build of Quarkus.

Apache Derby was deprecated in a previous release and has now been fully removed. Applications using Derby should migrate to a supported database such as PostgreSQL, MySQL, MariaDB, or another database listed in the supported configurations.

If your application currently uses Derby, you will need to:

  • Update your application dependencies to remove Derby JDBC drivers
  • Update your application.properties or application.yaml to configure a different database
  • Migrate your existing Derby database schema and data to the new database

For information about configuring datasources in Red Hat build of Quarkus, see Configuring data sources.

To apply this change to existing code, manually perform any additional steps described in this release note. The automatic update process in the Migrating applications to Red Hat build of Quarkus 3.27 guide do not cover this change.

1.7.3.2. Dev Services default images updates
Copy link

In the current release, the default images for the following Dev Services have been updated to the following versions:

  • Elasticsearch version 9.1
  • OpenSearch version 3.1

Breaking change: If your applications require specific versions of these images, you must configure the container image explicitly. For example: 

quarkus.elasticsearch.devservices.image-name=docker.io/elastic/elasticsearch:9.1.3

 

To apply this change to existing code, manually perform any additional steps described in this release note. The automatic update process in the Migrating applications to Red Hat build of Quarkus 3.27 guide do not cover this change.

For more information, see the Configuring the image section of the Quarkus "Dev Services for Elasticsearch" guide.

1.7.3.3. Hibernate ORM: Database version checks
Copy link

In the current release, Hibernate ORM improves database version checks.

Earlier releases already applied these checks; this update enhances version detection accuracy and expands the scope of checks run at startup.

If application startup fails the version check, set the correct database version for your dialect or upgrade the database to a supported version.

When you use CockroachDialect, set the CockroachDB version (not a PostgreSQL version) to match the server your application connects to.

To apply this change to existing code, manually perform any additional steps described in this release note. The automatic update process in the Migrating applications to Red Hat build of Quarkus 3.27 guide do not cover this change.

For more information, see the Quarkus Migration guide 3.25.

In the current release, the following Hibernate ORM (quarkus-hibernate-orm) extension properties are renamed to simplify YAML configuration and prepare for future changes.

The old properties remain recognized in the current release, but are deprecated and are planned to be removed in a future release.

Use the new properties when you upgrade to the current release.

Expand
Old property nameNew property name

quarkus.hibernate-orm.database.generation

quarkus.hibernate-orm.schema-management.strategy

quarkus.hibernate-orm.database.generation.create-schemas

quarkus.hibernate-orm.schema-management.create-schemas

quarkus.hibernate-orm.database.generation.halt-on-error

quarkus.hibernate-orm.schema-management.halt-on-error

To apply this change, run the automatic update process described in the Migrating applications to Red Hat build of Quarkus 3.27 guide.

1.7.3.5. Hibernate ORM: Upgraded to version 7.1
Copy link

In the current release, Hibernate ORM has been upgraded to version 7.1. This upgrade introduces breaking changes that might affect your applications.

  • API changes

    • Deprecated Session methods have been removed or replaced by JPA equivalents.

      To apply changes marked as "Automatic", run the automatic update process described in the Migrating applications to Red Hat build of Quarkus 3.27 guide, otherwise manually perform any additional steps.

      Expand
      Deprecated Session methodNew JPA equivalentUpdate process

      load(…​) without a lock option

      getReference(…​)

      Automatic

      get(…​)

      find(…​)

      Automatic

      delete(…​)

      remove(…​)

      Automatic

      save(…​)

      persist(…​)

      Automatic

      update(…​)

      merge(…​)

      Manual

      load(…​) with a lock option

      find(…​)

      Manual

      saveOrUpdate(…​)

      persist (new entity) / merge (persisted, then detached entity)

      Manual

      Note

      When migrating from an update method to a merge method, be aware of the following differences:

      • merge returns an entity instance attached to the persistence context. Ensure that you use that entity and discard the one passed as an argument.
      • To ensure proper merging, merge can load the entity. When using merge on multiple entities in succession, N+1 select issues might occur. To avoid this issue, load all entities in the session before the merge call, for example, by using Session#findMultiple.

      To apply this change, manually perform any additional steps described in this release note.

      For more information, see Hibernate ORM Defer to JPA.

    • Deprecated annotations have been removed or replaced by JPA equivalents. To view the impacted annotations, see Hibernate ORM Annotations.

    • @Cascade and CascadeType are deprecated and replaced by JPA equivalents such as @OneToMany(cascade = …​).

      To apply this change, run the automatic update process described in the Migrating applications to Red Hat build of Quarkus 3.27 guide.

    • Proxy customization has changed. If you were using @Proxy, consider @ConcreteProxy instead, or use the Session#getReference or Hibernate#unproxy methods. For more information, see Hibernate ORM Replace @Proxy.
    • org.hibernate.Metamodel was removed and replaced by org.hibernate.metamodel.model.domain.JpaMetamodel.
    • The UserType and CompositeType method signatures changed to no longer refer to internal or Service Provider Interface (SPI) types. For more information, see Hibernate ORM UserType and CompositeUserType changes.
    • Various JDBC types were moved to an internal package. To map your attributes to these types, use @JdbcTypeCode instead of @JdbcType.
    • The LockOptions class was deprecated; impacted methods have alternatives involving LockMode. Some deprecated features of the LockOptions class have also been removed. For more information, see Hibernate ORM LockOptions.
    • The Session#getLobHelper method is deprecated. Use Hibernate#getLobHelper instead. For more information, see Hibernate ORM Session#getLobHelper.

  • Behavior changes

    • Stricter annotation validation

      Misplaced mapping annotations now raise exceptions instead of being ignored. Examples include conflicting @Basic and @ManyToOne annotations on the same attribute, or the use of attribute converters on @Id and @Version. For more information, see Hibernate ORM Domain model validations.

    • Second-level cache usage

      StatelessSession now uses the second-level cache by default. This change impacts migrating applications that use second-level cache and StatelessSession. For more information, see Hibernate ORM StatelessSession and second-Level cache.

    • Batch operation changes

      StatelessSession does not respect the quarkus.hibernate-orm.jdbc.statement-batch-size setting. Because StatelessSession operations are designed to execute immediately, implicit batch operations are not required. Instead, you can use explicit batch operations such as 'insertMultiple()'. For more information, see Hibernate ORM StatelessSession and JDBC batching.

    • Query validation

      Ambiguous query strings are no longer accepted. This mainly affects type-unsafe queries, when not passing a class to Session#createQuery, or when using Panache to create a query. Queries without a select clause, but with a non-fetch join, must now specify the intended behavior. For more information, see Hibernate ORM Query with implicit SELECT and no explicit result type.

    • Changes to types returned for date and time values by native queries

      Previously, java.sql types were used to represent date and time types returned by a native query. Now, native queries return java.time types in the absence of specific type instructions. For more information, see Hibernate ORM Temporal types returned by native queries.

  • Minimum database versions

    The minimum required database versions have been updated to use the oldest version still supported by the respective vendor.

    In particular, note the following updates:

    • IBM DB2: minimum version updated from 10.5 to 11.1
    • MariaDB: minimum version updated from 10.4 to 10.6
    • Microsoft SQL Server: minimum version updated from 11.0 (2012) to 12.0 (2014)

    • PostgreSQL: minimum version updated from 12.0 to 13.0

      For more information about current minimum versions, see Hibernate ORM Supported dialects.

  • MySQL/MariaDB storage engine

    Using quarkus.hibernate-orm.dialect.storage-engine to set the MySQL/MariaDB storage engine has been deprecated. Use quarkus.hibernate-orm.dialect.mariadb.storage-engine=…​ or quarkus.hibernate-orm.dialect.mysql.storage-engine=…​ instead.

  • DDL/schema changes

    • The custom database initialization script, in particular on H2 databases, might need to change to avoid the use of quotes.
    • Basic arrays are now mapped to proper array structures in a database instead of being serialized as binary data. You can revert this behavior by setting quarkus.hibernate-orm.unsupported-properties."hibernate.type.preferred_array_jdbc_type" to VARBINARY. Otherwise, if your entity mapping includes arrays, updates to the database schema and a manual update of data are needed. For more information, see Hibernate ORM Array mapping changes.
    • char/Character attributes are now mapped to varchar(1) instead of char(1).
    • On Oracle and Microsoft SQL Server, timestamp attributes have a different default sub-second precision.
    • On Oracle, float and double attributes are mapped to binary_float and binary_double instead of float(p), real, or double precision types. For more information, see Hibernate ORM Changes affecting DDL.

  • Annotation processor changes

    • The Maven artifact for the Hibernate ORM annotation processor has changed from org.hibernate.orm:hibernate-jpamodelgen to org.hibernate.orm:hibernate-processor. In Maven, update the annotationProcessorPath.

    • The annotation processor org.hibernate.jpamodelgen.JPAMetaModelEntityProcessor is deprecated in favor of org.hibernate.processor.HibernateProcessor.

      To apply this change, run the automatic update process described in the Migrating applications to Red Hat build of Quarkus 3.27 guide.

  • Contexts and dependency injection (CDI) restrictions for Hibernate ORM components

    • Some pluggable components, that are potentially retrieved before CDI is initialized, can no longer be CDI beans.

      If you need to provide a custom implementation of such components, and need access to CDI within that implementation, consider retrieving other beans by using Arc.container().instance(OtherBean.class).get(). For a list of impacted components, see the Migration guide 3.24.

  • JSON/XML mapping

    Previously, Hibernate ORM’s "format mappers" for JSON/XML serialization in the database relied on global REST layer serialization settings by default.

    Now, it is preferred to separate database layer and REST layer serialization to help ensure database format stability and prevent unnecessary migrations. However, because of this, the current release fails by default if the following conditions are met:

    • Your application has a Hibernate mapping involving XML or JSON stored in the database.
    • The XML or JSON serialization settings for the REST layer are customized.

    Should this occur, you can update your database serialization settings:

    • Jackson-based JSON serialization

      If the ObjectMapper customization applied in your application does not affect the format of the JSON stored in the database, bypass that ObjectMapper by specifying quarkus.hibernate-orm.mapping.format.global=ignore.

      Otherwise, implement a custom FormatMapper bean. First, delegate a format mapper to the global REST layer serialization.

      For more information, see the Migration guide 3.26 and the Customizing JSON/XML serialization/deserialization section of the Quarkus "Using Hibernate ORM and Jakarta Persistence" guide.

      Then, take either of the following actions:

      • Continue to use this delegating format mapper if you want to rely on the globally configured ObjectMapper and depend on the REST layer serialization needs.
      • Prepare and test migration scripts to update your JSON data. You can use either Hibernate ORM’s default format or adapt the FormatMapper implementation to format JSON according to your needs.

    • JSON-B-based JSON serialization

      This scenario is identical to that of the Jackson-based mapper. For more information, see the Migration guide 3.26.

    • JAXB-based XML serialization

      The XML serialization format change in Hibernate ORM 7.0 also has an impact. While the Quarkus built-in JAXB-based XML format mapper uses the legacy format, removing or bypassing it with quarkus.hibernate-orm.mapping.format.global=ignore makes the format incompatible.

      To mitigate, create a mapper that delegates to Hibernate ORM’s mapper. For more information, see the Migration guide 3.26.

      Then, take either of the following actions:

      • Continue to use this delegating format mapper if you want to rely on the legacy format.
      • Prepare and test migration scripts to update your XML data. You can use either Hibernate ORM’s default format or adapt the FormatMapper implementation to format XML according to your needs.

To apply this change to existing code, manually perform any additional steps described in this release note. The automatic update process in the Migrating applications to Red Hat build of Quarkus 3.27 guide do not cover this change.

For more information, see the following resources:

In the current release, Hibernate Reactive validates database versions during startup.

This change ensures compatibility with supported databases and prevents applications from running against unsupported or incompatible versions.

If your application connects to a database version that does not meet Hibernate Reactive’s requirements, startup fails with a clear error message.

To resolve this issue, upgrade the database to a supported version or adjust your setup accordingly.

For more information, see the Quarkus Migration guide 3.25.

In the current release, Hibernate Reactive has been upgraded to version 3.1.

Hibernate Reactive 3.1 remains compatible with 3.0 for most applications, but it inherits breaking changes from Hibernate ORM.

For more information about the Hibernate ORM breaking changes, see the Hibernate ORM: Upgraded to version 7.1 release note.

The following Hibernate Reactive breaking changes are also introduced:

  • API changes

    The ReactiveIdentifierGenerator API is updated and now extends org.hibernate.generator.Generator, which requires additional methods.

    This change affects users who define a custom identifier generator by using the @GenericGenerator annotation and implement their own generator classes.

    To implement the new API, update custom identifier generators that are defined with @GenericGenerator.

    In the Generator interface, update the following methods:

    • generatedOnExecution(): Return true if the identifier is generated during query execution, or false if it is generated in your application code.
    • getEventTypes(): Specify if the identifier changes during an insert or update operation.

  • Minimum database versions

    The quarkus-hibernate-reactive extension aligns its minimum supported database versions with Hibernate ORM 7.1 dialect requirements. For more information about current minimum versions, see Hibernate ORM Supported dialects.

To apply this change to existing code, manually perform any additional steps described in this release note. The automatic update process in the Migrating applications to Red Hat build of Quarkus 3.27 guide do not cover this change.

1.7.3.8. Hibernate Search: Upgraded to version 8.1
Copy link

In the current release, Hibernate Search has been upgraded to version 8.1.

With the upgrade to the 8.x version series, some breaking changes are introduced that might impact your applications.

  • Deprecated classes are removed in favor of their recommended alternatives. Notably, org.hibernate.search.mapper.orm.massindexing.MassIndexingMonitor has been replaced by org.hibernate.search.mapper.pojo.massindexing.MassIndexingMonitor.
  • The MassIndexingMonitor#addToTotalCount method is deprecated and replaced by MassIndexingMonitor#typeGroupMonitor(..)
  • multi() methods in the projection DSL are deprecated and replaced by .list()/.set()/sortedSet()/collector(…​).
  • Logging categories have been updated. In particular, the org.hibernate.search.elasticsearch.request logging category, used for logging every request sent to Elasticsearch, has been renamed to org.hibernate.search.elasticsearch.client.request. For more information, see List of all available logging categories.
  • Search DSL interfaces are enhanced to include an extra SR type argument reference guide .
  • The format of mass indexing logs has changed to present more information in a condensed format.
  • Metric aggregation countDistinct() is deprecated and replaced by an option in count() aggregation: .count().field(..).distinct().

For more information, see the following resources:

1.7.4. Messaging
Copy link

In the current release, the Apache Kafka client artifact, kafka-clients, which is used in the quarkus-kafka-client extension, has been upgraded to version 4.0.0.

This version introduces the following changes:

  • Removal of ZooKeeper dependency
  • Support for some older protocols or API versions is removed
  • Incompatibility with older clients or brokers that rely on deprecated features
  • A minimum requirement for Java version 11 for your Quarkus application
  • Improvements to client metrics

You can still connect to Apache Kafka 3.x brokers. Older brokers that rely on removed protocol versions might be incompatible.

For more information, see the following resources:

1.7.5. Observability
Copy link

1.7.5.1. OpenTelemetry: Changes to metrics
Copy link

In the current release, the OpenTelemetry metrics provided by the quarkus-opentelemetry extension have changed.

Note

By default, OpenTelemetry metrics are disabled. When enabled, by setting quarkus.otel.metrics.enabled=true, metrics related to the JVM and the HTTP server are collected.

The following table lists the OpenTelemetry metrics that are now available. Note that jvm.system.cpu.utilization metric is removed in JVM mode; use jvm.cpu.recent_utilization instead.

Expand
Metric nameDescriptionTypeAvailable on JVMAvailable on NativeMP Telemetry 2.0

http.server.request.duration

Duration of HTTP server requests

HISTOGRAM

Y

Y

Y

jvm.memory.committed

Measure of memory committed

LONG_SUM

Y

No data produced

Y

jvm.memory.used

Measure of memory used

LONG_SUM

Y

No data produced

Y

jvm.memory.limit

Measure of max obtainable memory

LONG_SUM

Y

Not present

Y

jvm.memory.used_after_last_gc

Measure of memory used, as measured after the most recent garbage collection event on this pool

LONG_SUM

Y

No data produced

Y

jvm.gc.duration

Duration of JVM garbage collection actions

HISTOGRAM

Y

Not present

Y

jvm.class.count

Number of classes currently loaded

LONG_SUM

Y

No data produced

Y

jvm.class.loaded

Number of classes loaded since JVM start

LONG_SUM

Y

No data produced

Y

jvm.class.unloaded

Number of classes unloaded since JVM start

LONG_SUM

Y

No data produced

Y

jvm.cpu.count

Number of processors available to the JVM

LONG_SUM

Y

Y

N

jvm.cpu.limit

 

LONG_SUM

Y

No data produced

N

jvm.cpu.time

CPU time used by the process as reported by the JVM

DOUBLE_SUM

Y

Not present

N

jvm.system.cpu.utilization

CPU time used by the process as reported by the JVM

DOUBLE_SUM

Not present

No data produced

N

jvm.cpu.recent_utilization

Recent CPU utilization for the process as reported by the JVM

DOUBLE_GAUGE

Y

No data produced

N

jvm.cpu.longlock

Long lock times

HISTOGRAM

Y

Y

N

jvm.cpu.context_switch

 

DOUBLE_SUM

Y

No data produced

N

jvm.network.io

Network read/write bytes

HISTOGRAM

Y

Not present

N

jvm.network.time

Network read/write duration

HISTOGRAM

Y

Not present

N

jvm.thread.count

Number of executing platform threads

LONG_SUM

Y

Y

Y

To apply this change to existing code, manually perform any additional steps described in this release note. The automatic update process in the Migrating applications to Red Hat build of Quarkus 3.27 guide do not cover this change.

For more information, see the following resources:

1.7.6. Security
Copy link

In the current release, the deprecated blocking HttpAuthenticationMechanism.getCredentialTransport() method is removed.

If your application or a custom security extension overrides this method, you must update the implementation to avoid compilation errors.

Replace the removed method by implementing the reactive version, as in the following example: 

Uni<HttpCredentialTransport> getCredentialTransport(RoutingContext context) {
    return Uni.createFrom().item(myHttpCredentialTransport);
}

 

To apply this change to existing code, manually perform any additional steps described in this release note. The automatic update process in the Migrating applications to Red Hat build of Quarkus 3.27 guide do not cover this change.

1.7.6.2. TLS Registry extension restructuration
Copy link

In the current release, the TLS Registry extension (quarkus-tls-registry) has been restructured to avoid having a split package between the runtime and spi modules.

As part of this reorganization, the io.quarkus.tls.TlsRegistryBuildItem class has been renamed to io.quarkus.tls.deployment.spi.TlsRegistryBuildItem. It is still located in the spi module.

If you have existing code that references the earlier TlsRegistryBuildItem class location, update your imports to use the current package: 

// Earlier import
import io.quarkus.tls.TlsRegistryBuildItem;

// Current import
import io.quarkus.tls.deployment.spi.TlsRegistryBuildItem;

 

This change aligns with the architectural improvements proposed in the Quarkus project to maintain clearer separation between deployment and runtime components.

To apply this change to existing code, manually perform any additional steps described in this release note. The automatic update process in the Migrating applications to Red Hat build of Quarkus 3.27 guide do not cover this change.

1.7.7. Tooling
Copy link

Breaking change: Support for building extensions with legacy config classes and the -AlegacyConfigRoot=true annotation processor option has been removed.

Extensions must now use config interfaces annotated with @ConfigMapping and @ConfigRoot.

To apply this change to existing code, manually perform any additional steps described in this release note. The automatic update process in the Migrating applications to Red Hat build of Quarkus 3.27 guide do not cover this change.

For more information, see the following resources:

In the current release, the Gradle tasks testNative and quarkusIntTest no longer depend on the test task.

Now, they execute only the native tests and the integration tests respectively, allowing independent test execution stages.

Update your build scripts if you previously relied on the default task dependency that included unit tests when running native or integration tests.

To apply this change to existing code, manually perform any additional steps described in this release note. The automatic update process in the Migrating applications to Red Hat build of Quarkus 3.27 guide do not cover this change.

For more information, see the Quarkus Migration guide 3.22.

1.7.8. Web
Copy link

In the current release, defining a ContextResolver in REST Client with a lambda throws an IllegalArgumentException.

This occurs because the REST Client extension cannot infer the generic type, unlike previous versions that defaulted to Object.

Replace lambdas with concrete ContextResolver implementations to avoid runtime errors and ensure correct REST Client configuration.

To apply this change to existing code, manually perform any additional steps described in this release note. The automatic update process in the Migrating applications to Red Hat build of Quarkus 3.27 guide do not cover this change.

For more information, see the Quarkus Migration guide 3.22.

In the current release, Jakarta REST resource classes that use Panache work only with Quarkus REST modules.

REST Data Panache modules no longer work with RESTEasy Classic modules.

The following modules are affected:

  • quarkus-hibernate-orm-rest-data-panache
  • quarkus-hibernate-reactive-rest-data-panache
  • quarkus-mongodb-rest-data-panache
  • spring-data-rest

Use Quarkus REST, quarkus-rest-*, instead of RESTEasy Classic, quarkus-resteasy-*, to avoid runtime failures.

To apply this change to existing code, manually perform any additional steps described in this release note. The automatic update process in the Migrating applications to Red Hat build of Quarkus 3.27 guide do not cover this change.

For more information, see the Quarkus Migration guide 3.22.

In the current release, Quarkus REST applies @JsonView consistently to both serialization and deserialization.

@JsonView on resource methods or DTOs now controls which properties are read from input and written to output according to the specified view classes (for example, Views.Public and Views.Private).

Previously, only serialization honored @JsonView, so deserialization might have accepted properties outside the active view. Applications that relied on that behavior might require code or configuration changes to align with the new behavior.

To apply this change to existing code, manually perform any additional steps described in this release note. The automatic update process in the Migrating applications to Red Hat build of Quarkus 3.27 guide do not cover this change.

For more information, see the Quarkus Migration guide 3.21.

1.8. Known issues
Copy link

Review the following known issues for insights into Red Hat build of Quarkus 3.27 limitations and workarounds.

In the current release, the Caffeine @CacheResult annotation fails to synchronize concurrent access requests following a Uni failure.

The @CacheResult annotation guarantees that concurrent requests for the same missing key are synchronized into a single method invocation. However, in the current release, this synchronization breaks if the initial Uni fails, triggering multiple method invocations instead of waiting for a single cached result.

Example error message

...
AssertionFailedError: Cache lock should prevent excessive calls. Expected <= 2, but was 3

Workaround: No workaround is available at this time. This issue is planned to be resolved in a future release.

In the current release, testing has been conducted to evaluate how Quarkus applications behave in environments with FIPS (Federal Information Processing Standards) mode enabled.

While testing generally completes successfully, some technology integrations and native image configurations currently present limitations that prevent validation or compilation.

Testing in FIPS-enabled environments has shown successful results for several key components, including OpenID Connect (OIDC), supported databases, caching, messaging with Kafka in non-native modes, and OpenTelemetry. However, some technology integrations and native configurations cannot currently be verified in these environments.

These findings do not indicate official support by Red Hat build of Quarkus or its components for FIPS.

Scenarios that cannot be verified

The following technology integrations or configurations are currently not verifiable in FIPS-enabled environments:

  • MariaDB 11.x
  • Infinispan client extension in both JVM and native mode with Mandrel 23.0 and 23.1
  • Apache Kafka using SCRAM and OAUTHBEARER SASL mechanisms in native mode
  • JDBC MSSQL driver in native mode
  • DB2
  • Reactive MSSQL client in native mode
  • Native image compilation using Red Hat Mandrel 23.1 builder image

Notable related issues

The following public Jira tickets provide additional details on the limitations encountered:

  • QUARKUS-5984: MariaDB 11.x fails to connect in FIPS-enabled environments due to compatibility issues.
  • QUARKUS-2036: Infinispan client extension lacks support for FIPS-enabled environments.
  • QUARKUS-2984: Native builds using JDBC MSSQL and Reactive MSSQL clients fail on RHEL 8 with FIPS enabled.
  • QUARKUS-5232: SASL SCRAM mechanism is unusable in native mode within FIPS-enabled environments.
  • QUARKUS-5233: SASL OAUTHBEARER mechanism is unusable in native mode within FIPS-enabled environments.
  • MANDREL-254: Mandrel 23.1 builder image requires rework to support FIPS-enabled environments.
  • QUARKUS-4387: Quarkus Reactive MySQL client is not supported in FIPS-enabled environment.
  • QUARKUS-4612: Infinispan client extension fails on FIPS with native Mandrel 23.0 and 23.1.

Workaround: No workaround is currently available.

This release note is intended to preemptively disclose known challenges while broader compatibility testing continues.

Applications that use the quarkus-kafka-streams extension on Microsoft Windows fail at runtime due to a missing native library, librocksdbjni-win64.dll.

This functionality is available as a Technology Preview scope of support feature. The Technology Preview support status of the Kafka Streams extension is independent of this missing native library issue.

During startup on Microsoft Windows systems, the application throws the following error: 

java.lang.RuntimeException: librocksdbjni-win64.dll was not found inside JAR

 

This error prevents the initialization of the RocksDB component, which is required for Kafka Streams applications.

Workaround: If you are developing Kafka Streams applications in a Windows development environment, use the community version of Quarkus during development. Then, when you are ready to test and deploy to production, switch to the Red Hat build of Quarkus in your test and production environments.

If you need to deploy Kafka Streams applications to a Windows production environment, request a feature or product enhancement instead of reporting this issue as a bug. For Red Hat build of Quarkus, open a Red Hat support case and select Idea: Request a feature or product enhancement.

Example error

13:07:08,118 INFO  [app] ERROR: Failed to start application (with profile [prod])
13:07:08,118 INFO  [app] java.lang.RuntimeException: Failed to start quarkus
13:07:08,118 INFO  [app] 	at io.quarkus.runner.ApplicationImpl.doStart(Unknown Source)
13:07:08,118 INFO  [app] 	at io.quarkus.runtime.Application.start(Application.java:101)
13:07:08,118 INFO  [app] 	at io.quarkus.runtime.ApplicationLifecycleManager.run(ApplicationLifecycleManager.java:111)
13:07:08,118 INFO  [app] 	at io.quarkus.runtime.Quarkus.run(Quarkus.java:71)
13:07:08,118 INFO  [app] 	at io.quarkus.runtime.Quarkus.run(Quarkus.java:44)
13:07:08,118 INFO  [app] 	at io.quarkus.runtime.Quarkus.run(Quarkus.java:124)
13:07:08,118 INFO  [app] 	at io.quarkus.runner.GeneratedMain.main(Unknown Source)
13:07:08,118 INFO  [app] Caused by: java.lang.ExceptionInInitializerError
13:07:08,118 INFO  [app] 	at io.quarkus.kafka.streams.runtime.KafkaStreamsRecorder.loadRocksDb(KafkaStreamsRecorder.java:14)
13:07:08,118 INFO  [app] 	at io.quarkus.deployment.steps.KafkaStreamsProcessor$loadRocksDb1611413226.deploy_0(Unknown Source)
13:07:08,118 INFO  [app] 	at io.quarkus.deployment.steps.KafkaStreamsProcessor$loadRocksDb1611413226.deploy(Unknown Source)
13:07:08,118 INFO  [app] 	... 11 more
13:07:08,118 INFO  [app] Caused by: java.lang.RuntimeException: librocksdbjni-win64.dll was not found inside JAR.
13:07:08,118 INFO  [app] 	at org.rocksdb.NativeLibraryLoader.loadLibraryFromJarToTemp(NativeLibraryLoader.java:118)
13:07:08,118 INFO  [app] 	at org.rocksdb.NativeLibraryLoader.loadLibraryFromJar(NativeLibraryLoader.java:102)
13:07:08,118 INFO  [app] 	at org.rocksdb.NativeLibraryLoader.loadLibrary(NativeLibraryLoader.java:82)
13:07:08,118 INFO  [app] 	at org.rocksdb.RocksDB.loadLibrary(RocksDB.java:70)
13:07:08,118 INFO  [app] 	at org.rocksdb.RocksDB.<clinit>(RocksDB.java:39)
13:07:08,118 INFO  [app] 	... 14 more

 

For more information, see QUARKUS-3434.

In the current release, running an application that uses the Snappy compression library on Windows produces an error due to a missing native library.

When attempting to compress data with Snappy in Windows environments, users might encounter an error message similar to the following example.

Example error message

...
org.eclipse.microprofile.reactive.messaging.Message$5@1e8dc267 from channel 'test' was not sent to Kafka topic 'test' - nacking message: org.apache.kafka.common.KafkaException: org.xerial.snappy.SnappyError: [FAILED_TO_LOAD_NATIVE_LIBRARY] no native library is found for os.name=Windows and os.arch=x86_64
...

 

Workaround: No workaround is available at this time. This issue is planned to be resolved in a future release.

For more information, see QUARKUS-5983.

In the current release, building a native image with the Mandrel 23.1 runtime might fail intermittently due to heap snapshot verification errors.

The build process fails with an error indicating that a type was not marked as reachable: 

AnalysisType<... reachable: false>

 

These errors are inconsistent, difficult to reproduce in controlled environments, and affect various applications. However, there is a higher correlation of failures in applications that combine multiple database extensions, (for example, JDBC drivers for different vendors), particularly when proprietary database drivers are included. Simplifying the application’s database dependencies can help reduce the likelihood of these errors.

Example error 1

com.oracle.graal.pointsto.util.AnalysisError: The heap snapshot verifier discovered a type not marked as reachable:
AnalysisType<VMOption$Origin[] -> HotSpotType<[Lcom/sun/management/VMOption$Origin;, resolved>, allocated: false, inHeap: false, reachable: false>
	at com.oracle.graal.pointsto.heap.HeapSnapshotVerifier$ScanningObserver.ensureTypeScanned(HeapSnapshotVerifier.java:332)
	...

 

Example error 2

AnalysisType<MemoryType[] -> HotSpotType<[Ljava/lang/management/MemoryType;, resolved>, allocated: false, inHeap: false, reachable: false>
AnalysisType<HotSpotDiagnosticMXBean$ThreadDumpFormat[] -> HotSpotType<[Lcom/sun/management/HotSpotDiagnosticMXBean$ThreadDumpFormat;, resolved>, allocated: false, inHeap: false, reachable: false>

 

Example error 3

AnalysisType<MemoryType[] -> HotSpotType<[Ljava/lang/management/MemoryType;, resolved>, allocated: false, inHeap: false, reachable: false>

 

Workaround: Retry the native image build. Because the issue is intermittent, the build is likely to succeed on subsequent attempts. In applications that combine multiple database extensions, consider simplifying the application’s database dependencies.

This issue is planned to be resolved in a future release.

For more information, see MANDREL-332.

Red Hat build of Quarkus 3.15 introduced the quarkus-tls-registry-cli plugin, which enables TLS registry support for the Quarkus CLI.

However, development tools do not currently discover Quarkus CLI plugins that are hosted on maven.repository.ibm.com/releases. As a result, the Quarkus CLI cannot resolve the TLS registry CLI plugin by default.

When this issue occurs, the CLI returns an error similar to the following output: 

[jbang] [ERROR] Could not resolve dependencies: The following artifacts could not be resolved: io.quarkus:quarkus-tls-registry-cli:jar:3.27.3.redhat-00003 (absent): Could not find artifact io.quarkus:quarkus-tls-registry-cli:jar:3.27.3.redhat-00003 in central (https://repo1.maven.org/maven2/)

 

Workaround: To enable the Quarkus CLI to resolve the plugin, configure JBang to use the IBM Maven repository at https://maven.repository.ibm.com/releases/.

You can use one of the following methods:

  • Create a jbang.properties file with the following content: 

    run.repos=central,https://maven.repository.ibm.com/releases/

     

    To apply this configuration locally, place the file in the root directory of your project. To apply the configuration globally, place the file in the ~/.jbang directory.

  • If JBang is already installed, configure the repository globally by running the following command: 

    jbang config set run.repos central,https://maven.repository.ibm.com/releases/

     

For more information, see QUARKUS-5183.

In the current release, running the update command updates only the BOMs included in the Red Hat build of Quarkus platform, com.redhat.quarkus.platform. These can include BOMs such as quarkus-camel-bom and quarkus-cxf-bom if part of the release, quarkus-qpid-jms-bom, and quarkus-operator-sdk-bom.

However, the command does not update BOM versions tied to the upstream community release. If your project includes both Red Hat build of Quarkus and upstream BOMs, this issue can lead to potentially incompatible combinations of Quarkus and upstream BOMs.

Example update command

$ mvn com.redhat.quarkus.platform:quarkus-maven-plugin:3.27.3.redhat-00003:update -Dmaven.repo.local=<path-to-local-repo>

 

Example pom.xml file with issue

<properties>
    <quarkus.platform.artifact-id>quarkus-bom</quarkus.platform.artifact-id>
    <quarkus.platform.group-id>com.redhat.quarkus.platform</quarkus.platform.group-id>
    <quarkus.platform.version>3.27.3.redhat-00003</quarkus.platform.version>
</properties>
<dependencyManagement>
    <dependencies>
        <dependency>
            <groupId>${quarkus.platform.group-id}</groupId>
            <artifactId>${quarkus.platform.artifact-id}</artifactId>
            <version>${quarkus.platform.version}</version>
        </dependency>
        <dependency>
            <groupId>io.quarkus.platform</groupId>
            <artifactId>quarkus-amazon-services-bom</artifactId>
            <version>3.2.12.Final</version>
        </dependency>
    </dependencies>
</dependencyManagement>

 

In this example, the quarkus-amazon-services-bom version, <version>3.2.12.Final</version>, is not updated by the CLI command.

Workaround: Update the version numbers manually.

For more information, see QUARKUS-5185.

In the current release, using the quarkus/mandrel-for-jdk-21-rhel8:23.1 Red Hat Build of Quarkus Native builder image to initialize an RSA cipher in native mode within a FIPS-enabled environment produces a NullPointerException (NPE) error.

This issue occurs only in native mode with FIPS enabled; it does not affect native mode with FIPS disabled. It also does not impact JVM mode when using Red Hat build of OpenJDK with FIPS enabled.

Note

Native mode is not supported in a FIPS-enabled environment.

Example error message

2024-10-17 10:45:01,931 ERROR [io.qua.ver.htt.run.QuarkusErrorHandler] (executor-thread-1) HTTP Request to /repro failed, error id: 9b1f5dbb-058b-4c9b-9377-f3acc0a6cba5-1: java.lang.RuntimeException: java.lang.NullPointerException
    at org.acme.ReproResource.init(ReproResource.java:38)
...

 

Workaround:

  1. If present, remove the following property from the application.properties file: 

    quarkus.security.security-providers=SunPKCS11

     

  2. Add the following property to the application.properties file to initialize the ReproResource class at runtime: 

    quarkus.native.additional-build-args=--initialize-at-run-time=org.acme.ReproResource

     

For more information, see MANDREL-245.

In the current release, with the websockets-next extension, when a @WebSocket endpoint throws an exception in the @OnOpen lifecycle method, the following metrics are not incremented:

  • quarkus_websockets_server_connections_opened_errors_total{uri=${ENDPOINT}}
  • quarkus_websockets_client_connections_opened_errors_total{uri=${ENDPOINT}}

This behavior affects both server-side and client-side WebSocket connection metrics.

Workaround: No workaround is available at this time. This issue is planned to be resolved in a future release.

For more information, see QUARKUS-6640.

1.9. Red Hat build of Quarkus 3.27.3
Copy link

Red Hat build of Quarkus 3.27 provides increased stability and includes fixes to bugs that have a significant impact on users.

To get the latest fixes for Red Hat build of Quarkus, ensure you are using the latest available version, which is 3.27.3.

1.9.1. Bug fixes
Copy link

To view the list of issues resolved in this release, see Red Hat build of Quarkus 3.27.3 bug fixes.

1.9.2. Security fixes
Copy link

  • CVE-2026-33871 netty-codec-http2: Netty: Denial of Service via HTTP/2 CONTINUATION frame flood
  • CVE-2026-33870 netty-codec-http: Netty: Request smuggling via incorrect parsing of HTTP/1.1 chunked transfer encoding extension values
  • CVE-2025-67030 plexus-utils: Plexus-utils: Directory Traversal in extractFile method
  • CVE-2025-33042 avro: Apache Avro Java SDK: Code injection on Java generated code
  • CVE-2026-1002 vertx-core: Static handler component cache can be manipulated to deny the access to static files

1.9.3. Advisory
Copy link

Before you start using and deploying Red Hat build of Quarkus 3.27.3, review the following advisory related to the release.

1.10. Red Hat build of Quarkus 3.27.2
Copy link

Red Hat build of Quarkus 3.27 provides increased stability and includes fixes to bugs that have a significant impact on users.

To get the latest fixes for Red Hat build of Quarkus, ensure you are using the latest available version, which is 3.27.3.

1.10.1. Bug fixes
Copy link

To view the list of issues resolved in this release, see Red Hat build of Quarkus 3.27.2 bug fixes.

1.10.2. Security fixes
Copy link

  • CVE-2025-59432 common: Timing Attack Vulnerability in SCRAM Authentication
  • CVE-2025-14969 hibernate-reactive-core: Hibernate Reactive: Denial of Service due to connection leak on HTTP client disconnect
  • CVE-2025-67735 netty-codec-http: Netty (netty-codec-http): Request Smuggling via CRLF Injection
  • CVE-2025-66560 quarkus-rest: Quarkus REST Worker Thread Exhaustion Vulnerability

1.10.3. Advisory
Copy link

Before you start using and deploying Red Hat build of Quarkus 3.27.2, review the following advisory related to the release.

1.11. Red Hat build of Quarkus 3.27.1 SP1
Copy link

Red Hat build of Quarkus 3.27 provides increased stability and includes fixes to bugs that have a significant impact on users.

To get the latest fixes for Red Hat build of Quarkus, ensure you are using the latest available version, which is 3.27.3 SP1.

1.11.1. Bug fixes
Copy link

To view the list of issues resolved in this release, see the Red Hat build of Quarkus 3.27.1 SP1 bug fixes.

1.11.2. Security fixes
Copy link

  • CVE-2025-66566 lz4-java: lz4-java: Information disclosure via insufficient output buffer clearing
  • CVE-2025-12183 lz4-java: lz4-java: Out-of-bounds memory operations lead to denial of service and information disclosure
  • CVE-2025-11966 vertx-web: Eclipse Vert.x cross site scripting

1.11.3. Advisory
Copy link

Before you start using and deploying Red Hat build of Quarkus 3.27.1 SP1, review the following advisory related to the release.

1.12. Red Hat build of Quarkus 3.27.1
Copy link

Red Hat build of Quarkus 3.27 provides increased stability and includes fixes to bugs that have a significant impact on users.

To get the latest fixes for Red Hat build of Quarkus, ensure you are using the latest available version, which is 3.27.3.

1.12.1. Bug fixes
Copy link

To view the list of issues resolved in this release, see the Red Hat build of Quarkus 3.27.1 bug fixes.

1.12.2. Security fixes
Copy link

  • CVE-2025-64518 cyclonedx-core-java: CycloneDX Core (Java): BOM validation is vulnerable to XML External Entity injection

1.12.3. Advisory
Copy link

Before you start using and deploying Red Hat build of Quarkus 3.27.1, review the following advisory related to the release.

Before you start using and deploying Red Hat build of Quarkus 3.27.0, review the following advisory related to the release.

Red Hat logoGithubredditYoutubeTwitter

Learn

Try, buy, & sell

Communities

About Red Hat Documentation

We help Red Hat users innovate and achieve their goals with our products and services with content they can trust. Explore our recent updates.

Making open source more inclusive

Red Hat is committed to replacing problematic language in our code, documentation, and web properties. For more details, see the Red Hat Blog.

About Red Hat

We deliver hardened solutions that make it easier for enterprises to work across platforms and environments, from the core datacenter to the network edge.

Theme

© 2026 Red HatBack to top