Quarkus, counted per core.

Red Hat build of Quarkus licensing meters by core on the host where the Quarkus runtime executes. The subscription is sold inside the Red Hat Runtimes family, which also contains the Red Hat builds of OpenJDK, Spring Boot, Vert.x, and Node.js. On a Quarkus only deployment, the subscription is a per core entitlement against the systems running the Quarkus application; on a Runtimes bundle deployment, the same entitlement covers the other runtimes in the family. The community Quarkus distribution from the upstream project is identical in binary terms; the paid build adds support, certified compatibility within the Runtimes family, and a long term maintenance commitment.1

The economic interest in Quarkus comes from its low memory footprint and fast startup, which lets buyers fit more Quarkus instances per host than equivalent JBoss EAP deployments. The licensing follows the hardware, not the application, so the core count is what matters. A small Quarkus service running on a thirty two core host counts thirty two cores against the entitlement; a large EAP deployment on the same host would count the same. The buyer side reading is that the per core mechanic favours density, but only on the cores that are actually entitled.

For the broader middleware practice context, see the JBoss and middleware practice hub. For the benchmarking observations that underlie the unit price ranges here, see the benchmarking service hub.

Three counting traps recur on Quarkus deployments. Each is correctable through reshape before audit or renewal but each can also produce a meaningful gap if the operator did not run the reconciliation in advance.

The first trap is counting all cores on a hyperthreaded host as separate entitlement units. The Quarkus subscription counts physical cores, paired with the same hyperthreading rules that apply to RHEL and OpenShift on the same platform. Operators who count threads instead of cores often double the entitlement against what is actually owed. For the surrounding hyperthreading mechanics, see the broader OpenShift core counting context which uses the same paired core rule.

The second trap is licensing the entire host when only a partition runs Quarkus. On a virtualised host where the Quarkus workload runs in a small set of VMs and the remainder of the host runs unrelated workloads, the entitlement is sized to the partition rather than the whole host, on the condition that the partition is technically enforced and the partition method is contractually accepted. Where the partition is not enforced, the entire host is in scope.2

The third trap is treating community Quarkus deployments as out of scope when they share infrastructure with the paid build. A single host that runs a Red Hat build of Quarkus alongside a community Quarkus binary is fully in scope under the Red Hat subscription because the host is the licensing unit. The reshape is either to separate the community workload to a different host or to bring the community workload under the same subscription. The middle ground produces audit exposure.

Red Hat Runtimes packages Quarkus with the other Red Hat builds of open source runtimes. The bundle entitles every runtime in the family on every entitled core, which produces meaningful unit economics where the same host runs Quarkus alongside an OpenJDK based JBoss EAP application or a Vert.x service. On a host that runs only Quarkus, the bundle costs more than the standalone Quarkus subscription for capability the operator does not consume.

The break point sits around the second runtime. Estates that run Quarkus alone on most hosts and Runtimes in a bundle on the consolidated middleware tier often produce the cleanest licensing posture. For the bundled view, the same logic applies as on other Red Hat bundles where the bundle pays when the second product is consumed.3

The seller side has shown willingness to extend Runtimes discount to estates that commit to a multi runtime roadmap. The buyer side reading is to confirm the roadmap is real before signing for the bundle. A Runtimes commitment without an actual second runtime deployment produces a sunk subscription that the renewal cannot recover. For the sibling on Decision Manager which sometimes pairs with Quarkus on the rules tier, see the Decision Manager licensing note.

Quarkus is an upstream open source project. The community distribution is freely available, runs the same binaries, and produces the same operational results. The paid build provides support, a long term maintenance commitment on selected versions, and certified compatibility with the rest of the Red Hat platform. The boundary against community use is the most consequential decision on a Quarkus estate because the binaries are identical and the licensing question is therefore about support, not about the runtime.

Three boundary patterns work in operational practice. The first is paid build for production, community build for development and pre production. This is the common pattern and the seller side typically does not contest it, on the condition that the development hosts are technically separable from the production hosts. Where development and production share a single Kubernetes cluster without enforced namespace isolation, the full cluster is in scope.

The second is paid build only on hosts that need vendor support. Some estates pay for Red Hat build of Quarkus only on the workloads where vendor support is operationally critical and run community Quarkus elsewhere. This pattern works where the operator has the engineering capacity to handle community issues independently and where the production criticality varies meaningfully across workloads.

The third is paid build only on selected long term support versions. Where the Red Hat build's long term maintenance commitment is the actual value, the buyer side reading is to license only the workloads that pin to a long term version and let the rest run the community release. This pattern reduces the entitlement without losing the maintenance commitment on the workloads where it matters. For the surrounding application platform context that often pairs with Quarkus on the same host, see the Keycloak licensing note and the Apache Camel licensing note.

The renewal posture on a Quarkus estate has three components worth preparing before the seller side prices the next term. The first is the core inventory, which should resolve every entitled host to its physical core count, its partition status if virtualised, and its role in the application portfolio. The second is the community boundary, which should document which workloads run the paid build and which run community Quarkus, with the technical enforcement noted where applicable. The third is the Runtimes bundle exposure, which should compare the standalone Quarkus subscription cost against the Runtimes bundle cost on the same estate.

The seller side at renewal often positions the Runtimes bundle as the natural next step. The buyer side reading is that the bundle pays only when the second runtime is consumed. For estates with industry constraints, the boundary against community Quarkus carries different weight; financial services regulators often require vendor supported runtime on production workloads, which removes the community boundary as a reshape lever. For the audit context on regulated estates, see the financial services audit considerations note.

One cross cluster consideration is worth noting. Where Quarkus runs on RHEL hosts dedicated to SAP applications, the RHEL for SAP entitlement and the Quarkus entitlement are separate and the host carries both. The bundled view of the host's licensing footprint should include both entitlements rather than only the application runtime. For the surrounding RHEL for SAP context, see the RHEL for SAP applications licensing note.

For estates evaluating Quarkus licensing ahead of a renewal or audit, the engagement is normally a subscription assessment scoped to the Quarkus and Runtimes estate plus a community boundary review. To begin, see the contact page.

Preparing a response? The practice keeps a one-page Red Hat audit response checklist — what to acknowledge, what to preserve, and what not to volunteer in the first fourteen days after the letter arrives.