Eclipse Che
Eclipse Che is an open-source, Kubernetes-native integrated development environment (IDE) and developer collaboration platform that provides container-based workspaces for cloud-native development.[1] It enables developers to create replicable, multi-container environments running on Kubernetes or OpenShift clusters, eliminating local setup inconsistencies and accelerating project onboarding.[1] Launched as an Eclipse Foundation project in March 2016, Eclipse Che integrates browser-based IDEs such as Visual Studio Code and JetBrains IntelliJ IDEA, supporting protocols like the Language Server Protocol (LSP) and Debug Adapter Protocol (DAP) for enhanced coding efficiency.[2][1] The platform's architecture centers on a centralized Che server that manages user workspaces as Kubernetes Pods, each containing embedded IDEs, runtimes, and tools tailored to specific languages or stacks.[3] Key contributors to its development include Codenvy, Microsoft, Red Hat, and SAP, fostering a community-driven evolution focused on enterprise needs like secure authentication via OpenID Connect (OIDC) and role-based access control (RBAC).[2][1] Eclipse Che supports pre-built devfiles for quick starts with popular frameworks and allows custom extensions through VS Code compatibility, making it suitable for collaborative, zero-install development in distributed teams.[1] Its integration with tools like Prometheus for monitoring and Grafana for visualization further enhances operational reliability in production environments.[1]History and Development
Origins and Early Development
The concept for Eclipse Che originated in early 2009 when the eXo Platform team began developing a prototype for a cloud-based integrated development environment (IDE) to enhance their enterprise social platform.[4] This initiative was led by developer Gennady Azarenkov, who was tasked with creating a web-based IDE that could dynamically extend the eXo Platform using REST APIs and OpenSocial Gadgets, allowing users to build custom features without constraints from predefined APIs.[4] The prototype aimed to test multi-tenant, elastic scaling in a public cloud, evolving into a next-generation Java IDE with capabilities like remote debugging and code auto-completion.[4] By 2013, the eXo Cloud IDE had matured sufficiently to spin off as an independent company named Codenvy, formerly known as eXo IDE, which secured $9 million in Series A funding to accelerate development.[5] On October 27, 2014, Codenvy announced Eclipse Che as an open-source project under the Eclipse Foundation's Cloud Development initiative, donating the core intellectual property including the Codenvy SDK, IDE, and over 50 plugins.[6] This marked the formal launch of Che as a extensible platform for cloud-native developer workspaces.[7] Eclipse Che's early development addressed key limitations of traditional IDEs, such as the Eclipse IDE itself, by providing browser-accessible, multi-user environments that eliminated local installations and enabled seamless collaboration across distributed teams.[6] The project sought to unify disparate desktop and cloud tools into an integrated ecosystem for agile development, including build systems, continuous integration, and debugging.[6] Key contributors included the original eXo team and Codenvy developers primarily based in Cherkasy, Ukraine— the city's name even inspired the project's moniker—where the bulk of the initial coding occurred.[8] This groundwork laid the foundation for Che's donation to the Eclipse Foundation in 2014.[6]Key Releases and Milestones
Eclipse Che was donated to the Eclipse Foundation by Codenvy, with the project officially announced and entering incubation on March 8, 2016.[9] The initial stable release, version 4.0, arrived on March 29, 2016, introducing portable developer workspaces and advanced Java support within a cloud IDE framework.[10] This marked the transition from Codenvy's proprietary development to a community-driven open-source effort under Eclipse governance. In 2017, Red Hat acquired Codenvy, accelerating contributions to Eclipse Che and integrating it deeper into containerized ecosystems.[11] Other key contributors included IBM, Microsoft, and Docker, which joined the project in 2016 to enhance container integration and cloud-native capabilities.[9] These corporate involvements drove rapid evolution, focusing on scalability and interoperability. A significant licensing update occurred with version 6.9.0, released on August 1, 2018, shifting from EPL-1.0 to EPL-2.0 to align with modern open-source practices and improve compatibility.[12] The major milestone of Che 7 followed in September 2019, establishing it as the first Kubernetes-native IDE with built-in support for deploying on Kubernetes clusters and seamless integration with OpenShift for enterprise workflows.[13] The latest stable release, 7.112.0, was issued on November 17, 2025, featuring enhanced compatibility with Visual Studio Code Open Source (version 1.103.2) and support for Java 17 from the prior release, alongside improvements in workspace management, container nesting, automatic import of TLS certificates to the Java trust store, and an update to the DevWorkspace Operator to version 0.38.0. This update underscores ongoing advancements in cloud-native development tools.[14]Licensing and Naming
Eclipse Che was initially released under the Eclipse Public License (EPL) version 1.0, which governed the project up to and including version 6.8.0.[15] Starting with version 6.9.0, the project migrated to EPL 2.0 to align with evolving open-source practices, offering enhanced compatibility with other licenses such as the GNU General Public License (GPL) and explicit grants of patent rights to contributors and users.[16][17] The EPL is a weak copyleft license designed to promote collaborative development while accommodating commercial applications. It permits the use, reproduction, modification, and distribution of the software for both open-source and proprietary purposes, provided that any distributed modifications include the source code under the same license terms.[18] This structure facilitates integration into commercial products without imposing full reciprocity on non-modified portions, making it suitable for enterprise adoption while ensuring community access to improvements.[18] The project's name, "Che," originates from Cherkasy, Ukraine, the city where a significant portion of the initial development was conducted by the Codenvy team, the primary contributors at the time.[19] This etymology reflects the geographical roots of the technology, which began as an open-source donation to the Eclipse Foundation in 2014.Technical Foundations
Core Architecture
Eclipse Che employs a Kubernetes-native architecture, leveraging the platform's orchestration capabilities to manage developer workspaces as isolated, multi-container Pods. These Pods replicate production-like runtimes augmented with a "developer mode" layer that includes IDE tools and extensions, ensuring scalability and resource isolation across users. The system runs on Kubernetes or OpenShift clusters, where each workspace is provisioned within a dedicated namespace to support multi-tenancy and secure, collaborative development environments.[1][20] At the heart of this architecture is the Che Server, a Java-based web service that functions as a multi-user remote development server, exposing HTTP RESTful APIs for workspace lifecycle management, including creation, starting, stopping, and deletion. These APIs integrate with external services such as Git providers and the Kubernetes API, enabling programmatic control and automation of development environments. The server acts as a gateway, handling authentication via OpenID Connect (OIDC) and provisioning Kubernetes resources on behalf of users.[21][20] Workspaces in Eclipse Che are standardized and replicable through the Devfile format, a YAML-based specification that defines components like containers, projects, commands, and dependencies, allowing consistent reproduction across teams and environments. The browser-based IDE—such as Eclipse Theia or the VS Code web version—is embedded within the workspace Pod, providing a seamless, plugin-compatible interface that runs directly in the containerized runtime without requiring local installations.[1][20] The architecture enforces a clear separation of concerns: the workspace server and DevWorkspace Operator handle orchestration tasks like resource provisioning, scaling, and lifecycle management via Kubernetes Custom Resources, while individual workspace machines—executed as containers within Pods—focus solely on running development tools, languages, and application code in isolation. This decoupling enhances modularity, fault tolerance, and ease of extension, with asynchronous communication facilitated through ConfigMaps and Secrets.[20][21]Technological Stack
Eclipse Che's backend is implemented using Java SE with JAX-RS for REST APIs and Guice for dependency injection, running on an embedded Apache Tomcat server to handle API requests and workspace management. The Che Server component, which acts as the central gateway for operations like namespace provisioning and devfile retrieval, runs as a Java application within this environment.[22][23] The frontend of Eclipse Che traditionally utilized Google Web Toolkit (GWT) for building the web-based IDE interface, enabling cross-browser JavaScript compilation from Java code, though recent versions integrate Eclipse Theia—a TypeScript-based framework compatible with Visual Studio Code extensions—for enhanced editor capabilities.[24] This shift supports browser-based development with features like terminal access and version control integration directly in Kubernetes-hosted workspaces.[25] Containerization in Eclipse Che relies on Docker to package workspace machines, encapsulating dependencies, runtimes, and tools into isolated environments that developers can customize via devfiles.[26] For orchestration, Eclipse Che deploys these Docker containers as Kubernetes pods, with support for OpenShift as an enterprise Kubernetes distribution, enabling scalable, multi-tenant workspace provisioning.[25] Kubernetes pods are used to manage workspace resources, including services, ingresses, and persistent volumes for stateful components.[27] Eclipse Che incorporates standard protocols for developer tooling, including the Language Server Protocol (LSP) to provide editor intelligence such as code completion, diagnostics, and hover information across supported languages.[25] Similarly, the Debug Adapter Protocol (DAP) facilitates debugging by standardizing communication between the IDE and debuggers, allowing breakpoint management and variable inspection in cloud workspaces.[25] For monitoring, Eclipse Che integrates with Prometheus to collect and store metrics from workspace components and the Che Server, exposing JVM and pod-level data via endpoints like port 8087.[28] Grafana complements this by providing dashboards for visualizing these metrics, such as uptime and resource usage, configurable through Kubernetes ServiceMonitors and ConfigMaps in OpenShift environments.[28]Supported Technologies
Languages and Frameworks
Eclipse Che provides native support for several programming languages through pre-built Devfile stacks, including Java, JavaScript, TypeScript, Python, Go, PHP, Ruby, C/C++, C#, F#, and SQL. These stacks are designed to deliver ready-to-use environments with language-specific runtimes, compilers, debuggers, and initial tooling, streamlining the setup for developers working in these technologies.[1][29] Specific examples illustrate this support: Java stacks integrate build tools like Maven and Gradle for project management and dependency resolution, enabling seamless compilation and execution of Java applications.[30] The Node.js stack caters to JavaScript and TypeScript development with npm for package handling, while Python stacks incorporate pip environments for efficient library installation and virtual environment management. The platform places particular emphasis on cloud-native frameworks to facilitate modern application development. For instance, Spring Boot and Quarkus stacks build on Java support to provide lightweight, container-optimized environments for microservices, and React stacks leverage Node.js for building dynamic user interfaces. Beyond pre-built options, Eclipse Che's extensibility allows adaptation to any language or framework using custom Docker images and Devfiles, promoting polyglot development where multiple technologies coexist in a single workspace.Plugins and Integrations
Eclipse Che's plugin ecosystem is built around compatibility with Visual Studio Code (VS Code) extensions, enabling users to leverage thousands of extensions from the Open VSX registry to customize their development environments with features such as themes, linters, debuggers, and specialized tools.[31] These extensions are managed through the Che plugin registry, which lists available editors and extensions in Devfile v2 format, allowing administrators to curate and deploy a subset via embedded registries or public instances for air-gapped setups.[32] This compatibility extends the default Eclipse Theia IDE, providing flexibility without requiring custom development for common functionalities. For enterprise integrations, Eclipse Che supports authentication via OpenShift OAuth or Dex, facilitating secure, multi-tenant access and role-based control in Kubernetes and OpenShift environments.[1] It also integrates with Git providers including GitHub, GitLab, Bitbucket, and Microsoft Azure Repos through OAuth applications configured by administrators, enabling seamless repository cloning, syncing, and version control operations directly within workspaces.[33] Eclipse Che connects to CI/CD pipelines via tools like Jenkins and Tekton, allowing workspaces to trigger builds, tests, and deployments as part of broader DevOps workflows on Kubernetes platforms.[34] Monitoring integrations include Prometheus for metrics collection and Grafana for visualization, providing administrators with insights into workspace resource usage and performance.[1] Beyond the default Theia editor, custom editors such as full VS Code instances are supported through projects like che-code, offering alternative IDE experiences within Che workspaces.[35] Plugin development for Eclipse Che-specific extensions utilizes an SDK that supports creation of custom tools, with earlier implementations leveraging Java and GWT for client-side components, though contemporary extensions primarily align with the VS Code extension model for broader compatibility.[36]Key Features
Workspace Management
Eclipse Che utilizes the Devfile format, a YAML-based specification, to define and configure developer workspaces in a declarative manner. This format enables users to specify essential components such as container images, tools, plugins, and runtime environments, along with commands for building, running, and testing applications.[37] By encapsulating these elements in a single file, the Devfile ensures that workspaces can be consistently reproduced and shared across development teams without manual reconfiguration.[37] For streamlined workspace instantiation, Eclipse Che supports Factory URLs, which allow one-click creation of environments directly from Git repositories or predefined templates. A typical Factory URL follows the structurehttps://<che-hostname>#<git-repository-url>, where the Git URL points to a repository containing a Devfile or project files; upon access, Che automatically clones the repository's default branch and launches a fully configured workspace with the integrated development environment (IDE).[38] This mechanism supports various Git providers like GitHub, GitLab, and Bitbucket, facilitating rapid onboarding and replication of project setups from remote sources.[38]
Workspaces in Eclipse Che are architected as multi-container Kubernetes pods, promoting isolation and modularity. Each workspace typically includes a dedicated editor container hosting the browser-based IDE (such as Theia or VS Code), a runtime container for executing the application in a production-like environment, and additional containers for dependencies like language servers, debuggers, and build tools.[39] This separation ensures that changes in one container do not affect others, while allowing seamless integration of specialized services required for development tasks.[1]
Portability is a core aspect of Eclipse Che workspaces, achieved through the standardized Devfile format that abstracts configurations into portable YAML definitions usable across different Kubernetes clusters.[40] Workspaces can be replicated by sharing the Devfile, enabling consistent environments regardless of the underlying infrastructure.[39] For backups and state preservation, Eclipse Che leverages Kubernetes Persistent Volumes (PVs) to store source code and user data, such as the /home/[user](/page/User) directory, ensuring persistence across workspace restarts or migrations.[39] Administrators can request additional persistent storage via Devfile attributes to mount volumes for critical data, providing a form of snapshot-like reliability without full image captures.[41]
Development Tools and Collaboration
Eclipse Che integrates a robust set of development tools directly into its browser-based IDE, powered by Eclipse Theia, to support efficient coding and debugging workflows. The built-in debugger utilizes the Debug Adapter Protocol (DAP), enabling developers to attach to running processes, set breakpoints, examine call stacks, and evaluate expressions across multiple programming languages through extensible debug adapters that run in containerized environments. This protocol abstracts the communication between the IDE frontend and backend debuggers, ensuring compatibility with tools like GDB for C/C++ or the Java Debug Wire Protocol for JVM-based applications. Complementing this, Git visualization tools provide a graphical representation of repository history, including branch topologies, commit diffs, and change sets, while branching features allow seamless operations such as creating, switching, merging, and resetting branches via an intuitive menu interface. These capabilities streamline version control without requiring external clients, as all Git interactions occur within the isolated workspace runtime.[42] Collaboration in Eclipse Che is designed for distributed teams, featuring workspace sharing where multiple developers can access the same environment, with changes visible upon refresh or session updates. Shared terminals enable collaborative command-line interactions, allowing team members to execute builds, run tests, or troubleshoot issues in a single environment. Access to these shared resources is governed by role-based access control (RBAC), which defines granular permissions such as read-only viewing, editing, or administrative control, integrated with identity providers like OpenID Connect for secure authentication.[1] This setup supports pair programming and code reviews by limiting interference and enforcing organizational policies on workspace sharing.[39] The browser-based IDE enhances productivity with Language Server Protocol (LSP) support for IntelliSense-like features, including autocompletion, error diagnostics, refactoring, and hover documentation tailored to specific languages. Developers access an integrated terminal for shell commands and a command palette for executing build and run tasks, all without leaving the web interface. These tools operate within fully isolated Kubernetes-based environments, where each workspace runs in dedicated containers to prevent resource contention or security breaches between users, ensuring that debugging sessions or collaborative edits do not affect unrelated projects.[43]Deployment and Scaling
Installation Options
Eclipse Che offers several installation options tailored to different environments, from local development setups to enterprise-scale deployments on cloud infrastructure. The primary method for self-hosting involves deploying on a Kubernetes cluster, which supports both public and private configurations.[44] Self-hosted installations on Kubernetes clusters can be accomplished using the Eclipse Che Operator or Helm charts. The Operator, built with Operator SDK, automates the creation and management of Kubernetes resources such as pods, services, and persistent volumes required for a Che instance, ensuring one instance per cluster.[45] Alternatively, Helm charts provide a declarative approach to deploy the Eclipse Che server, plugin registry, and devfile registry, with prerequisites including Kubernetes 1.21 or later and Helm 3.2.2 or later.[46] For local testing and quickstarts, Minikube is recommended to simulate a single-node Kubernetes cluster, allowing developers to evaluate Che without a full production environment.[47] System requirements for Eclipse Che emphasize sufficient cluster resources to handle workspaces and server components. A minimum of Kubernetes 1.21 is required, though later versions are supported.[48] Each workspace typically demands around 8 GB of RAM and 5000 millicores of CPU, including allocations for components like the VS Code editor (1 GB RAM, 500 millicores) and gateway services (256 MiB RAM, 500 millicores); server-side elements add approximately 13 GiB RAM and 8.4 CPU cores across the Che server and controllers.[49] These figures establish baseline capacity, with actual needs varying by devfile configurations and concurrent users. As of November 2025, Eclipse Che 7.112.0 supports deployment on OpenShift Container Platform 4.18 or later.[12][48] For managed services, Red Hat OpenShift Dev Spaces provides a hosted Eclipse Che-based environment integrated with OpenShift clusters, simplifying setup through CLI or operator installation without manual Kubernetes management.[50] Additionally, Eclipse Che integrates with cloud providers like AWS via Amazon EKS and Microsoft Azure via Azure Kubernetes Service (AKS), enabling deployment on managed Kubernetes offerings for scalable, cloud-native development.[44]Multi-Tenancy and Performance
Eclipse Che implements multi-tenancy through Kubernetes namespaces, providing logical isolation for users and their resources. Each developer is assigned a dedicated namespace, typically named<username>-devspaces, which contains their containerized development environments (CDEs), pods, secrets, ConfigMaps, and persistent volumes. This namespace-based isolation ensures that users can only access and manage resources within their own environment, preventing interference or unauthorized access to others' workspaces. Cluster administrators can pre-provision these namespaces or disable automatic provisioning to enforce stricter access controls.[51]
Role-Based Access Control (RBAC) is integral to Eclipse Che's multi-tenancy model, leveraging Kubernetes RBAC mechanisms for fine-grained permissions. Default ClusterRoles, such as <namespace>-cheworkspaces-clusterrole and <namespace>-cheworkspaces-devworkspace-clusterrole, are created to manage interactions with Che-specific resources. Users receive RoleBindings in their personal namespace, granting verbs like "get," "create," "update," "patch," and "delete" on key objects including pods, secrets, devworkspaces, and routes. Administrators can extend these permissions but are advised against removing core defaults to maintain functionality. This RBAC setup aligns with OpenShift's security context constraints, enhancing isolation in shared clusters.[51]
For scaling, Eclipse Che relies on Kubernetes-native features to handle growing numbers of users and workspaces. Resource quotas and limit ranges are applied per namespace to prevent resource monopolization, controlling CPU, memory, and storage allocations for individual workspaces. Deployments are recommended to cap namespaces at around 10,000 to avoid performance degradation from excessive API objects. Che itself typically runs as a single instance per cluster for simplicity. For enterprise-scale operations exceeding thousands of concurrent users, multi-cluster architectures with load balancers and DNS routing are employed to distribute load across independent Che installations.[52][53]
Performance in Eclipse Che is optimized around a centralized server architecture, where the Che server acts as a shared service orchestrating workspace lifecycle, Git integrations, and API endpoints across all users. This centralization reduces redundancy but requires careful tuning to manage load; for instance, the Kubernetes etcd has a recommended maximum size of 8 GB, with recommendations to prune old DevWorkspace objects (e.g., retaining only recent ones to keep usage under 2.5 GB for 6,000 objects). Workspace startup times are improved via the Image Puller component, a DaemonSet that pre-pulls common container images to worker nodes in advance, minimizing pull delays during initialization. In large deployments, disabling unnecessary Operator Lifecycle Manager (OLM) features like copied ClusterServiceVersions further alleviates etcd overhead.[52][21][54]
Challenges in multi-tenant environments include handling high concurrency, where bottlenecks in etcd from accumulating DevWorkspace Custom Resources or oversized ConfigMaps can degrade API responsiveness. Solutions involve regular pruning via the DevWorkspace Operator (version 0.34.0 or later) and monitoring cluster limits, such as OpenShift's maximum of 150,000 pods and 2,000 nodes. Additionally, IDE plugins like VS Code, not inherently designed for multitenancy, may introduce scaling complexities, addressed through workspace configuration limits and predictive node scaling tools like Karpenter. These measures enable Eclipse Che to support hundreds of concurrent workspaces reliably in production settings.[52]