How OpenShift Dev Spaces works

OpenShift Dev Spaces delivers cloud development environments through three groups of components: server components that manage multi-tenancy, the Dev Workspace Operator that provisions workspace pods, and user workspaces where developers write code.

What happens when a developer starts a workspace

  1. The developer selects a Git repository in the dashboard and clicks Create & Open.
  2. The Dev Spaces server resolves the devfile from the repository, selects the editor, and creates a DevWorkspace custom resource in the developer's namespace.
  3. The Dev Workspace Operator reconciles the custom resource into a running pod with the specified containers, persistent storage, and injected credentials.
  4. The gateway authenticates the developer's session and routes browser traffic to the IDE running inside the workspace pod.

This sequence completes in under 60 seconds for cached images. The developer gets a full IDE with terminal access, language support, and direct access to the OpenShift cluster API.

Three component groups

All components run in the openshift-devspaces namespace. They divide into three groups with distinct responsibilities:

Server components
Four long-lived deployments that serve all users: the Traefik-based gateway, the developer dashboard, the Dev Spaces server, and the plug-in registry. These handle authentication, workspace orchestration, and traffic routing.
Dev Workspace Operator
A Kubernetes operator that translates DevWorkspace custom resources into running pods. It manages container images, persistent volumes, Secrets injection, and network policies. The operator runs independently and can serve multiple Dev Spaces installations on the same cluster.
User workspaces
One pod per developer session, running in a per-user namespace. Each workspace contains the IDE process, project source code, language servers, and any sidecar containers defined in the devfile. OpenShift RBAC isolates workspaces between users.

How updates are delivered

The Dev Spaces Operator installs through the Operator Lifecycle Manager (OLM). When a new version becomes available on the update channel, OLM replaces the operator pod. The operator then reconciles the CheCluster custom resource and rolls out updated server components without manual intervention or workspace downtime.