OpenShift Dev Spaces addresses three fundamental challenges in enterprise software development:

OpenShift Dev Spaces defines a workspace as the project source code together with all dependencies necessary to edit, build, run, and debug it. The IDE and development runtime are treated as workspace dependencies, embedded and always included. This differentiates OpenShift Dev Spaces from traditional development environments where the IDE is bound to a workstation and runtimes are configured locally.

OpenShift Dev Spaces workspaces are OpenShift Pods that replicate application runtimes used in production and provide a development layer on top: intelligent code completion, debugging, and IDE tools. Workspaces are isolated from one another and manage the lifecycle of their own components. Additional resources describes the architecture that delivers these workspaces, the server deployments that manage multi-tenancy, and the internal structure of each workspace pod.

When every developer configures their own local environment, differences in OS versions, tool versions, and dependencies cause "works on my machine" failures. OpenShift Dev Spaces uses devfiles, declarative YAML files that define the exact tools, runtimes, and dependencies for a project. Every developer who opens the same repository gets an identical environment.

New team members must install tools, clone repositories, configure credentials, and troubleshoot build failures before writing their first line of code. With OpenShift Dev Spaces, a new developer opens the dashboard URL, pastes the team’s repository link, and has a fully configured workspace within minutes.

Local development environments store credentials on individual laptops. OpenShift Dev Spaces centralizes credential management through OAuth integration with Git providers and OpenShift RBAC. Developer tokens are stored as OpenShift Secrets on the cluster, not on individual machines.

Even teams that start with consistent environments drift as developers install different extensions, update tools independently, or modify configurations. OpenShift Dev Spaces rebuilds the workspace container from the devfile on each start, so the base toolchain is always consistent. The /home/user directory persists across restarts by default, preserving personal preferences and shell history without affecting the standardized tools and runtimes.

Complex projects with multiple microservices, databases, and build tools can overwhelm laptop hardware. OpenShift Dev Spaces runs workspaces on cluster infrastructure with configurable CPU, memory, and storage limits. Developers get the resources they need without upgrading their hardware.

Organizations in regulated industries need to control where code is developed and how it is accessed. OpenShift Dev Spaces runs entirely within your OpenShift cluster and supports air-gapped environments with no internet access. In air-gapped deployments, all workspace traffic stays within your network boundary.

Platform administrators install OpenShift Dev Spaces on an OpenShift cluster and manage its lifecycle. Their responsibilities include:

Administrators primarily interact with OpenShift Dev Spaces through the OpenShift web console and the oc and dsc command-line tools.

Developers receive the OpenShift Dev Spaces dashboard URL from their administrator and use it to create cloud workspaces. Their experience includes:

Developers do not need cluster access, oc sessions, or any local tooling beyond a web browser.

OpenShift Dev Spaces supports different deployment sizes:

OpenShift Dev Spaces is a strong fit when your team faces one or more of these situations:

Developers need a supported web browser and network access to the OpenShift Dev Spaces dashboard URL. No local tools, CLI installations, or cluster credentials are required.

OpenShift Dev Spaces fits together three groups of components that communicate through Dev Workspace custom resources on OpenShift: server components, the Dev Workspace Operator, and user workspaces. Each group has a distinct role in delivering cloud development environments, and OpenShift RBAC controls access to all resources.

Figure 5.1. High-level OpenShift Dev Spaces architecture with the Dev Workspace operator

OpenShift Dev Spaces runs on three groups of components:

The role of these OpenShift features is central:

Additional resources links to dedicated pages for the server deployments, the Dev Workspace Operator reconciliation loop, and the structure of user workspace pods. The Dev Workspace Operator repository and the OpenShift Custom Resources documentation provide implementation details.

5.1.1. What runs on your cluster

Your cluster runs four OpenShift Dev Spaces server deployments that manage multi-tenancy and workspace lifecycle: the gateway routes and authenticates requests, the dashboard provides the user interface, the server provisions namespaces and integrates with Git providers, and the plug-in registry supplies editor extensions.

Figure 5.2. OpenShift Dev Spaces server components interacting with the Dev Workspace operator

Additional resources

• Section 5.1.2, “Operator and lifecycle management”
• Section 5.1.4, “Gateway and request routing”
• Section 5.1.5, “Dashboard and workspace management”
• Section 5.1.6, “Server and namespace provisioning”
• Section 5.1.7, “Plug-in registry”

5.1.3. Dev Workspace Operator and workspace pods

The Dev Workspace Operator (DWO) manages workspace pods, services, and persistent volumes by reconciling Dev Workspace custom resources on OpenShift. Every OpenShift Dev Spaces workspace has an underlying Dev Workspace CR that contains the devfile, editor definition, and configuration attributes.

The Dev Workspace CR is an OpenShift resource representation of an OpenShift Dev Spaces workspace. Whenever a user creates a workspace using OpenShift Dev Spaces in the background, Dashboard OpenShift Dev Spaces creates a Dev Workspace CR in the cluster. For every OpenShift Dev Spaces workspace, there is an underlying Dev Workspace CR on the cluster.

Figure 5.3. Example of a Dev Workspace CR in a cluster

When creating a workspace with OpenShift Dev Spaces with a devfile, the Dev Workspace CR contains the devfile details. Additionally, OpenShift Dev Spaces adds the editor definition into the Dev Workspace CR depending on which editor was chosen for the workspace. OpenShift Dev Spaces also adds attributes to the Dev Workspace that further configure the workspace depending on how you configured the CheCluster CR.

A DevWorkspaceTemplate is a custom resource that defines a reusable spec.template for Dev Workspaces.

