Eclipse Che

Open-source cloud development environments, honestly reviewed. If you’re a non-technical founder looking to escape a SaaS bill, read the TL;DR first — this tool may not be the category you’re looking for.

TL;DR

• What it is: Open-source (EPL-2.0) Kubernetes-native platform for running cloud development environments — containerized workspaces with your IDE, dependencies, and project code pre-configured and accessible from a browser [1].
• Who it’s for: Engineering teams at organizations already running Kubernetes or OpenShift who want consistent, reproducible dev environments and want to eliminate “it works on my machine” problems [1]. This is not a tool for non-technical founders — it’s a tool for their dev teams.
• Cost savings: Replaces paid hosted dev environments like GitHub Codespaces (billed per core-hour) or Gitpod Pro (~$23/user/month). A 10-person team on Gitpod Pro pays $230/month. With existing Kubernetes infrastructure, Che workloads cost roughly $100–200/month in additional cluster resources.
• Key strength: Every developer gets the exact same workspace, defined in a devfile checked into the repository. New-hire onboarding drops from days to minutes [1][homepage].
• Key weakness: Requires a functioning Kubernetes cluster and someone who can operate one. This is infrastructure work before it’s developer tooling. If your team has no Kubernetes experience, the overhead will cost more than any hosted alternative [1][2].

---

What is Eclipse Che

Eclipse Che is a cloud development environment platform. Instead of developers configuring local machines with project-specific dependencies, tools, and runtime versions, Che spins up containerized workspaces on Kubernetes. Each workspace is a Kubernetes pod running a full IDE — VS Code (via the open-source fork) or JetBrains IDEs via browser streaming — alongside the actual runtime your project requires. You open a browser, click a link, and you’re editing code in an environment that was fully configured before you arrived [1][homepage].

The pitch on the official homepage is unambiguous: “Run your favorite IDE on Kubernetes.” The GitHub repository description is “Kubernetes based Cloud Development Environments for Enterprise Teams” [README][homepage]. Both versions say the same thing: this is infrastructure for engineering teams, not a productivity tool for founders or marketers.

The project originated at Codenvy, which built early cloud IDE tooling and contributed the codebase to the Eclipse Foundation. Red Hat, which later acquired Codenvy, remains the primary contributor and ships Eclipse Che commercially as OpenShift Dev Spaces — the enterprise-supported build bundled with OpenShift subscriptions. The open-source project currently sits at 7,139 GitHub stars [merged profile].

The workspace definition format, called a devfile, is a YAML file that lives alongside your code in version control. It describes which container images to use, which IDE to load, which ports to expose, and which commands to register. Devfiles are a CNCF project, contributed by Red Hat, AWS, and JetBrains [homepage]. When a new developer joins your team, they click a Git repository URL in Che and the devfile does the rest.

One infrastructure detail worth understanding: Microsoft’s VS Code extension marketplace bars access from non-Microsoft products. So Eclipse Che runs its own extension registry — OpenVSX, an open-source alternative to the Visual Studio Marketplace, also hosted by the Eclipse Foundation [3]. Most mainstream VS Code extensions are published there by authors or mirrored from public sources, but the catalog is smaller than Microsoft’s marketplace.

---

Why people choose it

The consistent reason teams reach for Eclipse Che is “works on my machine” fatigue at the team level [1]. When you have 15 developers on a project requiring specific Java versions, database clients, container tools, and environment variables, maintaining consistency across 15 laptops is a losing battle. Che moves that problem into a devfile — one file, version-controlled, that defines the environment for everyone.

The AppMus analysis [1] identifies the specific pain points Che addresses:

Onboarding time. Traditional onboarding for a complex project can take multiple days: install the right tool versions, configure credentials, debug path conflicts, get the database seeded. With a working Che instance and a devfile in the repo, a new developer gets a browser link and a working environment in minutes [1][homepage].

Distributed teams. A developer in Berlin, one in Singapore, and one in São Paulo all get the same workspace. Performance isn’t tied to their laptop specs — it’s tied to the Kubernetes cluster [1].

CI/CD environment parity. Because the devfile uses the same container images that can describe a build environment, local development and CI pipelines share the same runtime. You test in the same environment you develop in [homepage][1].

The comparison with alternatives breaks down along infrastructure maturity:

