Red Hat maps a four-zone, quota-aware OpenShift Dev Spaces architecture

Red Hat has published a production-oriented architecture for operating OpenShift Dev Spaces as a multi-tenant internal platform, separating control components, shared services, extension assets and individual developer workspaces into four namespace zones.

The field guide is based on deployments using OpenShift 4.20.16 and OpenShift Dev Spaces 3.26. Its focus is less on installing a cloud development environment than on keeping one governable as usage grows: identity controls, quota-aware provisioning, cost labels, storage isolation and cleanup of workspace objects.

Four zones instead of one namespace

The proposed layout keeps the operators and cluster-wide configuration in openshift-devspaces, places the CheCluster instance and shared routing services in a separate devspaces-checluster namespace, isolates the internal OpenVSX extension service and its database in devspaces-openvsx, and assigns each developer a dedicated workspace namespace.

Red Hat’s guide warns that placing the CheCluster custom resource in the operator namespace can let reconciliation overwrite settings such as pruning rules, security profiles or idle timeouts. The separate core-server zone is intended to prevent that collision, while per-user namespaces provide compute, storage and network boundaries that can also carry chargeback metadata.

Quotas expose a gateway trap

For larger installations, the article recommends disabling automatic workspace-namespace provisioning and routing requests through a self-service portal. That lets platform teams attach ResourceQuota, LimitRange and cost-allocation labels when a namespace is created rather than patching them in later.

There is a specific implementation catch. Dev Spaces intentionally omits a CPU limit from the che-gateway container, but a namespace quota may require every container to declare one. The result is a rejected workspace pod. The guide’s remedy is to configure the gateway’s CPU limit explicitly in the CheCluster resource; the general default-container settings do not cover that container.

The resource caps are also per container, not per workspace. A workspace with three containers can therefore consume three times the nominal per-container ceiling, an important distinction for capacity and cost models.

Cleanup protects the control plane

The design pairs four-hour inactivity idling with a monthly job that deletes workspaces stopped for more than 30 days. Red Hat says stopped workspace custom resources still occupy etcd, citing guidance that roughly 6,000 such objects can consume about 2.5 GB.

This is an implementer’s pattern rather than a new Dev Spaces release. Its value is the collection of failure modes that do not show up in a basic installation: reconciliation conflicts, quota rejection, misleading resource ceilings and persistent control-plane state. Platform teams can use the design as a starting point, but should map the examples to the documentation and supported configuration for the specific OpenShift and Dev Spaces versions they deploy.