---
title: "Build a multi-tenant platform with OpenShift Dev Spaces"
description: "Local developer workstations introduce three concrete operational risks: production-parity risk from environment drift, slow time-to-first-commit for new engineers, and unmanaged security exposure from misconfigured tools. Red Hat OpenShift Dev Spaces addresses these by moving compute and tooling into containerized workspaces running directly on the cluster, with environments declared as code in a devfile. A production deployment requires four-zone namespace isolation separating control (openshift-devspaces), core server (devspaces-checluster), secure asset (devspaces-openvsx), and sandbox (username-devspaces) zones to prevent operator reconciliation from overriding custom configurations. Resource governance uses a two-tier model with defaultContainerResources fallback limits and containerResourceCaps absolute per-container ceilings, while automated cleanup cron jobs (monthly on the 1st) and inactivity idling (after 4 hours) protect etcd health by removing stopped workspaces after 30 days. The guide concludes with next steps for authentication and private extension registries."
---

# Build a multi-tenant platform with OpenShift Dev Spaces

[Red Hat](https://yomu.fyi/company/red-hat) · Ajay Kanse · Oct 9, 2026

**Type:** Tutorial

## Summary

Local developer workstations introduce three concrete operational risks: production-parity risk from environment drift, slow time-to-first-commit for new engineers, and unmanaged security exposure from misconfigured tools. Red Hat OpenShift Dev Spaces addresses these by moving compute and tooling into containerized workspaces running directly on the cluster, with environments declared as code in a devfile. A production deployment requires four-zone namespace isolation separating control (openshift-devspaces), core server (devspaces-checluster), secure asset (devspaces-openvsx), and sandbox (username-devspaces) zones to prevent operator reconciliation from overriding custom configurations. Resource governance uses a two-tier model with defaultContainerResources fallback limits and containerResourceCaps absolute per-container ceilings, while automated cleanup cron jobs (monthly on the 1st) and inactivity idling (after 4 hours) protect etcd health by removing stopped workspaces after 30 days. The guide concludes with next steps for authentication and private extension registries.

## Context

Local developer workstations introduce operational risks: environment drift, slow onboarding, and unmanaged security exposure. The solution is a cloud development environment (CDE) where compute and tooling move off laptops onto a governed platform. Red Hat OpenShift Dev Spaces implements this model with containerized workspaces declared as code in a devfile.

## Approach / What changed

Deploy OpenShift Dev Spaces with four isolated namespaces (control, core server, secure asset, sandbox) to separate operator configs from workloads. Use defaultContainerResources and containerResourceCaps for two-tier resource limits. Enable workspace cleanup CronJob with 30-day retention and inactivity idling of 4 hours to protect etcd.

## Takeaways

- Four-zone namespace isolation prevents the operator’s reconciliation loop from silently overriding custom DevWorkspaceOperatorConfig parameters by placing the CheCluster CR in its own dedicated namespace.
- Two-tier resource governance uses defaultContainerResources as a system-wide fallback and containerResourceCaps as an absolute per-container ceiling, preventing memory over-provisioning while allowing multi-container workspaces.
- Automated cleanup of stopped workspaces (30-day retention via CronJob) combined with inactivity idling (4 hours) keeps etcd state footprint within safe limits (under 8 GB) to maintain cluster stability.

## FAQ

### How does namespace isolation prevent config overrides?

Placing the CheCluster custom resource in its own namespace (devspaces-checluster) prevents the operator's reconciliation loop from resetting custom parameters like workspace pruning rules and idle timeouts to factory defaults.

### What is the two-tier resource governance model?

defaultContainerResources sets per-container fallback limits (e.g., 500m CPU, 2Gi memory), while containerResourceCaps enforces an absolute ceiling per container (e.g., 4 CPU, 32Gi memory). Caps apply per container, not per workspace pod.

### How does automated cleanup protect etcd health?

Stopped workspaces hold state as custom resources in etcd. The cleanup CronJob deletes workspaces stopped for more than 30 days, and inactivity idling stops pods after 4 hours, keeping etcd footprint under the recommended 8 GB limit.

**Tags:** [Developer Experience](https://yomu.fyi/topic/developer-experience), [Kubernetes](https://yomu.fyi/topic/kubernetes), [Multi-tenant](https://yomu.fyi/topic/multi-tenant), [Platform](https://yomu.fyi/topic/platform), [Red Hat OpenShift](https://yomu.fyi/topic/red-hat-openshift)

- Source: [Red Hat](https://developers.redhat.com/articles/2026/10/09/build-multi-tenant-platform-openshift-dev-spaces)
- Source URL: https://developers.redhat.com/articles/2026/10/09/build-multi-tenant-platform-openshift-dev-spaces
- Ingested by Yomu: 2026-10-09T15:00:14.295Z

[Read original post](https://developers.redhat.com/articles/2026/10/09/build-multi-tenant-platform-openshift-dev-spaces)