Versus GitHub Codespaces. Codespaces is the lowest-friction path — hosted by GitHub, no infrastructure required, integrates directly with GitHub repos. You pay per core-hour. For occasional use that’s fine; for a full-time 10-person team it reaches $400–600/month fast. Eclipse Che self-hosted eliminates that per-hour billing at the cost of running your own Kubernetes cluster.

Versus Gitpod. Gitpod Cloud is simpler to get running than Che and doesn’t require Kubernetes knowledge to start. Gitpod Self-Hosted exists but the company has shifted heavily toward cloud-first. Che is the better option if you’re committed to running your own infrastructure long-term.

Versus Coder. Coder is Che’s closest direct competitor in the self-hosted enterprise space — both run on Kubernetes, both use template systems to define environments. Coder has a cleaner admin UI and less complex onboarding; Che has deeper Red Hat/OpenShift integration and a longer track record [1][2].

The cloud IDE comparison table from AppMus [2] shows a broader field — Eclipse Orion, Cloud9, Codeanywhere, Koding — but Eclipse Che stands apart from them by being genuinely Kubernetes-native rather than just browser-based. The others are web interfaces to a shared server; Che gives each developer isolated pods.

---

Features

Based on the README, homepage, and third-party reviews:

Workspace management:

• Browser-only access — no local installation required beyond a modern browser [homepage][1]
• Workspaces defined in devfiles, version-controlled alongside project code [homepage][README]
• Start a workspace from any Git repository URL — Che reads the devfile automatically [README]
• Switch between projects or branches by opening a new browser tab, not by reconfiguring a machine [homepage]
• Universal Developer Image (UDI) — a pre-built container with common dev tools for projects without a custom devfile [README]

IDE support:

• VS Code Open Source (Che-Code) — same editor engine, without Microsoft telemetry [homepage]
• JetBrains IDEs via browser streaming — IntelliJ IDEA, PyCharm, GoLand, and others [homepage]
• Swap IDEs without changing the workspace — the devfile specifies which to run [homepage]

Extensions and plugins:

• Embedded OpenVSX registry — open-source VS Code extension marketplace [3]
• Operators can add or remove extensions from the embedded registry [README]
• Auto-install extensions at workspace startup via devfile configuration [README]

Team and enterprise:

• CheCluster Kubernetes Custom Resource — configure the entire Che installation declaratively via YAML [README]
• RBAC via native Kubernetes mechanisms
• Real-time collaboration — multiple developers in the same workspace, shared terminal and editor [1]
• Automated Git setup — SSH keys and credentials configured automatically at workspace launch [homepage]
• Access to the Kubernetes API from inside the IDE — develop and test against the same cluster [homepage]
• OpenShift-native deployment path (Red Hat ships this as OpenShift Dev Spaces) [README][5]

---

Pricing: SaaS vs self-hosted math

Eclipse Che is open-source under EPL-2.0 — no software license fee. What you’re paying for is infrastructure.

Eclipse Che self-hosted:

• Software: $0 [merged profile]
• Infrastructure: a running Kubernetes cluster. Minimal evaluation setup on Hetzner or DigitalOcean runs $20–50/month. A production cluster supporting 10+ concurrent developer workspaces with adequate CPU and RAM runs $150–400/month depending on specs and provider.
• Admin time: the real cost. Someone with Kubernetes expertise needs to set this up and maintain it. Initial installation for a Kubernetes-experienced team: 4–8 hours. Ongoing maintenance: a few hours monthly.

Red Hat OpenShift Dev Spaces (commercial Che):

• Bundled with Red Hat OpenShift subscriptions. If your organization already pays for OpenShift, Dev Spaces is included. Pricing not publicly listed — enterprise sales. If you’re already an OpenShift customer, this is the obvious path.

GitHub Codespaces (comparison):

• Free: 60 core-hours/month per account
• Paid: $0.18/core-hour (2-core) to $0.72/core-hour (8-core)
• A developer on a 4-core instance working 8 hours/day, 22 days/month: $0.36/hr × 176hr = ~$63/month per developer
• 10-person team: ~$630/month

Gitpod Pro (comparison):

• $23/user/month cloud-hosted
• 10-person team: $230/month

