Application Foundations, priced at the bundle break.

Red Hat OpenShift Application Foundations is the Red Hat middleware bundle positioned for OpenShift customers building modern application workloads on the cluster. The bundle ships as a set of operators on the OpenShift catalogue and is priced as a single OpenShift adjacent entitlement metered against the OpenShift worker pool the application workloads run on. The included components, on the published product page across 2025 and 2026, cover Red Hat AMQ Streams as the Kafka offering, Red Hat AMQ Broker as the message broker, Red Hat Service Registry as the schema and API registry, Red Hat Build of Quarkus as the supported runtime, Red Hat Build of Apache Camel as the integration runtime, and Red Hat Build of Keycloak as the identity broker1.

The bundle is sold as a node level entitlement that scales with the OpenShift worker pool hosting the application workloads. The unit is comparable to the OpenShift core counting basis, with the bundle layered on top of the OpenShift subscription rather than replacing any portion of it. A buyer that runs OpenShift on a hundred core worker pool subscribes the bundle against that worker pool footprint, regardless of how many of the bundled components the application workloads actually use2.

The standalone alternative is a series of individual subscriptions: AMQ Streams as a per node JBoss entitlement, Service Registry as part of the Service Registry offering, the Build of Quarkus and the Build of Camel as supported runtime subscriptions, the Build of Keycloak as the identity entitlement. Each carries its own subscription unit and its own pricing line. The procurement function that adds up all the standalone lines for a buyer who would use most of the bundle's components arrives at a price materially above the bundled line.

The breakeven line between the bundle and the standalone path runs through the number of components the application workloads actually activate. A buyer that uses only AMQ Streams is paying the bundle line for a single component the standalone subscription would have covered more cheaply. A buyer that uses AMQ Streams plus the Build of Quarkus is at roughly the breakeven point depending on the worker pool size and the concession band. A buyer that uses three or more components is on the bundle side of the breakeven and is paying materially less than the standalone path would price.

The procurement function should price both paths at the negotiation table. The buyer who knows the application portfolio at signature can list the components per workload and read the breakeven directly. The buyer who anticipates expansion of the application portfolio during the contract term should price the bundle against the expected end state portfolio, not the day one portfolio, because the bundle absorbs new components without a contract amendment while the standalone path requires an amendment per component3.

The standalone path can be cheaper in two specific cases. The first is the buyer with a very small worker pool footprint and a single bundled component; the standalone subscription on a small footprint is below the bundle minimum. The second is the buyer that uses a bundled component for a workload outside the OpenShift cluster, in which case the bundle does not cover the external use and the standalone subscription is required regardless. A buyer with both an in cluster and an out of cluster footprint of the same component carries the bundle for the in cluster footprint and a standalone subscription for the out of cluster footprint, which the procurement function should treat as one negotiation across two lines.

The bundle reads cleanly at audit because the entitlement is a single line metered against the OpenShift worker pool. The audit reads the worker pool count against the bundle line and the conversation is short. The standalone path reads through several lines simultaneously: the AMQ Streams subscription against its node count, the Service Registry subscription against its node count, the Build of Quarkus subscription against its node count, and so on. Each line is its own short conversation, and the audit calendar reflects the total surface rather than the bundle's single line.

The audit posture also differs in how a quietly activated component reads. On the standalone path, a workload that begins using the Build of Camel without a corresponding subscription reads at audit as an unsubscribed product. On the bundle, the same workload reads at the worker pool count against the bundle's existing entitlement and is automatically covered. The bundle therefore absorbs new component activation through the term without exposure; the standalone path requires a procurement ticket per activation4.

The trade off is the bundle's coverage envelope. The bundle covers the components Red Hat names in the bundle definition; it does not cover middleware components outside that definition. A buyer that uses Red Hat 3scale, Red Hat Decision Manager, or the JBoss Web Server alongside the bundled components still subscribes those products separately. The procurement narrative should name every middleware component in scope and check it against the bundle definition before signature.

The buyer side discipline at the procurement table is an application portfolio map that names every application, the components it uses today, the components it is planned to use across the contract term, and the OpenShift worker pool that hosts it. The procurement function reads the map against the bundle definition and the standalone price sheet and chooses the path that prices cleanly against the application portfolio's end state rather than its day one state. The bundle is cheaper at three components and cleaner at any number; the standalone path is cheaper only at one component and only when the buyer is confident the portfolio will not expand.

For the broader cross product reading, see the OpenShift practice hub, the Red Hat Build of Quarkus licensing read for one of the bundled runtimes, the Red Hat Build of Keycloak licensing read for the identity component, the Red Hat Build of Apache Camel licensing read for the integration runtime, and the 3scale API management licensing read for the adjacent middleware product that sits outside the bundle definition. For the engagement protocol, see renewal negotiation and contact.

OpenShift Application Foundations bundle economics break at the second or third active component and favour the bundle at any number above that. The bundle's procurement clarity and audit posture argue in its favour even at the breakeven point. The buyer who prices the application portfolio at end state rather than at day one signs the bundle when the bundle is the right contract; the buyer who prices only the day one portfolio commonly returns to the bundle at the next renewal and pays the conversion cost.

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.