Single node and three node OpenShift, licensed for the compact site.
Single node OpenShift, often abbreviated SNO, and the three node compact cluster are the two profiles Red Hat ships for sites where the conventional three control plane plus N worker cluster does not fit. The 2026 reading is that both profiles carry a small node entitlement subscription class that sits beneath the standard per worker core line, but the entitlement requires the site to actually fit the profile constraints; a single node deployment that grows past its capacity envelope migrates to the standard reading and the subscription line moves with it. The contract record should name the profile at each site so the audit reads the line correctly.
Single Node OpenShift, the all in one cluster.
Single Node OpenShift is the deployment profile in which the OpenShift control plane and the worker role both run on a single host. The host carries the API server, the etcd state store, the scheduler, the controller manager, and the workload pods that the cluster runs. The profile produces a fully functional OpenShift cluster that operates with the standard OpenShift API surface and the standard tooling, but it does so on one host rather than on the three control plane plus N worker arrangement of a standard cluster1.
The profile is built for sites where the operational deployment cannot accommodate three control plane hosts. A telecommunications cell site, a small bank branch, a manufacturing line cabinet, a maritime vessel, a remote oil platform. The compute footprint at these sites is materially smaller than the data centre standard and the redundancy properties of the multi node arrangement are either not required or are provided by redundant deployments of single node clusters at peer sites rather than by node redundancy within a single cluster.
The Red Hat subscription line in 2026 covers single node OpenShift through a small node entitlement subscription class designed for the compact profile. The class sits beneath the standard per worker core line and produces a renewal arithmetic that respects the small footprint of the deployment. A buyer with one hundred and twenty SNO sites reads against one hundred and twenty small node entitlements rather than against the per core count those sites would aggregate to under the standard reading.
Three node compact, the resilient compact cluster.
The three node compact cluster runs the OpenShift control plane across three hosts that also act as worker nodes for the workload pods. Each host carries a control plane component and a worker role, and the cluster maintains the etcd quorum and the API redundancy properties of a standard OpenShift cluster while running on a footprint of three hosts rather than on the larger control plane plus worker arrangement2. The profile produces resilience properties closer to the data centre standard at a smaller hardware footprint.
The compact profile is favoured at sites where the workload tolerance requires resilience to a single host failure but where the full multi node cluster footprint is too large. A regional data centre with one hundred and twenty cores of compute. An edge co location facility with three rack units of dedicated OpenShift capacity. A factory floor IT closet with three industrial computers. The three node arrangement maintains the etcd quorum across two of three hosts in a failure scenario; the workload pods that were running on the failed host reschedule onto the remaining two.
The three node compact cluster carries the small node entitlement subscription class at a different volume reading than the single node profile. The line accrues per cluster rather than per host, and the cluster reads as one compact cluster regardless of the variation in core count across the three hosts. A buyer with twenty compact clusters reads against twenty compact cluster entitlements; the cores on each host inside the cluster are absorbed by the compact entitlement reading rather than counted individually against the standard per worker core line.
Three counting traps across the compact fleet.
Three counting traps produce most of the exposure observed across single node and three node compact cluster engagements in the trailing twelve months.
The first trap is the SNO site that grew past its capacity envelope. A buyer deploys a single node cluster on a host with the expectation that the workload will sit at thirty percent utilisation across the term, and the operational reality grows the workload to eighty percent utilisation by year two. The platform team responds by attaching worker nodes to the single node cluster, which converts the deployment to a multi node cluster on the same host arrangement. The audit reads the multi node deployment against the standard per worker core line rather than against the small node entitlement, and the SNO subscription class no longer applies to the site3. The mitigation is a quarterly review of SNO utilisation and a contract clause that allows migration from SNO to a multi node profile inside the contract scope rather than as a mid term renegotiation.
The second trap is the three node compact cluster that was scaled out to a four or five node deployment. The compact entitlement class requires the cluster to fit the three node arrangement; a fourth host added to the cluster, even one that runs only as a worker node, breaks the compact constraint and migrates the cluster to the standard reading. The buyer who scaled out to handle a transient workload spike during a peak season may discover at audit that the entire term reads against the standard per worker core line rather than against the compact entitlement.
The third trap is the contract record that does not name the profile at each site. A buyer with a mixed fleet of SNO sites, three node compact clusters, and small multi node clusters signs a renewal scope that names a site count without distinguishing the profile mix. The audit defaults to the standard reading absent contract language that names the small node entitlement, and the buyer pays the per worker core line against a footprint the small entitlement should cover. The decomposition at signature tends to surface a twelve to twenty percent saving against the unstructured posture, recurring annually across the term.
| Pattern | Frequency | Reading |
|---|---|---|
| Profile mix named in contract record | 3 of 10 | Pays |
| SNO sites and three node clusters enumerated | 2 of 10 | Pays |
| SNO site grew past capacity envelope | 2 of 10 | Traps |
| Compact cluster scaled to a fourth host | 2 of 10 | Traps |
| Site count named without profile mix | 1 of 10 | Traps |
Reading the compact line against the profile constraint.
OpenShift single node and three node compact cluster licensing is read on the small node entitlement subscription class against the site count and the profile mix. The reading at signature should reflect the SNO inventory, the three node compact cluster inventory, the small multi node clusters that sit on the boundary, and the operational expectation for the term. The buyer who signs against the profile mix pays the small entitlement on the small sites and the standard line on the standard ones. The buyer who signs against a site count without profile mix pays the larger of the two lines absent contract language to the contrary.
The discipline at signature sets four protections that hold across the term. The profile at each site is named in the contract record with the small node entitlement attached where it applies. The capacity envelope on SNO sites is documented so the audit reads the SNO entitlement at the deployment profile rather than at the standard reading once growth occurs. The three node compact constraint is named explicitly so a transient scale out to a fourth host does not break the compact entitlement reading. A quarterly compact cluster inventory captures site by site profile state.
For the broader cross product reading, see the OpenShift practice hub, the edge deployment read for the field site context in which compact profiles often appear, the bare metal versus virtualized read for the host platform decision underneath, the ACM pricing read for the governance line that the compact fleet accrues, and the telecommunications audit posture where compact profiles cluster densely at cell site scale. For the engagement protocol, see subscription assessment and contact.
Notes & references
- 1. Red Hat Single Node OpenShift documentation, accessed across 2025 and 2026. SNO runs the OpenShift control plane and the worker role on a single host and is the deployment profile used at sites where the multi node arrangement does not fit.
- 2. Red Hat three node compact cluster documentation, accessed across 2025 and 2026. The three host arrangement runs the control plane across the same three hosts that act as worker nodes, producing a small footprint cluster with resilience properties close to the data centre standard.
- 3. Capacity envelope breach on SNO migrates the deployment from the small node entitlement to the standard per worker core reading. The contract should name the SNO deployment so the migration triggers a defined expansion mechanic rather than a mid term renegotiation.
- 4. Practice observation across ten compact cluster engagements settled in the trailing twelve months. The most common exposure pattern is the SNO site that grew past its capacity envelope without a corresponding update to the contract record.
- 5. Concession bands and trailing twelve month figures refer to the practice observation across signed contracts. The eighty two percent audit exposure reduction in marginalia is the trailing twelve month average across defenses settled.
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.