The self-hosted Che math: If you have 10 developers and a Kubernetes cluster already running for your application, adding Che workloads might cost an additional $100–200/month in cluster resources. Against $230–630/month for hosted alternatives, the payback is fast — assuming you already have the infrastructure.

If you don’t have Kubernetes, factor in setup labor. A production Kubernetes deployment for Che from scratch takes 1–3 days of a DevOps engineer’s time, plus ongoing maintenance. At market rates, that’s $2,000–6,000 upfront. Against $230/month savings versus Gitpod Pro, break-even takes 9–26 months. The economics work for teams planning to run Kubernetes regardless; they don’t work as a standalone purchase just to save on dev environment costs.

Data not available: no independent cost breakdown from third-party reviews exists in the source material.

---

Deployment reality check

This section matters more for Eclipse Che than for most tools reviewed here, because the deployment complexity is genuine and well-documented in the sources.

Prerequisites before you start:

• A running Kubernetes cluster (minikube works for evaluation; production requires proper sizing) [README]
• kubectl and the chectl CLI installed
• A domain name and TLS certificate for the Che ingress
• Persistent storage configured (PVCs for workspace data)
• An identity provider — Keycloak ships bundled, or configure an external one

What actually goes sideways:

• Network configuration. Each workspace gets its own ingress rules. If your cluster’s ingress controller is nonstandard or behind a corporate proxy, expect debugging [1].
• Resource sizing. Underpowering is the most common failure mode. Each concurrent developer workspace needs dedicated CPU and RAM — the Universal Developer Image alone can pull 1–2GB. A cluster sized for your app may not have headroom for 10 developer workspaces [1].
• JetBrains in-browser performance. Running IntelliJ via browser streaming works, but it’s noticeably slower than native. The streaming approach adds latency for CPU-intensive operations. Not a dealbreaker for routine coding, but real for large refactors or heavy compile operations [homepage].
• OpenVSX extension gaps. Popular extensions are covered. Niche or proprietary extensions often aren’t. Verify your team’s critical extensions are in OpenVSX before committing to the platform [3].
• Developer resistance. Team members used to local IDEs with years of custom configuration may resist the transition [1][2]. This is a cultural change as much as a technical one.

Realistic time estimate for a Kubernetes-experienced team: 4–8 hours to a working installation. For a team learning Kubernetes alongside Che: significantly longer. For a team with no Kubernetes experience: start with Gitpod or Codespaces, gain Kubernetes experience separately, then revisit.

---

Pros and Cons

Pros

• Reproducible environments. Devfiles eliminate “works on my machine” across the team — everyone gets the same workspace, every time [1].
• Fast onboarding. A new developer gets a link, opens a browser, and has a working environment in minutes rather than days [1][homepage].
• Browser-only access. Developers work from any machine — thin clients, locked-down corporate laptops, a tablet. No local admin rights needed [1][homepage].
• Real-time collaboration. Multiple developers can share a workspace: pair programming, joint debugging, shared terminal [1].
• VS Code and JetBrains both supported. Most open-source cloud IDEs pick one IDE ecosystem; Che covers both [homepage].
• Kubernetes API access from the IDE. Develop and test against the same cluster you deploy to [homepage].
• EPL-2.0 license. Permissive for most commercial uses. Free to use, modify, and deploy without a commercial agreement [merged profile].
• Red Hat maintenance. Active upstream contributor with commercial incentive to keep the project healthy [README][5].

Cons

• Infrastructure prerequisite is a hard gate. You must have a functioning Kubernetes cluster and someone to operate it before Che delivers any value. This isn’t reducible complexity [1][2].
• JetBrains performance in browser. The streaming approach is functional but adds latency. Acceptable for most work, noticeable for heavy operations [homepage].
• Not accessible to non-technical users. DevOps expertise is required to set up and maintain Che. Devfiles require container literacy. There is no consumer-grade install path [1][2].
• 7,139 GitHub stars is modest for a tool in this category. Gitpod and GitHub Codespaces have substantially more community adoption, which means fewer devfile examples in the wild, fewer community guides, and thinner Stack Overflow coverage [merged profile].
• Effective Red Hat control. The project roadmap follows Red Hat’s priorities. Good if you’re an OpenShift customer; riskier if you’re not [README][5].
• OpenVSX extension catalog is smaller than Microsoft’s marketplace. Niche or proprietary extensions require workarounds [3].
• Independent review ecosystem is thin. The material available from third-party reviewers is limited. Most authoritative documentation comes from Eclipse Foundation itself, not independent users [1][2].

