Eclipse Che: Kubernetes-Native Cloud Development Environments for Enterprise Teams

The problem Eclipse Che targets: environments that live in the repository

The README states the project's purpose plainly: it is a "Platform for providing Kubernetes-based Cloud Development Environments for Enterprise Teams". The problem it addresses is the gap between a developer's laptop and the cluster the code actually runs on. Dependencies, runtimes, the editor and the source all get placed into containers in Kubernetes pods, and the README describes the result as workspaces that are "distributed, collaborative, and portable to run anywhere Kubernetes runs".

That framing tells you who the intended buyer is. This is not a tool for one person who wants a browser IDE. It is for an organization that already operates Kubernetes and wants development environments to be defined once and handed out many times. The unit of definition is the devfile, a YAML file committed to the repository root, which means the environment travels with the branch rather than living in a wiki page or a colleague's shell history.

The trade-off is visible before you install anything. A laptop-based setup needs no cluster. Che needs one, plus an operator, plus the willingness to treat workspace provisioning as a platform responsibility. Teams that cannot staff that responsibility will find the platform heavier than the problem it solves.

How a devfile becomes a running workspace

The mechanism is straightforward once you see the pieces. A repository carries a devfile.yaml at its root. The README gives this example of what one looks like:

schemaVersion: 2.3.0
metadata:
  name: my-project
components:
  - name: devtools
    container:
      image: quay.io/devfile/universal-developer-image:ubi9-latest
      memoryLimit: 4G
      mountSources: true
commands:
  - id: build
    exec:
      commandLine: 'mvn clean install'
      component: devtools

The components block names a container image and a memory limit, and sets mountSources so the project code is mounted into that container. The commands block binds a named command to a component, so "build" means running mvn clean install inside the devtools container. According to the README, "When a devfile.yaml is present, Che automatically configures the workspace with the specified tools, runtimes, and commands."

On the cluster side, the administrative surface is the CheCluster Kubernetes Custom Resource. The README points to its field reference and to the CRD documentation, which means an installation is configured by editing a custom resource rather than by hand-editing deployments. There is also an embedded Open VSX extensions registry that administrators can add to or trim, and the README links to instructions for automating VS Code extension installation at workspace startup. The data flow, in short: devfile in Git, CheCluster on the cluster, containers in pods.

Installing Eclipse Che on your own Kubernetes cluster

The README does not reproduce installation steps. It points to two destinations: a hosted option at eclipse.dev/che/getting-started/cloud/ for using Che online, and an administration guide page titled "preparing the installation" for running Che on your own Kubernetes cluster. Treat those as the authoritative sources; the commands below are the ones the README itself shows for workspace operations once an instance exists.

Workspace creation and lifecycle are handled by chectl, a separate CLI hosted in the che-incubator organization. The README gives these invocations:

# Start a workspace from a devfile
chectl workspace:start -f devfile.yaml

# Start a workspace from a remote devfile
chectl workspace:start -f https://raw.githubusercontent.com/eclipse/che/main/.devfile.yaml

# List running workspaces
chectl workspace:list

# Stop a running workspace
chectl workspace:stop <workspace-id>

After chectl workspace:start, the expected outcome is a workspace bound to the devfile you passed, and chectl workspace:list should show it as running. If you prefer not to use the CLI, the README documents factory URLs: navigating to your Che instance with the repository appended after a hash opens that repository as a workspace. The pattern is https://<your-che-host>/#https://github.com/<owner>/<repo>, and the README uses the Che repository itself as the example. A useful first exercise is to fork a small repository, add a devfile.yaml with one container component and one build command, and open it through a factory URL to confirm that the cluster, the registry and the devfile all agree.

Where Eclipse Che is the wrong tool

The clearest limitation is the entry requirement. Che is Kubernetes-native by design, and the README's installation path assumes a cluster you control. A solo developer or a two-person team without a cluster gets nothing from the architecture; the devfile format is portable, but the platform that consumes it is not free to run.

A second boundary is operational. The configuration surface is the CheCluster custom resource, and the README links to a full field reference rather than a short list. That implies a meaningful number of knobs and, by extension, a meaningful amount of reading before a production rollout. The embedded extensions registry is another piece administrators are expected to curate: the README links to instructions for adding or removing extensions in the embedded Open VSX instance, which is a task that does not exist in a desktop IDE.

The README does not document rollback or downgrade procedures, and it does not describe what happens to running workspaces during an upgrade. That silence is worth noting rather than filling in. Any team that needs a documented, tested rollback story should confirm it against the administration guide before treating Che as production infrastructure.

Eclipse Che compared with VS Code and Theia-based setups

The comparison people actually search for is Che against VS Code, and the difference is architectural rather than cosmetic. VS Code runs on the developer's machine, and a remote development extension lets that local editor attach to a remote host. The environment definition, in that model, is largely the developer's own configuration. Che inverts it: the workspace is a set of containers in Kubernetes pods, and the definition is a devfile.yaml committed alongside the code, so every developer who opens the repository gets the same tools, the same memory limit and the same build command.

Eclipse Theia is a related but distinct subject. Theia is an editor framework that can be embedded in a platform; Che is the platform that provisions environments and can host an editor inside them. The README's own links make this concrete: it documents how to automate installation of Microsoft Visual Studio Code extensions at workspace startup and how to customize the embedded Open VSX registry, which is administration work that belongs to the platform, not to the editor.

The practical difference for a platform team is where control lives. With a desktop editor, control sits with each developer and drift is normal. With Che, control sits in the devfile and the CheCluster resource, and drift becomes a configuration bug you can fix once.

Maintenance, releases and the EPL-2.0 licence

The repository is not archived, and the last push was on 2026-09-21, so the project is being worked on now. Releases follow a monthly cadence in the recent record: 7.120.0 on 2026-07-07, 7.121.0 on 2026-08-07, and 7.122.0 on 2026-09-09. That rhythm matters for planning, because it means upgrade decisions arrive roughly every month rather than once a year, and a team that pins a version is choosing to fall behind on a short clock.

The licence is Eclipse Public License 2.0, stated in the README and present as the LICENSE file at the repository root. EPL-2.0 is a weak-copyleft licence with a patent grant, and it is generally considered friendly to commercial use, but the obligations attach to distribution of the covered code and to modifications of it. This article is not legal advice: if you plan to redistribute Che or a modified build inside a product, have counsel read the licence text rather than this paragraph.

The upgrade cost is not only the version bump. Because configuration lives in the CheCluster custom resource and in devfiles, a release can change which fields exist or how they behave, and the README directs administrators to the CheCluster field reference for exactly that reason. Budget time for reading the release notes and the field reference each cycle, not just for running the update.

Editorial conclusion

Adopt Eclipse Che if you run Kubernetes and need many developers to get identical, reproducible environments from a devfile.yaml that lives in each repository, with the CheCluster custom resource as the single configuration surface. Do not adopt it for a single developer or a small team that has no cluster to spare: the install path starts with a Kubernetes cluster and a chectl deployment, and the operational surface (operator, CheCluster fields, embedded VS Code extensions registry) is real work. Before committing, verify that your cluster meets the installation prerequisites in the administration guide, check whether the CheCluster fields you need exist in the version you plan to pin, and confirm that your team accepts EPL-2.0 terms for the deployment artifacts you distribute internally.

Frequently asked questions

Official sources

1. eclipse-che/che on GitHub
2. License: EPL-2.0
3. Project website
4. README
5. Releases