JBoss EAP, counted by core.

Red Hat JBoss Enterprise Application Platform, written JBoss EAP throughout this note, is the commercial distribution of the WildFly application server with Red Hat productisation, certification against the Jakarta EE specification, and a Red Hat support entitlement. The product runs Java enterprise applications, exposes the standard set of application server services, and has been part of the Red Hat middleware portfolio since the original acquisition of JBoss Inc. in 2006.1 The product is mature; the meter has evolved with the underlying compute model.

In commercial circulation in 2026, JBoss EAP is sold on a core based subscription, with a defined number of entitled cores per subscription unit and a support tier attached to the subscription. The core is the meter. The application server is the thing licensed. The host on which the application server runs is the operational substrate. The buyer side reading separates the meter from the host because the seller side proposal sheet sometimes does not.

For the wider JBoss middleware practice, see the JBoss and Middleware practice hub. For the broader subscription assessment work, see subscription assessment.

The core meter reads as follows. A JBoss EAP subscription unit entitles a defined number of cores on the host where the application server runs. The buyer counts the cores that JBoss EAP is using on each host and confirms the total entitled cores cover the total used cores. The meter is the entitled compute, not the host machine. A sixty four core host running JBoss EAP pinned to eight cores requires eight cores of entitlement, not sixty four, provided the pinning is enforceable and auditable.2

The enforceability of pinning is the technical detail that the buyer side reading often overlooks. Where JBoss EAP is bound to a subset of cores through cgroups, container CPU limits, virtualization core allocation, or operating system level pinning, the binding has to be demonstrable. A buyer that asserts core pinning without a demonstrable enforcement mechanism is exposed in an audit. A buyer that demonstrates the binding through container resource limits, hypervisor CPU pinning, or systemd cgroup configuration is operating defensibly. The practice has worked with clients to produce the audit ready evidence of pinning before the inquiry lands, as part of subscription assessment.

The support tier is the second dimension of the subscription. Red Hat ships JBoss EAP in standard and premium support tiers in 2026. The tier affects response time targets and the depth of support engagement on a case. The tier does not affect the meter itself. The buyer that pays for premium support on a hundred core deployment pays for premium across all hundred cores; the buyer cannot tier individual cores. The tier is a deployment wide attribute of the subscription.

Three traps recur on the JBoss EAP line in 2026 renewal proposals. The first is the host wide read on a virtualized estate, where the seller side counts every physical core on every hypervisor that runs a JBoss EAP virtual machine, rather than the entitled cores actually pinned. This reading overcounts dramatically in any estate where JBoss EAP is one of many workloads on a shared cluster. The defensible response is to demonstrate the pinning and to negotiate the meter at the pinned count.

The second trap is the container CPU limit read at the host level. A JBoss EAP container running on a Kubernetes node with a CPU limit of four cores is entitled at four cores, provided the limit is set and the cluster honors it. The proposal that reads the underlying node's total cores rather than the container limit has misread the meter. This is particularly common where JBoss EAP runs on OpenShift; see the OpenShift practice hub for the wider container licensing context.

The third trap is the support tier double charge, where the proposal reads premium support as an uplift on a per core basis above the standard subscription, in a way that effectively double counts the cores. The defensible reading is a single core count multiplied by a single subscription rate at the chosen tier, not a layered rate that compounds.3

Cloud topology adds a fourth specific consideration. JBoss EAP on a cloud instance is metered against the vCPU count bound to that instance, in the same shape as it would be metered against a virtual machine in a private hypervisor estate. A buyer that runs JBoss EAP on a sixteen vCPU cloud instance is entitled at sixteen vCPUs. A buyer that runs JBoss EAP across multiple instances is entitled at the sum of the bound vCPUs. The cloud provider's own billing is independent of Red Hat's meter; the buyer pays the cloud provider for the compute and pays Red Hat for the entitlement against that compute.4

Container topology adds a fifth consideration. JBoss EAP container images run inside the container runtime on the host. The CPU limit set in the container specification is the meter, provided the cluster enforces the limit. Where JBoss EAP runs on OpenShift, the OpenShift core entitlement on the cluster nodes does not stack with the JBoss EAP entitlement on the workload; the two are separate meters reading separate things. For the wider OpenShift core counting context, see the OpenShift core counting article.

The reconciled position is that JBoss EAP entitlement is the sum of the cores that JBoss EAP is enforceably bound to across the estate, regardless of the underlying topology, with the topology determining how the binding is implemented and demonstrated. The audit posture follows from the demonstration. The practice has worked with clients to produce the demonstration as part of the standard subscription assessment cycle.

The buyer side reading at JBoss EAP renewal proceeds in five steps. First, inventory the actual deployments of JBoss EAP across the estate, with the topology of each. Second, count the cores that JBoss EAP is enforceably bound to in each deployment and document the enforcement mechanism. Third, sum the bound cores across the estate to produce the total entitled cores required. Fourth, select the support tier appropriate to the workload mix, with the tier applied at the deployment wide level. Fifth, sign the JBoss EAP line at the documented core count and the chosen tier, with the documentation retained for any subsequent audit inquiry.5

Across recent practice engagements, this discipline has produced a recoverable correction band on JBoss EAP renewals where the existing meter read the host rather than the bound cores. Where the prior reading already correctly tracked the binding, the correction was smaller and the conversation moved to multi year structuring and tier optimisation. Either way the structural separation between host and entitlement is the reading that holds at signature.

The corollary on the audit side is that a Red Hat finding that cites total host cores rather than bound cores on a virtualized or containerized estate is reading the topology rather than the meter. The defensible response presents the binding evidence and reconciles against it. For the audit defense engagement, see audit defense; for the renewal engagement, see renewal negotiation; for direct contact, 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.