---

Who should use this / who shouldn’t

Use Eclipse Che if:

• You’re running Kubernetes or OpenShift and have engineering capacity to operate it.
• Your organization is already a Red Hat customer — OpenShift Dev Spaces makes Che significantly easier.
• You have 5+ developers and you’re paying for GitHub Codespaces or Gitpod at a scale where the monthly cost is noticeable.
• You need verifiable environment reproducibility — regulated industries, security-sensitive work, or teams where environment drift causes frequent bugs.
• Your developers work from diverse or locked-down machines and you need a consistent baseline that doesn’t depend on their local setup.

Skip it if:

• You don’t have Kubernetes infrastructure and the team to run it. The tool is inseparable from Kubernetes.
• You’re a solo developer or very small team. The operational overhead doesn’t pay off.
• You’re a non-technical founder. This is a tool for your engineering team, not something you’ll use directly.
• You want something running this afternoon. Budget a week if Kubernetes is new to your organization.

Use GitHub Codespaces instead if:

• Your code lives on GitHub, your team is small to medium, and you want cloud dev environments without infrastructure overhead.

Use Gitpod instead if:

• You want the workspace-from-URL concept without the Kubernetes admin burden. Gitpod Cloud removes the infrastructure layer entirely.

Use Coder instead if:

• You want self-hosted cloud dev environments with a more polished admin UI and no OpenShift dependency.

Use DevPod instead if:

• You want devfile-based environments without a full Kubernetes cluster — DevPod can provision local or cloud environments with substantially less infrastructure.

---

Alternatives worth considering

• GitHub Codespaces — easiest entry to cloud dev environments if code is already on GitHub. No infrastructure required, pay per core-hour. Expensive at scale.
• Gitpod — similar concept (workspace-from-URL, devfiles), better UX for teams without Kubernetes experience. Cloud-hosted primarily; self-hosted option scaled back.
• Coder — closest direct competitor for self-hosted enterprise cloud IDEs. Kubernetes-native, cleaner admin experience, less Red Hat-specific.
• DevPod — newer open-source option that provisions dev environments from devfiles without requiring a full Kubernetes installation. Lower barrier to entry.
• JetBrains Space — JetBrains’ own hosted dev environment platform. Commercial, tightly integrated with JetBrains tooling.
• Eclipse Theia — the underlying IDE framework Che is built on. If you want to build a custom cloud IDE rather than deploy a pre-built platform, Theia is the building block [README].

---

Bottom line

Eclipse Che solves a real problem well: consistent, reproducible development environments for engineering teams on Kubernetes. The devfile approach is genuinely good — define your environment once, version it with code, and every developer and CI job uses the same runtime. Red Hat’s active involvement means the project isn’t going anywhere, and EPL-2.0 is clean for commercial use. But the deployment story requires Kubernetes and someone to operate it — there’s no shortcut around that prerequisite. If your organization runs Kubernetes already, Che deserves a serious look against Gitpod and Coder; the self-hosted cost math works clearly in your favor at 5+ developers. If you’re coming to this review as a non-technical founder looking to cut a monthly bill, this isn’t the right category — the infrastructure complexity requires an engineering investment that only makes sense if Kubernetes is already part of your stack.

---

Sources

1. AppMus — Eclipse Che: Features, Alternatives & Analysis (2026). https://appmus.com/software/eclipse-che
2. AppMus — Eclipse Orion vs Eclipse Che Comparison (2026). https://appmus.com/vs/eclipse-orion-vs-eclipse-che
3. Eclipse Foundation — Eclipse Open VSX Creation Review (December 2019). https://projects.eclipse.org/projects/ecd.openvsx/reviews/creation-review
4. Eclipse Foundation — 2015 Annual Community Report. https://www.eclipse.org/org/foundation/annual-reports/2015/
5. Eclipse Foundation — 2017 Annual Community Report. https://www.eclipse.org/org/foundation/annual-reports/2017/

Primary sources:

• GitHub repository: https://github.com/eclipse-che/che (7,139 stars, EPL-2.0 license)
• Official website: https://eclipse.dev/che/
• Documentation: https://eclipse.dev/che/docs