When a workspace is started, DWO reads the corresponding Dev Workspace CR and creates the necessary resources such as deployments, secrets, configmaps, and routes. As a result, a workspace pod representing the development environment defined in the devfile is created.

The Dev Workspace Operator provides four Custom Resource Definitions:

• Dev Workspace contains devfile details and a reference to the editor definition for each workspace.
• DevWorkspaceTemplate defines reusable editor and component templates shared by multiple workspaces.
• DevWorkspaceOperatorConfig defines configuration options for the DWO itself.
• DevWorkspaceRouting specifies workspace container endpoints and routing.

The configuration guide in Additional resources documents the fields and options available for each of these custom resources. The Dev Workspace Operator source code, including the CRD schemas, is in the linked upstream repository.

Additional resources

• Configure the Dev Workspace Operator custom resources
• Content from github.com is not included.Dev Workspace Operator repository

5.1.4. Gateway and request routing

The OpenShift Dev Spaces gateway routes requests, authenticates users with OpenID Connect (OIDC), and enforces OpenShift RBAC policies. It controls access to the dashboard, server, plug-in registry, and every user workspace.

The che-gateway Deployment contains four containers:

• gateway (Traefik) routes requests to the correct backend service.
• oauth-proxy (OAuth2 Proxy) authenticates users with OpenID Connect (OIDC).
• kube-rbac-proxy applies OpenShift Role Based Access Control (RBAC) policies to control access to any OpenShift Dev Spaces resource.
• configbump watches for configuration changes and reloads Traefik routing rules without restarting the Pod.

Each container performs a distinct security and routing function. The security guide in Additional resources covers how to configure the access control policies that these containers enforce, and the Traefik, OAuth2 Proxy, and kube-rbac-proxy project repositories provide upstream documentation for each container.

Figure 5.4. OpenShift Dev Spaces gateway interactions with other components

Additional resources

• This content is not included.Control who can access OpenShift Dev Spaces
• Content from github.com is not included.Traefik
• Content from github.com is not included.OAuth2 Proxy
• Content from github.com is not included.kube-rbac-proxy
• Section 5.1.5, “Dashboard and workspace management”
• Section 5.1.6, “Server and namespace provisioning”
• Section 5.1.7, “Plug-in registry”
• Section 5.2, “What developers get in a workspace”

5.1.5. Dashboard and workspace management

The user dashboard is the landing page of Red Hat OpenShift Dev Spaces where users create, manage, and access their workspaces. It coordinates with the OpenShift Dev Spaces server and OpenShift API to convert devfiles into running workspace pods.

It is a React application. The OpenShift Dev Spaces deployment starts it in the devspaces-dashboard Deployment.

It needs access to the OpenShift Dev Spaces server and the OpenShift Application Programming Interface (API).

Figure 5.5. User dashboard interactions with other components

When the user requests the user dashboard to start a workspace, the user dashboard executes this sequence of actions:

1. Sends the repository URL to the OpenShift Dev Spaces server and expects a devfile in return, when the user is creating a workspace from a remote devfile.
2. Reads the devfile describing the workspace.
3. Converts the information into a Dev Workspace Custom Resource.
4. Creates the Dev Workspace Custom Resource in the user project using the OpenShift API.
5. Watches the Dev Workspace Custom Resource status.
6. Redirects the user to the running workspace IDE.

Additional resources

• Customize the developer dashboard
• Section 5.1.6, “Server and namespace provisioning”

5.1.6. Server and namespace provisioning

The OpenShift Dev Spaces server is a Java web service that creates user namespaces, provisions them with secrets and config maps, and integrates with Git service providers for devfile fetching and authentication.

The OpenShift Dev Spaces server main functions are:

• Creating user namespaces.
• Provisioning user namespaces with required secrets and config maps.
• Integrating with Git services providers, to fetch and validate devfiles and authentication.

The OpenShift Dev Spaces server is a Java web service exposing a Hypertext Transfer Protocol (HTTP) REST API and needs access to:

• Git service providers
• OpenShift API

Figure 5.6. OpenShift Dev Spaces server interactions with other components

Additional resources

• Fine-tune the OpenShift Dev Spaces server

5.1.7. Plug-in registry

The OpenShift Dev Spaces plug-in registry provides extensions for the Visual Studio Code editor.

The online instance linked in Additional resources provides the latest community version of the registry.

Figure 5.7. Plugin registries interactions with other components

Additional resources

• Content from eclipse-che.github.io is not included.Plugin registry latest community version online instance

Developers get browser-based IDEs running in OpenShift containers, with on-demand access to editors, language servers, debugging tools, and application runtimes without local setup.

Figure 5.8. User workspaces interactions with other components

Each workspace runs as an OpenShift Pod containing the IDE, language servers, debugging tools, and application runtimes. Developers interact with the workspace through a browser-based editor or a desktop IDE connected over SSH.

A workspace Pod includes:

Supporting OpenShift resources created for each workspace:

The devfile v2 format specifies which tools and runtimes a workspace includes. When a workspace starts, the Dev Workspace Operator reads the devfile and creates all necessary OpenShift resources.

Figure 5.9. OpenShift Dev Spaces workspace components

Platform administrators deploy, configure, secure, upgrade, and monitor OpenShift Dev Spaces on OpenShift clusters. They manage the Operator, the CheCluster custom resource, and the platform infrastructure that developers use.

Common tasks include:

Developers create workspaces, write code, use IDE extensions, and integrate with Git repositories. They consume the cloud development environments that platform administrators provide.

Common tasks include:

Revised on 2026-07-27 19:47:43 UTC