Eclipse Che

What it is

Eclipse Che is a Kubernetes-native platform for running developer workspaces in containers instead of on local machines. You define a workspace in a devfile (YAML: runtime image, tools, commands, project sources) and Che schedules it as pods on a cluster. Developers get a browser-based IDE (Theia-derived, with VS Code compatibility layers) pointed at that running workspace. The pitch is reproducibility: the same devfile produces the same environment for every developer, every time, and "it works on my machine" stops being a valid excuse because there is no local machine involved.

Who builds it and why

Eclipse Che is an Eclipse Foundation project, but in practice it's driven primarily by Red Hat, which ships it as the upstream for OpenShift Dev Spaces (formerly CodeReady Workspaces). That relationship explains most of the design decisions — deep OpenShift/Kubernetes integration, devfile as a first-class spec, and enterprise concerns like SSO and multi-tenant workspace isolation baked in early rather than bolted on. 216 contributors is a healthy number for a project this specialized, and it signals a real ecosystem, not a single-vendor side project, even though Red Hat's commercial interest is the obvious center of gravity.

Production readiness signal

Active commit history through mid-2026 and a release number at 7.119.0 indicate a long, continuously maintained release cadence rather than sporadic big-bang updates — that's a good sign for anyone worried about abandonment. 7,152 GitHub stars is modest compared to adjacent cloud-IDE tools, which tells you adoption is concentrated (largely OpenShift shops) rather than broad-based across the general Kubernetes community. CNCF maturity status is not publicly available — Che is not tracked through the CNCF maturity levels the way many projects in this landscape category are, so you can't lean on that signal for a go/no-go decision. Treat it as a Red-Hat-backed project with a stable release train, not as a CNCF-vetted graduate.

Who should use this

Teams already running OpenShift or a Kubernetes cluster with spare capacity, who want centrally-defined, versioned dev environments instead of per-developer local setup drift. Organizations standardizing onboarding across large or distributed engineering teams, where "clone repo, get identical environment in under a minute" has real ROI. Shops already committed to Red Hat's stack that want the option to run the free upstream before (or instead of) paying for Dev Spaces support.

Who should NOT use this

Small teams or startups without an existing cluster — the operational overhead of running Che (ingress, storage classes, RBAC, workspace lifecycle management) is not worth it for a handful of developers; a hosted option is cheaper in engineer-time. Solo developers or open-source contributors — this is infrastructure for organizations, not individuals. Teams that just want a fast, disposable cloud IDE with minimal ops — Gitpod or GitHub Codespaces get you there with far less cluster babysitting. GPU-heavy ML workflows — Che's workspace model isn't optimized for that, and you'll fight the platform more than it helps you. If you're not on Kubernetes already and have no plan to be, this is the wrong starting point entirely — you'd be adopting a cluster just to run an IDE.

Alternatives

• Gitpod — hosted or self-hosted ephemeral cloud dev environments, less Kubernetes-cluster-operations overhead, faster to adopt for smaller teams.
• GitHub Codespaces — fully managed, zero infrastructure to run yourself, tightly integrated with GitHub, but less control over the underlying platform and higher marginal cost at scale.
• Coder — similar devfile-adjacent, Kubernetes-friendly self-hosted workspace model, with a smaller footprint and less Red-Hat-specific tooling baked in.

Pricing

Fully open source under EPL-2.0. Self-host it yourself at no licensing cost — you pay only for the cluster it runs on. Red Hat sells a supported, packaged version (OpenShift Dev Spaces) if you want vendor support and SLA