Decision Manager, priced per execution core.

JBoss Decision Manager licensing meters by core on the host running the rule engine at execution time. The product is the supported distribution of the Drools rule engine, packaged with the kie server for runtime execution, the Business Central authoring environment for the business analyst, and the integration with the JBoss EAP and Quarkus runtimes that host the engine. The metered unit is the execution core; the authoring environment, the rules repository, and the user count on Business Central are not metered separately under the standard entitlement.1

The product sits in a category of business rules platforms where the metering shape varies dramatically across vendors. Some vendors meter by named user, others by transaction volume, others by the number of rules in the repository. Red Hat's per execution core model favours estates with stable rule volumes and predictable execution patterns; the cost scales with the runtime footprint rather than with the size of the rules portfolio or the size of the analyst team.

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

Three counting traps recur on Decision Manager estates. Each is correctable through reshape before audit or renewal.

The first trap is counting cores on the development authoring environment as runtime cores. Business Central runs the rules authoring environment for the business analyst; the kie server runs the execution engine. The runtime entitlement applies to the kie server cores. Operators sometimes count the Business Central host alongside the kie server hosts, which doubles the entitlement on infrastructure that does not need it. The reshape is to confirm which hosts run the execution engine and entitle only those.

The second trap is licensing every kie server in a clustered runtime as a separate entitlement. A clustered Decision Manager runtime normally runs three or more kie server instances behind a load balancer for high availability. All instances are in scope as active members of the cluster because each kie server is an execution engine. The reshape is to confirm the cluster size reflects the operational load rather than overprovisioned headroom; the seller side does not exclude replicas from the count.2

The third trap is embedding the rule engine in application JVMs without recognising the entitlement chain. Drools supports embedded execution inside an application JVM, where the engine runs as a library inside the application rather than as a separate kie server. The entitlement still applies on the cores of the host running that application. Operators sometimes treat the embedded mode as out of scope because no kie server is visible; the seller side reads the entitlement as attaching to any host where the supported engine executes. The reshape is to either move the engine to a kie server or to count the embedding hosts.

The runtime model on a Decision Manager estate shapes the entitlement footprint more than the rules portfolio itself. Three patterns dominate. The first is the dedicated kie server cluster pattern, where rule execution runs on a separate cluster of kie servers and applications call the engine over the network. The entitlement is sized to the kie server cores. The second is the embedded engine pattern, where rules execute inside application JVMs and no separate cluster exists. The entitlement applies to every host running an application that embeds the engine. The third is the hybrid pattern, where some rules execute on a central cluster and others embed inside application JVMs.

The cost shape across the three patterns is non trivial. The dedicated cluster pattern usually produces the smallest entitlement count because the runtime footprint is concentrated. The embedded pattern often produces the largest count because every application host carries the engine. The hybrid pattern lands in the middle, with the cost depending on the share of execution that sits on the central cluster versus the embedded hosts. For estates considering a runtime consolidation, the reshape opportunity sits in moving embedded execution onto a central kie server cluster.3

One operational note matters. The kie server runtime base can be either JBoss EAP or Quarkus depending on the deployment. The runtime base does not change the Decision Manager entitlement count but does change the adjacent entitlement footprint; for the Quarkus side reading, see the Quarkus licensing note.

Drools is an upstream open source project. The community distribution runs the same rule engine as JBoss Decision Manager, with the paid build providing support, certified compatibility within the Red Hat platform, and a long term maintenance commitment on selected versions. The boundary against community use is consequential where the rules platform sits in a regulated workflow or in a production critical decision path.

Three boundary patterns work in operational practice. The first is paid build on production decision flows, community build on analytics and reporting use cases. Production decision flows that affect customer outcomes, financial settlements, or compliance decisions normally require vendor support and the paid build. Analytics and reporting use cases that compute aggregates from rule scoring can often run on community Drools where the operational consequence of a failure is lower.

The second is paid build on the central execution platform, community build on team owned rule sets. Where the central rules platform handles cross domain decisions and team owned platforms handle local decisions, the entitlement attaches to the central platform alone. The reshape requires technical separation between the central platform and the team platforms.

The third is paid build only on long term support versions. Where the paid build's maintenance commitment is the actual value, the reshape is to license only the kie servers that pin to a long term version and let the rest run the community release. This pattern is less common on Decision Manager than on Quarkus or Keycloak because the rules platform tends to be more conservatively versioned and the support value carries more weight. For the surrounding industry reading where business rules platforms sit inside production critical workflows, see the healthcare audit considerations note on claim adjudication rule estates. For the sibling middleware platform that often pairs with Decision Manager on event driven rule execution, see the AMQ Streams licensing note.

The renewal posture on a Decision Manager estate has three components worth preparing before the seller side prices the next term. The first is the runtime inventory, which should resolve every kie server and every embedded engine host to its core count and confirm that authoring hosts have been removed from the runtime count. The second is the consolidation review, which should test whether embedded execution can move onto a central cluster with a smaller aggregate core count. The third is the community boundary, with the technical enforcement documented for each environment where the paid build and the community build coexist.

The seller side at renewal often positions Decision Manager as part of a broader Red Hat Process Automation or Runtimes commitment. The buyer side reading is to treat any bundle conversation against the actual consumption pattern. Where the estate runs Decision Manager standalone without Process Automation, the bundle does not pay. Where both products run on overlapping host bases, the bundle may pay; the analysis is mechanical.

For estates evaluating Decision Manager licensing ahead of a renewal or audit, the engagement is normally a subscription assessment scoped to the rules estate plus a runtime model review and a community boundary check. To begin, see the contact page. For the sibling reading on the process automation product that often pairs with Decision Manager on workflow estates, see the Keycloak licensing note for the identity layer that fronts the rules portal and the 3scale API management licensing note for the API tier that exposes the engine to consumers.

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.