OpenShift Dev Spaces, read on the workspace cluster.

Red Hat OpenShift Dev Spaces is the productised release of the upstream Eclipse Che project, packaged as a cluster operator on Red Hat OpenShift Container Platform. The product runs each developer workspace as a Kubernetes pod on a dedicated workspace cluster, exposing the editor through a browser based interface that connects to the workspace pod over a websocket1. The developer interacts with a remote workspace rather than a local IDE, and the workspace lifecycle is managed by the Dev Spaces controller on the cluster.

The reading in 2026 is that OpenShift Dev Spaces does not carry a per developer or per workspace charge. The product is included as a value added operator inside Red Hat OpenShift Container Platform on the cluster where the operator runs2. The platform line on the workspace cluster cores absorbs the Dev Spaces attribution, and the attribution scales with cluster size rather than with developer headcount.

The structural distinction matters at the renewal table. A buyer who scopes Dev Spaces against developer headcount maps the wrong variable to the cost. The variable that matters is concurrent workspace count multiplied by workspace pod sizing, which together drive cluster core count and the platform line. A team of one hundred developers with twenty workspaces concurrent at any given moment carries a smaller platform line attribution than a team of forty developers where every developer keeps a workspace open continuously.

Each Dev Spaces workspace runs as a pod with resource requests typically in the two to eight cores range depending on the workspace template3. A workspace template that includes language servers, container runtimes, and database connectors sits at the high end. A workspace template that runs a minimal editor sits at the low end. The cluster sizing is the sum of the steady state pod requests across the concurrent workspaces, plus the cluster system overhead.

The concurrency profile across a developer organisation is rarely flat. A typical pattern shows peak concurrency on weekday mornings in the local timezone, falling concurrency through lunch, secondary peak in the afternoon, and a long tail of low concurrency overnight as developers in other timezones come online. The workspace cluster sized to absorb the morning peak carries a platform line that reads at the morning peak twenty four hours a day.

The mitigation depends on workspace idle behaviour. Dev Spaces supports workspace idling, where workspaces with no recent activity are paused and the underlying pods are scaled down. A workspace pool with aggressive idling sees the cluster autoscaler shed worker nodes during low concurrency windows, and the platform line attribution reads on the average rather than the peak. A workspace pool without idling carries the morning peak across the entire day and produces an expensive platform line on the cluster.

Workspace templates define the pod specification for each workspace type. A platform team that ships a single heavyweight template for every developer bakes the heavyweight cost into every workspace. A platform team that ships a small set of right sized templates aligned to actual developer workload allows the typical workspace to run lighter while still offering a heavyweight template for the workloads that need it.

The audit reading captures the cluster, not the template. The buyer who deploys a heavyweight template across the organisation pays the platform line at the heavyweight cluster size. The buyer who right sizes templates pays at the right sized cluster. Template right sizing tends to be the highest leverage operational change on a Dev Spaces deployment because it scales linearly with both concurrent workspace count and per workspace pod request.

A subscription assessment in the ninety days before renewal produces a workspace template by concurrency inventory and reconciles the cluster sizing against the realistic concurrency and template mix.

Three counting traps produce most of the exposure observed across Dev Spaces engagements in the trailing twelve months.

The first trap is the workspace pool without idling. Workspaces left open overnight, over weekends, and through vacations consume cluster capacity at all hours. The audit reads the cluster at peak; the cluster sits at peak because idling is not configured. The mitigation is a workspace idling policy reviewed quarterly with the platform team.

The second trap is the heavyweight workspace template applied to every developer4. A template that includes every language server and every database connector consumes four to eight cores per workspace where a right sized template would consume two. A workspace pool of fifty concurrent workspaces carries the difference at the cluster level, and the cluster line at signature reads the heavyweight cluster.

The third trap is the workspace cluster shared with non workspace workloads. A cluster that runs Dev Spaces workspaces alongside CI build jobs or batch workloads cannot easily reconcile the workspace attribution at audit because the cluster cores absorb both workloads through the same platform line. A dedicated workspace cluster simplifies the audit reading and supports independent right sizing.

OpenShift Dev Spaces is read through the platform line on the workspace cluster cores. The buyer who reads the line against developer headcount and not against concurrent workspace count maps the wrong variable to the cost. The buyer who reads the line against peak concurrency without an idling policy carries the peak across the day. The buyer who reads the line against right sized templates and idled workspaces pays the line at the realistic steady state.

The discipline at signature sets four protections that hold across the term. The workspace cluster scope is named in the contract record, decoupled from non workspace workloads where possible. The workspace idling policy is documented with the inactivity threshold and the cluster autoscaler behaviour. The workspace template inventory is captured with the per template pod sizing so future template changes are reviewed for cost impact. A quarterly concurrency inventory aligns the operational reality with the contract scope.

For the broader cross product reading, see the OpenShift practice hub, the GitOps entitlement, the Pipelines line, the serverless cluster read, and the developer program read when Dev Spaces sits alongside the developer subscription estate. For the engagement protocol, see contact.

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.