Understanding Che workspaces architecture
Che workspaces architecture
A Che deployment on the cluster consists of the Che server component, a database for storing user profile and preferences, and a number of additional deployments hosting workspaces. The Che server orchestrates the creation of workspaces, which consist of a deployment containing the workspace containers and enabled plug-ins, plus related components, such as:
-
ConfigMaps
-
services
-
endpoints
-
ingresses/routes
-
secrets
-
PVs
The Che workspace is a web application. It is composed of microservices running in containers that provide all the services of a modern IDE such as an editor, language auto-completion, and debugging tools. The IDE services are deployed with the development tools, packaged in containers and user runtime applications, which are defined as Kubernetes resources.
The source code of the projects of a Che workspace is persisted in a Kubernetes or OpenShift PersistentVolume
. Microservices run in containers that have read-write access to the source code (IDE services, development tools), and runtime applications have read-write access to this shared directory.
The following diagram shows the detailed components of a Che workspace.

In the diagram, there are three running workspaces: two belonging to User A and one to User C. A fourth workspace is getting provisioned where the plug-in broker is verifying and completing the workspace configuration.
Use the devfile format to specify the tools and runtime applications of a Che workspace.
Che workspace components
This section describes the components of a Che workspace.
Che Plugin
plug-ins
Che Plugin
plug-ins are special services that extend Che workspace capabilities. Che Plugin
plug-ins are packaged as containers. Packaging plug-ins into a container has the following benefits:
-
It isolates the plug-ins from the main IDE, therefore limiting the resources that a plug-in has access to.
-
It uses the consolidated standard of container registries to publish and distribute plug-ins (as with any container image).
The containers that plug-ins are packaged into run as sidecars of the Che workspace editor and augment its capabilities.
Visual Studio Code extensions packaged in containers are Che plug-ins for the Che-Theia editor.
Multiple Che plug-ins can run in the same container (for better resource use), or a Che Plugin can run in its dedicated container (for better isolation).
Che Editor
plug-in
A Che Editor
plug-in is a Che workspace plug-in.
It defines the web application that is used as an editor in a workspace.
The default Che workspace editor is Che-Theia.
It is a web-based source-code editor similar to Visual Studio Code (VS Code).
It has a plug-in system that supports VS Code extensions.
Source code |
|
Container image |
|
Endpoints |
|
Che user runtimes
Use any non-terminating user container as a user runtime. An application that can be defined as a container image or as a set of Kubernetes or OpenShift resources can be included in a Che workspace. This makes it easy to test applications in the Che workspace.
To test an application in the Che workspace, include the application YAML definition used in stage or production in the workspace specification. It is a 12-factor app dev/prod parity.
Examples of user runtimes are Node.js, SpringBoot or MongoDB, and MySQL.
Che workspace JWT proxy
The JWT proxy is responsible for securing the communication of the Che workspace services. The Che workspace JWT proxy is included in a Che workspace only if the Che server is configured in multi-user mode.
An HTTP proxy is used to sign outgoing requests from a workspace service to the Che server and to authenticate incoming requests from the IDE client running on a browser.
Source code |
|
Container image |
|
Che plug-ins broker
Plug-in brokers are special services that, given a plug-in meta.yaml
file:
-
Gather all the information to provide a plug-in definition that the Che server knows.
-
Perform preparation actions in the workspace namespace (download, unpack files, process configuration).
The main goal of the plug-in broker is to decouple the Che plug-ins definitions from the actual plug-ins that Che can support. With brokers, Che can support different plug-ins without updating the Che server.
The Che server starts the plug-in broker. The plug-in broker runs in the same Kubernetes namespace or OpenShift project as the workspace. It has access to the plug-ins and project persistent volumes.
A plug-ins broker is defined as a container image (for example, eclipse/che-plugin-broker
). The plug-in type determines the type of the broker that is started. Two types of plug-ins are supported: Che Plugin
and Che Editor
.
Source code |
|
Container image |
|
Che workspace creation flow

The following is a Che workspace creation flow:
-
A user starts a Che workspace defined by:
-
An editor (the default is Che-Theia)
-
A list of plug-ins (for example, Java and Kubernetes or OpenShift tools)
-
A list of runtime applications
-
-
Che server retrieves the editor and plug-in metadata from the plug-in registry.
-
For every plug-in type, Che server starts a specific plug-in broker.
-
The Che plug-ins broker transforms the plug-in metadata into a Che Plugin definition. It executes the following steps:
-
Downloads a plug-in and extracts its content.
-
Processes the plug-in
meta.yaml
file and sends it back to Che server in the format of a Che Plugin.
-
-
Che server starts the editor and the plug-in sidecars.
-
The editor loads the plug-ins from the plug-in persistent volume.