Jekyll2026-07-22T13:21:04+00:00https://che.eclipseprojects.io/feed.xmlEclipse Che BlogEclipse Che runs IDEs in Kubernetes.Beyond Human IDEs: Running Agentic Cloud Development Environments in Eclipse Che2026-07-22T00:00:00+00:002026-07-22T00:00:00+00:00https://che.eclipseprojects.io/2026/07/22/@rohan.kumar/beyond-human-ides-running-agentic-workspaces

Introduction

AI coding agents have shifted from autocomplete helpers to autonomous teammates that can edit code, run tests, and open pull requests. Today, they often run in the same environments developers already use every day: a local machine or a full IDE cloud workspace.

What if, for routine, well-defined tasks, those agents could run in their own lightweight, isolated environments instead, so you could stay focused on creative problem-solving and review what the agents produce?

One way to do that is with Agentic Workspaces on Eclipse Che. Che’s Cloud Development Environments (CDEs) let you spin up terminal-centric workspaces dedicated to autonomous agents: safer agentic automation in isolated sandboxes, with the human in the review loop, either inspecting a diff in the workspace or reviewing a pull request the agent creates.

Here is the end result this post walks through: Claude Code and OpenCode running side by side in an Eclipse Che workspace with the Herdr editor definition.

Herdr workspace showing Claude Code idle as generator and OpenCode working as reviewer on a GitHub Actions workflow inside Eclipse Che.
Figure 1. End result: Claude Code (generator) and OpenCode (reviewer) agents running in an Eclipse Che workspace with the Herdr editor definition.

 

Traditional CDEs vs Agentic CDEs

Traditional CDEs are built around a full IDE experience for humans. In this post, we use Agentic CDE to describe a terminal-centric Che workspace built for terminal-based coding agents rather than human IDE use. Agentic CDEs keep the same isolation and lifecycle model, but slim the workspace down to the minimal tooling an agent needs. One does not replace the other; each is built for different use cases.

Capability Traditional CDEs Agentic CDEs

Primary user

Human developers working interactively in an IDE

Autonomous agents executing tasks, with humans in the review loop

Workspace shape

Full IDE (for example, VS Code) plus extensions, UI, and layouts

Slim terminal-centric runtime with terminal-based coding agents and a web terminal such as ttyd

Resource footprint

Higher CPU and memory to host a browser IDE and rich UI

Lower overhead; more workspaces can fit on the same cluster

Day-to-day interaction

Developer lives in the editor: coding, debugging, and exploring

Developer assigns work, monitors progress, and reviews diffs or pull requests

Best suited for

Interactive development, pairing, and complex local-style workflows in the cloud

Routine or parallel agent tasks that do not need a full graphical IDE

Strengths

Familiar IDE UX, rich debugging, and strong human productivity tooling

High density, lower cost per workspace, and a tighter sandbox for unattended agent runs

Trade-offs

Heavier and often more than an agent needs for CLI-driven work

Less convenient for deep interactive editing; humans review rather than live in the workspace

The Human-in-the-Review-Loop Workflow

An agentic workspace flips the usual CDE interaction model. The developer is no longer living inside the IDE day to day; they are the orchestrator and reviewer.

  1. Assign a task: the human starts a Che workspace and points an agent at a bug, feature, or specification.

  2. Let the agent work: the agent edits code, runs tests, and iterates inside the isolated workspace, observed through ttyd if needed.

  3. Review the outcome: when the agent finishes, the human either inspects the diff in that workspace or, more commonly for team workflows, reviews a pull request the agent created.

That last step is the control point. The agent does the execution; the human decides what merges.

Review-loop flow showing a human assigning tasks to an agentic workspace in Eclipse Che on Kubernetes, producing a diff or PR for human review, with API calls to on-prem or cloud-hosted models.
Figure 2. Review-loop flow: the human assigns a task, the agent works inside an Eclipse Che workspace, and the human reviews a diff or pull request. The agent can call on-prem or cloud-hosted models.

 

The Stack: Eclipse Che and ttyd

In this post, we show one practical stack: Eclipse Che for the workspace lifecycle, plus ttyd for a lightweight browser terminal. The idea is to strip away the traditional desktop IDE layer and keep a minimal, terminal-centric environment.

Component Role in the Agentic Workspace

Eclipse Che

The Kubernetes-native control plane. It handles workspace lifecycle, secure container isolation, RBAC, and compute resource allocation.

ttyd

A simple, fast utility that shares a Linux terminal over the web, allowing users to monitor their agents in real-time through any browser.

Together, they create a secure sandbox where AI agents can run without overloading a developer’s local machine or cluttering their primary workspace. You get a browser-accessible shell backed by Kubernetes isolation, with no full IDE required.

Step-by-Step: Running an Agentic CDE in Eclipse Che

Here is a simple way to start an agentic workspace from the Eclipse Che dashboard.

Prerequisites:

  • Access to an Eclipse Che instance (for example, a local or team deployment)

  • Credentials for an LLM provider your coding agent can use (on-prem or cloud-hosted)

  • A Git repository URL to import in the Import from Git section

  • Optional: Git credentials configured in Eclipse Che so the agent can push branches and open pull requests on your Git provider automatically

1. Go to the Eclipse Che Dashboard

Open your Che dashboard in the browser and begin creating a new workspace.

2. Choose an Editor Definition

Open the Choose an Editor tree and select a lightweight, terminal-centric editor definition instead of a full IDE. For an agentic CDE, pick either:

  • Web Terminal: a minimal ttyd-based shell in the browser

  • Herdr: an agent-aware terminal multiplexer on top of the same web-terminal model

Eclipse Che Editor Selector with red circles around Herdr and Web Terminal editor definitions.
Figure 3. Eclipse Che Editor Selector, with Herdr and Web Terminal highlighted as lightweight, terminal-centric editor definitions alongside full IDEs.

 

3. Provide a Git Repository URL and Create the Workspace

In the Import from Git section, paste the Git repository URL for the project you want the agent to work on. Then select Create & Open to start the workspace.

Eclipse Che Import from Git section with the Create and Open button highlighted.
Figure 4. Import from Git: enter a repository URL, then select Create & Open.

 

4. Wait for the Workspace to Become Ready, Then Launch a Coding Agent

Wait for the workspace to become ready. Once it is ready, Che opens the ttyd-based terminal in the browser. From there, launch your preferred terminal-based coding agent (for example, claude-code or opencode), point it at a task or specification, and let it work inside the isolated workspace.

Note

Terminal-based coding agents (such as Claude Code or OpenCode) must already be present in the DevWorkspace container image, or installed or otherwise injected into the workspace before you use them. One simple option is a Devfile exec command. See che-server Devfile as an example that installs the Claude Code CLI.
Note
 Coding agents also need authentication configured for the models they call. That step varies by tool and model provider (for example API keys, login flows, or on-prem endpoint settings).

When the agent finishes, stay in the review loop: inspect the diff in the workspace, or let the agent open a pull request and review that through your normal Git workflow.

Here is an example of Claude Code and OpenCode running in a workspace with the Herdr editor definition. Herdr shows each agent in the sidebar (idle or working) while the active pane streams the agent’s tools and output.

Herdr workspace showing Claude Code idle and OpenCode working on Dockerfile tests inside Eclipse Che.
Figure 5. Claude Code and OpenCode agents running in an Eclipse Che workspace with the Herdr editor definition.
Tip
 If you chose Herdr, you can split panes and run multiple agents in parallel, while Herdr tracks whether each one is idle, working, or blocked. The platform underneath matters more: with Che, each agent still gets its own sandboxed, Kubernetes-native workspace.

How Agentic CDEs help Teams

Agentic CDEs keep each coding agent in its own Kubernetes-isolated workspace, instead of sharing a developer laptop or a long-lived VM. Using Che for ttyd-driven agent workspaces can build on that foundation in a few practical ways:

  • Contained sandbox execution: Giving autonomous tools raw access to a local machine is a significant security and operational risk. With Eclipse Che, you can confine the agent to a secure, RBAC-bounded Kubernetes namespace. If an agent misbehaves or runs a destructive script, the blast radius stays contained within that workspace.

  • Higher workspace density: Without the overhead of complex browser-based IDE UIs, terminal-centric workspaces typically require less CPU and memory, so teams can run more agent workspaces on the same cluster.

  • Parallel asynchronous scaling: A developer can spin up multiple independent agent workspaces simultaneously from their browser, each tackling a different task or bug report, without consuming local compute.

Try It Yourself

If you do not have a Che instance handy, you can try this workflow on Eclipse Che hosted by Red Hat through the Developer Sandbox. Open workspaces.openshift.com, choose a terminal-centric editor definition, and import a Git repository as described above.

Conclusion

Software engineering is evolving, and so are CDEs along with it. They are no longer only digital desktops for human developers; they can also host safer agentic automation in isolated workspaces.

With Eclipse Che’s Kubernetes-native orchestration and lightweight tools like ttyd, you can try this pattern today: spin up a terminal-centric workspace, run a coding agent inside it, and keep humans in the review loop through diffs or pull requests.

]]>Rohan KumarUsing Keycloak as an External Identity Provider for Eclipse Che on OpenShift2026-04-20T00:00:00+00:002026-04-20T00:00:00+00:00https://che.eclipseprojects.io/2026/04/20/@tolusha/openshift-external-idp

Starting with OpenShift 4.20, administrators can configure external OIDC identity providers for direct authentication to bypass the built-in OAuth server and use the external identity provider directly. This enables direct integration with an external OIDC provider, allowing you to use its advanced capabilities beyond the built-in OAuth server.

Eclipse Che now fully supports this setup: you can deploy Che on an OpenShift cluster that authenticates users through an external Keycloak instance, for example. In this post, we walk through the end-to-end configuration.

Step-by-Step Configuration

Prerequisites:

  • Keycloak is deployed and configured as an external identity provider for OpenShift.

  • You have cluster administrator access.

  • You have oc CLI installed and authenticated.

1. Create the Eclipse Che Client in Keycloak

In the Keycloak Admin Console, create a new client for Eclipse Che:

  1. Navigate to your OpenShift realm and select Clients.

  2. Click Create client.

  3. Set the Client ID to eclipse-che.

  4. On the Capability config page, toggle Client authentication to On.

  5. Save the client and copy the Client secret from the Credentials tab.

Note
 You configure the redirect URI after deploying Eclipse Che (Step 7).
Creating the eclipse-che client in Keycloak Admin Console

2. Register the Client as an Audience

Add the eclipse-che client to the audiences list in the OpenShift authentication configuration:

oc patch authentication.config/cluster \
  --type='json' \
  -p='[
    {
      "op": "add",
      "path": "/spec/oidcProviders/0/issuer/audiences/-",
      "value": "eclipse-che"
    }
  ]'

Then wait for the kube-apiserver to roll out the changes:

watch oc get co kube-apiserver

3. Create the eclipse-che Namespace

oc create namespace eclipse-che

4. Create the OAuth Secret

oc apply -f - <<EOF
apiVersion: v1
kind: Secret
metadata:
  name: oauth-secret
  namespace: eclipse-che
  labels:
    app.kubernetes.io/part-of: che.eclipse.org
stringData:
  oAuthSecret: <CLIENT_SECRET>
EOF

Replace <CLIENT_SECRET> with the value copied from the Keycloak Credentials tab.

5. Import the Keycloak CA Certificate

Create a ConfigMap containing the Keycloak server’s CA certificate, so that Eclipse Che can trust the Keycloak endpoint.

Extract the CA certificate from the Keycloak server:

openssl s_client \
  -connect "$(echo "$KEYCLOAK_URL" | sed 's|https://||'):443" \
  -showcerts < /dev/null \
  | sed -n '/-----BEGIN CERTIFICATE-----/,/-----END CERTIFICATE-----/p' \
  > keycloak-ca.crt

Create a ConfigMap from the extracted certificate:

oc create configmap keycloak-certs \
  --from-file=keycloak-ca.crt=keycloak-ca.crt \
  -n eclipse-che

Label the ConfigMap so that Eclipse Che recognizes it as a trusted CA bundle:

oc label configmap keycloak-certs \
  app.kubernetes.io/part-of=che.eclipse.org \
  app.kubernetes.io/component=ca-bundle \
  -n eclipse-che

6. Prepare the CheCluster Configuration

Create a patch file that configures Che to use Keycloak for authentication. Replace <KEYCLOAK_URL> with the actual Keycloak URL, <OPENSHIFT_REALM> with the Keycloak realm configured for OpenShift authentication, and the claim and prefix values with those configured in the authentication.config/cluster resource:

cat > che-patch.yaml << EOF
kind: CheCluster
apiVersion: org.eclipse.che/v2
spec:
  networking:
    auth:
      oAuthClientName: eclipse-che
      oAuthSecret: oauth-secret
      identityProviderURL: "<KEYCLOAK_URL>/realms/<OPENSHIFT_REALM>"
      gateway:
        oAuthProxy:
          cookieExpireSeconds: 300
        deployment:
          containers:
            - name: oauth-proxy
              env:
                - name: OAUTH2_PROXY_CODE_CHALLENGE_METHOD
                  value: S256
                - name: OAUTH2_PROXY_BACKEND_LOGOUT_URL
                  value: "<KEYCLOAK_URL>/realms/<OPENSHIFT_REALM>/protocol/openid-connect/logout?id_token_hint={id_token}"
  components:
    cheServer:
      extraProperties:
        CHE_OIDC_GROUPS__CLAIM: '<GROUPS_CLAIM>'
        CHE_OIDC_GROUPS__PREFIX: '<GROUPS_PREFIX>'
        CHE_OIDC_USERNAME__CLAIM: '<USERNAME_CLAIM>'
        CHE_OIDC_USERNAME__PREFIX: '<USERNAME_PREFIX>'
EOF

7. Deploy Eclipse Che

chectl server:deploy --platform openshift --che-operator-cr-patch-yaml che-patch.yaml
Eclipse Che deployed

8. Configure the Callback URL in Keycloak

After deployment, update the eclipse-che client in Keycloak with the redirect URI and web origin:

  1. Get the Eclipse Che URL:

    oc get checluster eclipse-che -n eclipse-che \
  -o jsonpath='{.status.cheURL}'

  2. In the Keycloak Admin Console, open the eclipse-che client.

  3. Paste the URL with /oauth/callback appended into Valid redirect URIs.

  4. Paste the URL into Web origins.

  5. Save.

9. Start a Workspace

Once everything is configured, open the dashboard and start a workspace:

chectl dashboard:open

You should be redirected to the Keycloak login page. After authenticating, the Eclipse Che dashboard opens.

Eclipse Che dashboard after successful authentication

For the full reference documentation, see Installing Che on OpenShift with Keycloak as external identity provider.

]]>Anatolii BazkoRunning Open VSX On-Premises2025-09-09T00:00:00+00:002025-09-09T00:00:00+00:00https://che.eclipseprojects.io/2025/09/09/@svor/running-open-vsx-on-premises

Introduction

Developers love extensions — they customize editors, add new languages, and streamline workflows. But in enterprise environments, relying on the public Open VSX registry can introduce challenges: air-gapped environments, compliance rules, or simply the need for a curated list of approved tools.

That’s where running Open VSX On-Premises comes in. In this post, we’ll explore how Eclipse Che makes it easy to deploy and configure your own extension registry, using nothing more than an Eclipse Che Cloud Development Environment running on the OpenShift cluster.

Step-by-Step: Preparing Eclipse Open VSX with Eclipse Che

All the following steps can be executed inside an Eclipse Che workspace provisioned from the Open VSX repository’s devfile. This Devfile automates most of the work — so instead of manually stitching pieces together, you simply run tasks in sequence.

Prerequisites:

  • You must be running Eclipse Che on an OpenShift cluster.

  • You must be logged in as a cluster administrator.

Step 1: Start the Open VSX Workspace

Create a workspace using the Open VSX repository. This initializes an environment with all required components and tasks.

User Dashboard

Figure 1: User Dashboard

Step 2: Create an OpenShift project for Open VSX

Run the Devfile task:

Terminal → Run Task… → devfile → 2.1. Create Namespace for OpenVSX

This creates a new OpenShift project named openvsx.

Create Open VSX Project

Figure 2: Open VSX namespace creation

Step 3: Build and Publish the Open VSX Server Image

Run the task:

Terminal → Run Task… → devfile → 2.2. Build and Publish Open VSX Image

You’ll be prompted for the Open VSX version (defaults to v0.27.0 if left blank). The image is built and pushed to the OpenShift internal registry.

Build Open VSX Server Image

Figure 3: Open VSX server image build

Step 4: Build and Publish the Open VSX CLI (ovsx) Image

Run the task:

Terminal → Run Task… → devfile → 2.3. Build and Publish OpenVSX CLI Image

This prepares the ovsx CLI image and uploads it to the cluster registry.

Build Open VSX CLI Image

Figure 4: Open VSX CLI image build

Step 5: Deploy Open VSX Components

Run the task:

Terminal → Run Task… → devfile → 2.4. Deploy OpenVSX

This command deploys the Open VSX components to an OpenShift project by processing a template file (openvsx-deployment.yml). It creates all required resources defined in the template, which includes:

  • Deployments (PostgreSQL, Elasticsearch, Open VSX server, Open VSX CLI).

  • Services and Routes for accessing components.

  • Secrets for GitHub OAuth credentials and Open VSX personal access token.

Open VSX Pods

Figure 5: Open VSX pods running in OpenShift console

Step 6: Add a User with Personal Access Token (PAT)

Run the task :

Terminal → Run Task… → devfile → 2.5. Add OpenVSX user with PAT to the DB

The command will ask for the Open VSX username and user PAT and insert them into the PostgreSQL database. You can just click enter to use the default values.

Important
 ❗ The user PAT must match the decoded value of OVSX_PAT_BASE64 specified in the deployment file. If OVSX_PAT_BASE64 has been updated, use the new token’s decoded value as the user PAT.
Adding User and PAT

Figure 6: Terminal output after adding a user with a PAT

Step 7: Configure Eclipse Che to Use Your Internal Registry

Run the task:

Terminal → Run Task… → devfile → 2.6. Configure Che to use the internal OpenVSX registry

This patches the CheCluster CR, updating the pluginRegistry.openVSXURL to point to your internal Open VSX endpoint.

CheCluster CR

Figure 7: CheCluster custom resource after patching

Step 8: Publish Extensions via VSIX File

At the beginning, the Open VSX registry does not provide any extensions. Once the openvsx-server pod is running and in the Ready state, extensions can be published to the registry. The 2.8. Publish a Visual Studio Code Extension from a VSIX file command publishes an extension to the local Open VSX registry directly from a .vsix file. It prompts you to provide the extension’s namespace name and the path to the .vsix file.

Publish Extension from VSIX

Figure 8: Publish GitLens extension from the local vsix file

Step 9: Batch Publish Extensions from a List

For multiple extensions, run:

Terminal → Run Task… → devfile → 2.9. Publish list of Visual Studio Code Extensions

This task reads URLs from deploy/openshift/extensions.txt and publishes them automatically.

Publish List of Extensions

Figure 9: Batch publishing from extensions.txt

Step 10: Verify Integration

Start a new Che workspace and open the Extensions view. Confirm that extensions are served from your internal registry.

Extensions View

Figure 10: Extensions view

Or browse directly to your registry’s route, opening the internal route in the OpenVSX OpenShift project.

Open VSX Extensions Registry

Figure 11: Custom Extensions registry

Optional: Restrict Open VSX Registry to Internal-Only Access

To prevent external exposure:

  • Delete the public route with name internal from openvsx OpenShift project:

oc delete route internal -n openvsx

  • Patch Che to use the in-cluster service DNS:

oc patch checluster <name> -n <namespace> \
  --type=merge \
  --patch '{"spec":{"components":{"pluginRegistry":{"openVSXURL":"http://openvsx-server.openvsx.svc:8080"}}}}'

Conclusion

Setting up Open VSX on-premises with Eclipse Che may sound complex at first, but the Devfile-driven flow makes it straightforward: You spin up a workspace, run a sequence of tasks, and end up with a fully functional, internal extension registry.

Further Reading

]]>Valerii SvydenkoSpec-Driven Development in Action2025-08-18T00:00:00+00:002025-08-18T00:00:00+00:00https://che.eclipseprojects.io/2025/08/18/@oleksii.kurinnyi/spec-driven-development-in-action

Introduction

What if the most important skill for a developer was no longer writing code, but writing specifications? The traditional development cycle is a grind of boilerplate, configuration, and repetitive tasks. We spend more time on the "how" than perfecting the "what". But a new paradigm, powered by AI, is shifting that dynamic, and you can try it yourself right now.

I’m talking about specification-driven development, a workflow where the developer’s primary role is to create a detailed, machine-readable blueprint of an application. To prove it, I built a full-stack URL shortener. The vast majority of my time was spent crafting a perfect specification file; then an AI did the rest with a single command.

The Tools and the Paradigm

This experiment relies on a powerful combination of modern tools working in synergy:

  • Eclipse Che: A platform for providing Kubernetes-based Cloud Development Environments.

  • RA.Aid & Aider: A pair of open-source AI assistants, both licensed under the Apache 2.0. RA.Aid is the master planner, taking a high-level spec and breaking it down into an implementation plan. Aider is the hands-on coder, executing the plan and modifying the code.

Together, they enable a shift where you, the developer, transition from a coder to an architect. Your focus is on high-level decisions, defining robust data models, crafting clean API contracts, and designing intuitive user interactions. The specification file becomes the single source of truth that drives the entire development process.

How to Replicate This: From Repo to Running App

You can follow these exact steps to see the process for yourself.

Step 1: The Blueprint Repo

Everything you need to start is in this GitHub repository: che-incubator/demo-spec-driven-development-with-ai

This repo contains the blueprint for our entire project. It includes two crucial files: the spec.md, which provides the detailed instructions for the AI, and the devfile.yaml, which defines the Eclipse Che workspace.

Step 2: Launch the Workspace with a Devfile

The devfile.yaml is the key to a one-click setup. It tells Eclipse Che to create a workspace using a pre-configured container image (quay.io/che-incubator/cli-ai-tools:latest) that already includes RA.Aid and Aider. This means your development environment comes ready with all the specialized AI tools installed.

Step 3: Secure Your AI’s Access

To work, the AI assistants need access to a Large Language Model (LLM). RA.Aid and Aider are flexible and support many different providers, including Gemini, OpenAI, Anthropic, Groq, and more. For this demo, we’ll use the Gemini API.

The recommended way to provide credentials is by creating a Kubernetes Secret. Eclipse Che will then automatically mount this secret as an environment variable inside your workspace. For the Gemini API, the required environment variable is GEMINI_API_KEY.

You can create the secret for Gemini with the following command:

oc apply -f - <<EOF
kind: Secret
apiVersion: v1
metadata:
  name: gemini-api-key
  labels:
    controller.devfile.io/mount-to-devworkspace: 'true'
    controller.devfile.io/watch-secret: 'true'
  annotations:
    controller.devfile.io/mount-as: env
data:
  GEMINI_API_KEY: [base64 encoded Gemini API key]
type: Opaque
EOF

If you prefer to use a different provider, simply consult the RA.Aid or Aider documentation for the correct environment variable name (e.g., OPENAI_API_KEY) and adapt the secret accordingly.

Step 4: Unleash the AI

Once you have crafted the spec.md for the application of your dreams, all it takes is this one command in the terminal to set the AI to work:

ra-aid --use-aider --cowboy-mode --show-cost --track-cost --msg-file spec.md

This command tells RA.Aid to use your spec.md file as its guide, leverage Aider for code modifications, and run autonomously without needing interactive approval (--cowboy-mode).

Instantly, the agent will parse the specification and begin building the application right inside your Eclipse Che workspace, just as it did for my URL shortener. See the whole process unfold in the video below.

As the agent works, you can follow its progress directly in the terminal. The output shows its step-by-step thinking process as it interprets the specification, plans its actions, and executes them.

RA.Aid command running in the terminal
Figure 1. RA.Aid command running in the terminal, showing the AI planning and executing steps for the URL shortener.

 

It will generate the backend, the frontend, and any necessary scripts. You can see the complete, well-structured project created by the AI in the file explorer.

Generated project file structure for the URL shortener in the Eclipse Che IDE.
Figure 2. Generated project file structure for the URL shortener in the Eclipse Che IDE.

 

Step 5: Working Application

Writing a detailed specification requires deep thought, but that upfront investment pays off massively by automating the hours of coding and debugging. After the agent finishes, you have a fully working application.

Note
 While the demo environment’s hostname makes the full URL long, the AI correctly built the core feature: generating a short, clean, and predictable path for any link you provide.
Final URL shortener application is running in a browser tab within Eclipse Che.
Figure 3. The final URL shortener application is running in a browser tab within Eclipse Che.

 

Conclusion

This demonstration is more than just a new way to build a URL shortener; it’s a glimpse into the future of our profession. The rise of capable AI assistants marks a fundamental shift in the developer’s workflow, moving us away from the manual, line-by-line construction of applications and toward a new paradigm where we act as architects. Our primary role is evolving to be the designers of robust systems, the authors of clear specifications, and the strategic thinkers who guide AI tools to execute a vision.

Spec-driven development is likely just one step on a path of rapid transformation. The world of AI in software engineering is changing fast, and the tools we use tomorrow will be even more powerful.

The best way to understand this shift is to experience it firsthand. I encourage you to run the demo yourself and reflect on how this technology could change your own work. The conversation is no longer about whether AI will write code, but about how we will guide it to build better software.

]]>Oleksii KurinnyiVibe Coding with Eclipse Che2025-07-23T00:00:00+00:002025-07-23T00:00:00+00:00https://che.eclipseprojects.io/2025/07/23/@ilya.buziuk/vibe-coding

Introduction

Imagine a world where coding isn’t about meticulous syntax or endless debugging, but about conversation and pure flow. Welcome to "vibe coding" – a revolutionary approach to software development where Large Language Models (LLMs) become your ultimate co-pilot, transforming complex tasks into effortless interactions.

This paradigm shift gained significant traction in early February 2025, sparked by Andrej Karpathy’s insightful post on X, who actually coined the term:

There’s a new kind of coding I call "vibe coding", where you fully give in to the vibes, embrace exponentials, and forget that the code even exists. It’s possible because the LLMs (e.g. Cursor Composer w Sonnet) are getting too good. Also I just talk to Composer with SuperWhisper so I barely even touch the keyboard. I ask for the dumbest things like "decrease the padding on the sidebar by half" because I’m too lazy to find it. I "Accept All" always, I don’t read the diffs anymore. When I get error messages I just copy paste them in with no comment, usually that fixes it. The code grows beyond my usual comprehension, I’d have to really read through it for a while. Sometimes the LLMs can’t fix a bug so I just work around it or ask for random changes until it goes away. It’s not too bad for throwaway weekend projects, but still quite amusing. I’m building a project or webapp, but it’s not really coding - I just see stuff, say stuff, run stuff, and copy paste stuff, and it mostly works.

This "AI-First Coding" is rapidly being embraced by Big Tech and is quickly becoming the new norm:

Big Tech embraces Vibe Coding

Figure 1: Big Tech embraces Vibe Coding (the screenshot was taken from the CNBC Television YouTube Channel)

In this article, we will delve into the innovative solutions and tools that are transforming vibe coding from a concept to a powerful new reality for developers everywhere. We will also explore why Cloud Development Environments (CDEs) are the ideal playground for the "AI-First Coding" unlike the local IDEs.

Open-Source Tools for the Vibe Coder

To truly embrace Vibe Coding, you need the right tools. While many closed-source assistants exist—such as Cursor, Windsurf, and Kiro (all effectively forks of the Visual Studio Code - Open Source ("Code - OSS")), the open-source community offers powerful alternatives that provide greater control and transparency.

Important
 A significant drawback of local-first AI tools is their potential to disrupt your local development environment if the AI assistant misbehaves. Cloud Development Environments (CDEs), however, offer a crucial advantage for AI assistants: they provide isolated, repeatable, and on-demand workspaces. This means developers don’t have to worry about misbehaving AI tools, MCP agents, or other integrations breaking their local setup, as any issues remain contained within a pod/namespace itself (assuming proper RBAC setup for the developer persona on the Kubernetes cluster).

Let’s explore a few awesome open-source extensions available on Open VSX that make vibe coding a reality today.

Continue

Continue is an open-source autopilot for software development, available under the Apache 2.0 license. Continue enables developers to create, share, and use custom AI code assistants with open-source VS Code and JetBrains extensions, as well as a hub of models, rules, prompts, documentation, and other building blocks. The extension allows you to connect to any LLM, local or hosted, to receive coding assistance directly within the IDE.

Tip
 Learn more about integrating a private AI coding assistant into your Cloud Development Environments using Ollama and Continue in the dedicated article.

Cline

Cline is an open-source extension for Visual Studio Code, available under the Apache 2.0 license. Cline (pronounced /klaɪn/, like “Klein”), an AI assistant that can use your CLI aNd Editor. Cline extension is an autonomous coding agent right in the IDE, capable of creating/editing files, executing commands, using the browser, and more with your permission every step of the way.

Roo Code

Roo Code is yet another open-source extension for Visual Studio Code, available under the Apache 2.0 license. As a fork of Cline, Roo Code builds upon its foundation to provide an AI coding assistant that integrates directly into the IDE. It excels at understanding your intentions, offering intelligent code completions, refactoring suggestions, and explaining complex code blocks. Designed to thrive in CDEs, Roo Code provides a secure, reproducible environment to push the boundaries of AI-powered development. With Roo, you can request broad changes, refactor entire functions with a single prompt, and let the AI handle repetitive tasks, freeing you to focus on the creative aspects of coding. Roo Code is an AI-powered autonomous coding agent that lives in your editor. It can:

  • Communicate in natural language

  • Read and write files directly in your workspace

  • Run terminal commands

  • Automate browser actions

  • Integrate with any OpenAI-compatible or custom API/model

  • Adapt its “personality” and capabilities through Custom Modes

Whether you’re seeking a flexible coding partner, a system architect, or specialized roles like a QA engineer or product manager, Roo Code can help you build software more efficiently.

Experience Vibe Coding Now!

Ready to experience the future of coding? All you need is a browser!

You can start Vibe Coding in minutes using Eclipse Che hosted by Red Hat on the Developer Sandbox.

  1. Register for a Developer Sandbox for Red Hat OpenShift account.

  2. Go to workspaces.openshift.com

  3. Start an Empty Workspace from the Getting Started Samples or import your pet project from Git:

User Dashboard

Figure 2: User Dashboard

  1. Install the Roo Code extension from the marketplace:

Open VSX Marketplace

Figure 3: Open VSX Marketplace

Tip
 You can add the Roo Code extension to the .vscode/extensions.json file in the Git repository, and it will be installed automatically after workspace startup:

  1. Choose LLM and Configure the API Key in the Roo Code "Settings".

Roo Code Settings

Figure 4: Roo Code Settings

Tip
 For some Gemini models e.g. gemini-2.5-flash you can generate a free API Key on the Google AI Studio. You only need to set up the API key once in the extension; it will be persisted in your browser settings for future workspaces.

And…​ start vibe coding - put the wildest ideas in the chat window, and Roo Code will do it’s best to make it come true!

Roo Code

Figure 5: Roo Code Extension

This iterative, conversational approach allows you to rapidly prototype and build, focusing on the desired outcome rather than the intricate details of implementation.

Conclusion

Vibe coding represents a paradigm shift in software development. It’s about moving away from meticulous, line-by-line implementation and embracing a more intuitive, conversational, and results-driven workflow. This AI-first approach, powered by increasingly sophisticated LLMs, lets developers focus on the "what" rather than the "how," accelerating innovation and making development more accessible.

AI coding assistants are central to this new workflow, providing code suggestions, completions, and contextual help. Combining these assistants with a Cloud Development Environment creates a powerful and secure setup. CDEs offer isolated, on-demand workspaces, allowing your AI assistant to experiment freely without risking your local machine. Any issues are contained within the ephemeral workspace, which can be easily discarded and restarted.

As we’ve explored, Cloud Development Environments are the ideal playground for this new era. They provide safe, isolated, and reproducible workspaces where you can unleash powerful AI assistants like Roo Code without fear of breaking your local setup. The synergy between a CDE and a cutting-edge AI assistant enables a flow state of rapid prototyping and iteration that was previously unimaginable.

The journey into vibe coding is just beginning. We encourage you to follow our guide, embrace the flow, and discover how these tools can transform your own development process. The future of coding isn’t about replacing developers; it’s about empowering them with tools that amplify their creativity and productivity.

Happy Vibe Coding!

]]>Ilya BuziukRunning at Scale2025-04-29T00:00:00+00:002025-04-29T00:00:00+00:00https://che.eclipseprojects.io/2025/04/29/@ilya.buziuk/running-at-scale

Introduction

Even though Kubernetes has emerged as a powerful foundation for deploying and managing containerized workloads at scale, achieving scale with Cloud Development Environments (CDEs), particularly in the range of thousands of concurrent workspaces, presents significant challenges.

Important
 CDE workloads are complex to scale mainly because of the fact that underlying IDE solutions, such as Visual Studio Code - Open Source ("Code - OSS") or JetBrains Gateway, are designed as single-user applications rather than multitenant services.

Such a scale imposes substantial infrastructure demands and introduces potential bottlenecks that can impact the performance and stability of the entire system. Addressing these challenges requires meticulous planning, strategic architectural choices, monitoring, and continuous optimization to ensure a seamless and efficient development experience for a large number of users. In this article, you can find a few important takeaways worth considering when running Eclipse Che at scale on Kubernetes.

Planning your environment according to object maximums

While there is no strict limit on the number of resources in a Kubernetes cluster, there are certain considerations for large clusters to keep in mind.

Tip
 More insights about the Kubernetes scalability can be found in the "Scalability, with Wojciech Tyczynski" Kubernetes Podcast.

OpenShift Container Platform, which is a certified distribution of Kubernetes, also provides a set of tested maximums for various resources, which can serve as an initial guideline for planning your environment:

Resource type Tested maximum

Number of nodes

2000

Number of pods

150000

Number of pods per node

2500

Number of namespace

10000

Number of services

10000

Number of secrets

80000

Number of config maps

90000

Table 1: OpenShift Container Platform tested cluster maximums for various resources.

Tip
 You can find more details on the OpenShift Container Platform tested object maximums in the official documentation.

For example, it is generally not recommended to have more than 10,000 namespaces due to potential performance and management overhead. In Eclipse Che, for instance, each user is allocated a namespace. If you expect the user base to be large, consider spreading workloads across multiple "fit-for-purpose" clusters and potentially leveraging solutions for multi-cluster orchestration.

Calculating Resource Requirements

When deploying Eclipse Che on Kubernetes, it is crucial to accurately calculate the resource requirements and determine memory and CPU / GPU needs for each CDE to come up with the right sizing of the cluster. In general, the CDE size is limited by and can not be bigger than the worker node size. The resource requirements for CDEs can vary significantly based on the specific workloads and configurations. For example, a simple CDE may require only a few hundred megabytes of memory, while a more complex one will need several gigabytes of memory and multiple CPU cores.

Tip
 You can find more details about calculating resource requirements in the official documentation.

etcd

The primary datastore of Kubernetes cluster configuration and state is etcd. It holds the cluster state and configuration, including information about nodes, pods, services, and custom resources. As a distributed key-value store, etcd does not scale well past a certain threshold, and as the size of etcd grows, so does the load on the cluster, risking its stability.

Important
 The default etcd size is 2 GB, and the recommended maximum is 8 GB. Exceeding the maximum limit can make the Kubernetes cluster unstable and unresponsive.
Metrics with the progression of the etcd storage growth that leads to cluster instability

Figure 1: Metrics with the progression of the etcd storage growth that leads to cluster instability.

The size of the objects matters

Not only the overall number, but also the size of the objects stored in etcd is a critical factor that can significantly impact its performance and stability. Each object stored in etcd consumes space, and as the number of objects increases, the overall size of etcd grows too. The larger the object is, the more space it takes in etcd. For example, etcd can be overloaded with just a few thousand of relatively big Kubernetes objects.

Important
 Even though the data stored in a ConfigMap cannot exceed 1 MiB by design, a few thousand of relatively big ConfigMap objects can overload etcd storage.

In the context of Eclipse Che, by default the operator creates and manages the 'ca-certs-merged' ConfigMap, which contains the Certificate Authorities (CAs) bundle, in every user namespace. With a large number of TLS certificates in the cluster, this results in additional etcd usage.

In order to disable mounting the CA bundle using the ConfigMap under the /etc/pki/ca-trust/extracted/pem path, configure the CheCluster Custom Resource by setting the disableWorkspaceCaBundleMount property to true. With this configuration, only custom certificates will be mounted under the path /public-certs:

spec:
  devEnvironments:
    trustedCerts:
      disableWorkspaceCaBundleMount: true
Tip
 You can find more details about importing untrusted TLS certificates in the official documentation.

DevWorkspace objects

For large Kubernetes deployments, particularly those involving a high number of custom resources such as DevWorkspace objects, which represent CDEs, etcd can become a significant performance bottleneck.

Important
 Based on the load testing for 6,000 DevWorkspace objects, storage consumption for etcd was around 2.5GB.

Starting from DevWorkspace Operator version 0.34.0, you can configure a pruner that would automatically clean up DevWorkspace objects that were not in use for a certain period of time. To set the pruner up, configure the DevWorkspaceOperatorConfig object as follows:

apiVersion: controller.devfile.io/v1alpha1
kind: DevWorkspaceOperatorConfig
metadata:
  name: devworkspace-operator-config
  namespace: crw
config:
  workspace:
    cleanupCronJob:
      enabled: true
      dryRun: false
      retainTime: 2592000 # By default, if a workspace was not started for more than 30 days it will be marked for deletion
      schedule: “0 0 1 * *” # By default, the pruner will run once per month
Tip
 You can find more details about DevWorkspace Operator Configuration in the official documentation.

OLMConfig

When an operator is installed by the Operator Lifecycle Manager (OLM), a stripped-down copy of its CSV is created in every namespace the operator is configured to watch. These stripped-down CSVs are known as “Copied CSVs” and communicate to users which controllers are actively reconciling resource events in a given namespace. On especially large clusters, with namespaces and installed operators tending in the hundreds or thousands, Copied CSVs consume an untenable amount of resources; e.g. OLM’s memory usage, cluster etcd limits, networking, etc. In order to eliminate the CSVs copied to every namespace, configure the OLMConfig object accordingly:

apiVersion: operators.coreos.com/v1
kind: OLMConfig
metadata:
  name: cluster
spec:
  features:
    disableCopiedCSVs: true
Tip
 Additional information about the disableCopiedCSVs feature can be found in its original enhancement proposal.

The primary impact of the disableCopiedCSVs property on etcd is related to resource consumption. In clusters with a large number of namespaces and many cluster-wide Operators, the creation and maintenance of numerous Copied CSVs can lead to increased etcd storage usage and memory consumption. By disabling Copied CSVs, the amount of data stored in etcd is significantly reduced, which can help improve overall cluster performance and stability.

This is particularly important for large clusters where the number of namespaces and operators can quickly add up to a significant amount of data. Disabling Copied CSVs can help reduce the load on etcd, leading to improved performance and responsiveness of the cluster. Additionally, it can help reduce the memory footprint of OLM, as it no longer needs to maintain and manage these additional resources.

Tip
 You can find more details about "Disabling Copied CSVs" in the official documentation.

Cluster Autoscaling

Although cluster autoscaling is a powerful Kubernetes feature, you cannot always fall back on it. You should always consider predictive scaling by analyzing load data on your environment to detect daily or weekly usage patterns. If your workloads follow a pattern and there are dramatic peaks throughout the day, you should consider provisioning worker nodes accordingly. For example, if you have a predictable load pattern where the number of workspaces increases during business hours and decreases during off-hours, you can use predictive scaling to adjust the number of worker nodes based on the expected load. This can help ensure that you have enough resources available to handle the peak load while minimizing costs during off-peak hours.

Tip
 Consider leveraging open-source solutions like Karpenter for configuration and lifecycle management of the worker nodes. Karpenter can dynamically provision and optimize worker nodes based on the specific requirements of the workloads, helping to improve resource utilization and reduce costs.

Multi-cluster

By design, Eclipse Che is not multi-cluster aware, and you can only have one instance per cluster. However, you can run Eclipse Che in a multi-cluster environment by deploying Eclipse Che in each different cluster and using a load balancer or DNS-based routing to direct traffic to the appropriate instance based on the user’s location or other criteria. This approach can help improve performance and reliability by distributing the workload across multiple clusters and providing redundancy in case of cluster failures.

One example of a multi-cluster architecture is workspaces.openshift.com, which is part of the Developer Sandbox.

From the infrastructure perspective, the Developer Sandbox consists of multiple ROSA clusters. On each cluster, the productized version of Eclipse Che is installed and configured using Argo CD. Since the user base is spread across multiple clusters, workspaces.openshift.com is used as a single entry point to the productized Eclipse Che instances. You can find implementation details about the multicluster redirector in the following GitHub repository.

Multi-cluster solution for running the productized version of Eclipse Che on the Developer Sandbox

Figure 2: Multi-cluster solution for running the productized version of Eclipse Che on the Developer Sandbox.

Tip
 The solution for workspaces.openshift.com is a Developer Sandbox-specific solution that can not be reused as-is in other environments. However, you can use it as a reference for implementing a similar solution well-tailored to your specific multicluster needs.

Conclusion

Running Eclipse Che at scale on Kubernetes presents unique challenges that require careful planning and consideration of various factors. By understanding the limitations of Kubernetes, accurately calculating resource requirements, and implementing best practices for managing etcd and OLM, you can build a robust and scalable CDE platform that meets the needs of your users. Additionally, leveraging predictive scaling and considering multicluster architectures can further enhance the performance and reliability of Eclipse Che deployments. By following these guidelines and continuously monitoring and optimizing the environment, you can provide a reliable and efficient CDE, ensure a seamless and efficient development experience for a large number of users while maintaining responsiveness, and prevent performance degradation of the cluster.

]]>Ilya BuziukWorking locally in the cloud: Develop in local Visual Studio Code with Eclipse Che as your Cloud Development Environment2025-02-27T00:00:00+00:002025-02-27T00:00:00+00:00https://che.eclipseprojects.io/2025/02/27/@vgulyy/use-desktop-visual-studio-code

Introduction

Eclipse Che provides developers with a web version of the Visual Studio Code OSS editor, which includes most features from the desktop version. The transition to cloud development can feel quite unusual for developers, but Eclipse Che has a feature that will help you feel right at home immediately. With Visual Studio Code Command Line Interface (CLI) you can create a tunnel that allows you to connect your local Visual Studio Code, an editor you may already be familiar with, to your workspace.

Connecting Visual Studio Code desktop to a new workspace

You can connect your local Visual Studio Code to a new workspace with a few clicks. First, create a workspace from the Che Dashboard and choose Visual Studio Code (desktop) as your editor.

Create Workspace

 

Wait for the login page to appear and log in with your Microsoft or GitHub account. Click the Copy & Continue to Microsoft or Copy & Continue to GitHub button to copy the authentication code to the clipboard and to open the authenticating pop-up.

Login with GitHub account

 

Complete the authentication process, paste the code from the clipboard, and follow the instructions. Upon successful authentication, close the pop-up and wait for the tunnel to your workspace to be created.

Tunnel to the workspace

 

Click Open in Visual Studio Code desktop to open your workspace in the desktop version of Visual Studio Code. Confirm opening the desktop application by clicking Open Visual Studio Code - URL Handler.

Open in Visual Studio Code desktop

 

Wait for the local Visual Studio Code to load and allow the Remote - Tunnels extension to open the URI.

Note

If Visual Studio Code opens your workspace with a delay, open the Remote Explorer view.

Connecting Visual Studio Code desktop to a running workspace

Prepare your local Visual Studio Code.

First, you need to install both Remote - Tunnels and Remote Explorer extensions to your local Visual Studio Code. It will allow you to connect to a remote machine via a secure tunnel.

Install Visual Studio Code CLI.

Next, you need to install Visual Studio Code CLI in your workspace. Open a terminal and run the following command to install Visual Studio Code CLI in the /checode directory.

curl 'https://code.visualstudio.com/sha/download?build=stable&os=cli-alpine-x64' --location -o /tmp/code.tar.gz && \
tar -xvzf /tmp/code.tar.gz --directory=/checode
Important

If you don’t have gzip installed in your workspace, you won’t be able to install the CLI using the command above.

In this case you need to:

  1. download CLI for Linux x64 architecture to your desktop

  2. unpack and upload the extracted binary to your workspace root

  3. move the binary to /checode directory and make it executable by mv $PROJECT_SOURCE/code /checode && chmod +x /checode/code

By placing the Visual Studio Code CLI binary in the /checode directory, it will persist even if the workspace is restarted.

Create a secure tunnel to the Cloud Development Environment.

Open the workspace terminal and launch the Visual Studio Code CLI with the command below.

/checode/code tunnel --accept-server-license-terms --name $DEVWORKSPACE_NAME

Log in using your Microsoft or GitHub account.

Create a secure tunnel to the workpace

After successful login, you will see the information about the created tunnel and will be prompted to open the workspace in your browser.

Open your workspace using local Visual Studio Code.

Open your local Visual Studio Code and navigate to the Remote Explorer view. A tunnel to your workspace will appear. With the buttons on the right, open your workspace in the current or a new window.

Open your workspace in local Visual Studio Code

 

Note

A tunnel to your workspace will not appear if you are not signed in yet. Sign in using the same account you used to create the tunnel.

You are now equipped to develop locally within a Cloud Development Environment.  
 
Happy coding!

]]>Vitaliy GulyyIn Kubernetes We Trust2024-11-26T00:00:00+00:002024-11-26T00:00:00+00:00https://che.eclipseprojects.io/2024/11/26/@ilya.buziuk/in-kubernetes-we-trust

Introduction

Last year, the "Pros and cons of using Kubernetes as a development platform" session was presented at EclipseCon in Ludwigsburg. The main message was that, indeed, Kubernetes is complex and sometimes there are caveats and tradeoffs to make, but it is evolving rapidly with plenty of new features and opportunities available with every release. Today it is time to reflect a bit more on this topic.

Building an application platform for developers

If you are considering building your own development platform it is recommended to read the brilliant “Production Kubernetes” book, where a multitude of potential options are described in great detail:

The multitude of options available to provide an application platform to developers

Figure 1: The multitude of options available to provide an application platform to developers.

Of course, you can always craft your own platform from scratch or even decide that the cloud, in general, is not your cup of tea and stop the Cloud Development Environment (CDE) journey right here since local development is good enough for your use-case and works “just fine”. Nevertheless, in Eclipse Che we strongly believe in the hybrid cloud strategy, and that Kubernetes is one of the best possible options for building a modern CDE platform for developers because of:

  • Extensibility

  • Scalability

  • Resource Efficiency

  • Consistency

  • High Availability

  • Control

  • Open Source

  • Community

  • Vendor Neutrality

  • Hybrid-Cloud Nature

However, there are a lot of subtle details worth considering when using Kubernetes as the pillar for building an application platform for developers. Some of them are described in the dedicated EclipseCon session mentioned in the introduction:

  • Networking

  • Storage

  • Immutability

  • Permissions

  • CPU Throttling

  • OOM Kill

  • Image Pulling

  • Image Building

In this article you can find a few more.

Namespaces

While there is no strict limit on the number of namespaces in a Kubernetes cluster, having more than 10,000 is generally not recommended due to potential performance and management overhead. In Eclipse Che for instance, each user is allocated a namespace. If you expect the user base to be large, consider spreading workloads across multiple clusters and potentially leveraging solutions for multi-cluster orchestration.

GitOps

Do NOT manage the Kubernetes clusters manually otherwise you will end up with a snowflake environment. Application definitions, configurations, and environments should be declarative and version controlled. Application deployment and lifecycle management should be automated, auditable, and easy to understand. Using a GitOps CD solution for Kubernetes such as Argo CD is a must-have when managing a complex application platform for developers.

Root Access

Containers running as root on a cluster are a major security risk since they significantly increase the attack surface, potentially allowing root access over the host node. That is the main reason why the containers on OpenShift are running using Arbitrary User IDs by default. This approach provides additional security against processes escaping the container due to a container engine vulnerability, thereby achieving escalated permissions on the host node. This basic principle applies to CDEs as well. It might look like a trade-off between security and usability, when users cannot easily install OS-scoped packages in the runtime. However, dynamically installing packages in a running workspace is an anti-pattern - containers are supposed to be immutable, and installing anything inside a running container is not recommended since all the packages will vanish after the restart. There is also the added benefit of maintaining workspace consistency across different users by adhering to the immutable principle for container images used in the CDE.

emptyDir Volumes

Volume mounting could be by far the most time-consuming operation during pod startup. Consider leveraging ephemeral workloads whenever relevant which are using emptyDir volumes under the hood. In the context of Eclipse Che, those are ephemeral workspaces that could be particularly useful for developer routines like code review, with the dedicated storage type defined on the devfile level:

schemaVersion: 2.3.0
metadata:
  generateName: quarkus-api-example
attributes:
  controller.devfile.io/storage-type: ephemeral

Cluster Autoscaling

Although Cluster Autoscaling is a powerful Kubernetes feature, you cannot always fall back on it and should always consider predictive scaling by analyzing load data on your environment to detect daily or weekly usage patterns. If your workloads follow a pattern and there are dramatic peaks throughout the day you should consider provisioning worker nodes accordingly (e.g. a lot of users turn on their smart speakers in the morning between 7 - 9 a.m. causing a huge spike in requests that can be predicted and handled in advance on the infrastructure level).

CPU Limits

Setting CPU Limits in general is a contended topic for production workloads, since If you apply them the workloads are throttled by definition. Limits for CPU for soft-tenancy pods are probably not going to be helpful unless you are approaching very dense setups (> 10 pods per core) - otherwise, you will waste more CPU by throttling than you save. CPU Limits definitely increase tail latencies for most non-predictable workloads (almost all request-driven use cases) in a way that will result in a worse overall application environment for most users most of the time (because of how limits are sliced). At lower pods per core, you are almost certainly trading a false security for a worse quality of service for the workloads you are running on Kubernetes.

CPU Limits are most useful when dealing with bad actors on your own platform, and even then, there are far more effective ways of dealing with bad actors like detection and account blocking. However, in the case of CDEs, you may consider applying the limits on the namespace level to prevent developers from accidentally saturating a compute node. If you apply limits, you must make sure the limits are high enough to allow normal bursts of CPU usage during the inner-loop activities. Otherwise, developers may experience unexpected performance issues during CPU-intensive activities.

Ephemeral Containers

Ephemeral Containers is a great example of how Kubernetes features are providing new opportunities for building application platforms for developers every release. Last year we talked about Ephemeral Containers at EclipseCon as a potential new opportunity for Cloud Development Environments. This year a kubectl plugin for debugging Kubernetes pods from a CDE, rather than the CLI has been presented at KubeCon.

Dynamic Resource Allocation (DRA)

Dynamic Resource Allocation (DRA) is yet another striking example of how Kubernetes features are providing new opportunities for developers with every release. With the push for GPU-centric applications, DRA was presented all throughout the last KubeCon North America 2024. It speaks to the popularity of AI-related workloads that require specific resources, and while today DRA mostly targets GPUs, it is very well possible that one day we will be talking about DRA for everything from CPUs and memory to customized hardware accelerators in the future.

Release Notes

To maximize the potential of your Kubernetes-based developer platform, consistently review the Release Notes. They offer a treasury of opportunities for innovative features, performance enhancements, optimizations, recommended configurations, best practices, and strategic planning based on future roadmap insights.

Adoption

For the last few years, we have seen a spike in the adoption of Eclipse Che and the downstream product Red Hat OpenShift Dev Spaces built on top of it. Multiple success stories when the Kubernetes-based platform for provisioning CDEs to enterprise teams is deployed across public, private, and hybrid environments motivate and encourage us every day. Here are just a few public references:

  • EPAM Systems deploys Eclipse Che on Azure Kubernetes Service (AKS).

  • Ford Motor Company uses fit-for-purpose OpenShift clusters and a dedicated Kubernetes Operator for managing CDEs.

  • Capgemini accelerates digital service development for the Federal Information Technology Center (ITZBund) using Red Hat OpenShift Dev Spaces Operator in combination with NVIDIA vGPU Operator for managing CDEs in the 100% air-gapped environment, isolated from the internet.

Conclusion

We trust in Kubernetes and do believe in the hybrid cloud. Open Source is in our DNA.

]]>Ilya BuziukBoosting CDE Security in a Kubernetes cluster: A Guide to new features2024-10-28T00:00:00+00:002024-10-28T00:00:00+00:00https://che.eclipseprojects.io/2024/10/28/@tolusha/boosting-cde-security-on-kubernetes-cluster

Introduction

As organizations transition to cloud-native development, maintaining control, security, and flexibility in development environments becomes critical. Eclipse Che is a powerful Kubernetes-native IDE that offers administrators tools for ensuring security and resource efficiency. In this post, we’ll look at three new Eclipse Che features that improve security and resource control in your development environments.

Limiting the Number of Simultaneous Workspaces

Effective resource management is critical in cloud-based environments, as uncontrolled workspace development can quickly deplete resources and degrade system performance. To mitigate this risk, Eclipse Che now has a functionality that restricts the amount of running workspaces per cluster.

Administrators can use this feature to limit the amount of workspaces that can run at the same time, reducing resource misuse, supporting fair allocation of resources among teams, and increasing overall efficiency.

In the example below, we set the maximum number of running workspaces per cluster to 20:

kubectl patch checluster/eclipse-che \
  --namespace eclipse-che \
  --type='merge' -p \
    '{"spec":
        {"devEnvironments":
          {"maxNumberOfRunningWorkspacesPerCluster": 20}
        }
     }'

If a user exceeds the workspace limit, they will receive a warning message during workspace startup: "Exceeded the cluster limit for running DevWorkspaces"

Exceeded the cluster limit for running DevWorkspaces

 

To learn more about configuring workspace limits, follow the Eclipse Che documentation.

Untrusted Repository Warning

It is not recommended to create workspaces from unknown or untrusted repositories automatically. When a user tries to create a workspace in Eclipse Che, a warning window appears on the dashboard, requesting confirmation that they trust the repository before proceeding.

URL is not permitted for creating a workspace

 

Configuring Allowed URLs

This feature ensures that developer workspaces can only be launched from pre-approved, secure URLs. Organizations can prevent workspaces from being started with unwanted URLs by creating a allowlist of trusted domains.

In the example below, we configure the allowed URLs to only permit connections to GitLab:

kubectl patch checluster/eclipse-che \
    --namespace eclipse-che \
    --type='merge' \
    -p \
        '{
           "spec": {
             "devEnvironments": {
               "allowedSources": {
                 "urls": ["https://gitlab.com/*"]
               }
             }
           }
         }'

If a user attempts to create a workspace with a URL other than GitLab, they will receive an error message: "URL is not permitted for creating a workspace".

URL is not permitted for creating a workspace

 

To learn more about configuring allowed URLs, follow the Eclipse Che documentation.

Conclusion

Eclipse Che’s new security features, such as limiting simultaneous workspaces and configuring allowed URLs, give administrators greater control over resource usage and workspace security in cloud-native environments. Implementing these updates allows organizations to improve the efficiency and safety of their development workflows, resulting in a secure and well-regulated workspace.

]]>Anatolii BazkoWriting documentation in Eclipse Che2024-08-09T00:00:00+00:002024-08-09T00:00:00+00:00https://che.eclipseprojects.io/2024/08/09/@deerskindoll/writing-docs-with-che

The quick and easy way to create documentation

With Eclipse Che, writing technical documentation is even easier than you think. Let’s use the Eclipse Che documentation repository on GitHub. The che-docs repository was created with community contribution in mind, featuring tools you need to create and test your content. And from the initial draft to submitting a PR, everything is happening in the environment you’re already familiar with: an Eclipse Che cloud development environment (CDE).

An Eclipse Che CDE created from the che-docs repository.
Figure 1. An Eclipse Che CDE created from the che-docs repository.

Getting started

Click the Developer Workspace button in the che-docs repository README file. This opens a clone of the repository in an Eclipse Che workspace hosted by Red Hat in the Developer Sandbox. Alternatively, you can click right here:

contribute

How does it work?

What about the che-docs repository makes using an Eclipse Che CDE to contribute content so convenient? The following two elements:

Let’s look at the devfile first. The che-docs repository contains a simple devfile that defines the basic features of the che-docs workspace. It also includes a command for building a preview of your newly created content:

# sh tools/preview.sh

This is helpful not only for checking the layout of the document but also for making sure that embedded images, links and code blocks are displayed correctly. Additionally, the preview script features a Vale-based grammar check you can also use separately. More about this in a moment.

By default, the che-docs workspace launches with Visual Studio Code - Open Source ("Code - OSS") as the IDE. This is relevant for the second file mentioned above. The che-docs repository features an extensions.json file listing Visual Studio Code extensions you need for writing Eclipse Che content. When you launch the che-docs workspace for the first time, these extensions are installed automatically:

Overview of automatically installed extensions, including the Vale extension.
Figure 2. Overview of automatically installed extensions, including the Vale extension.

You can start working immediately, with minimal additional setup required.

Getting started

By launching the che-docs workspace, you’re almost ready to go:

  • You have a clone of the che-docs repository

  • You have an IDE to write in.

  • You have required extensions installed.

  • You have a preview build script.

There are only three things left to do.

  1. Read the contribution guidelines.

  2. Read how to document commands for Eclipse Che documentation.

  3. Update the grammar- and spelling-checking Vale extension by running the vale-sync command defined in the devfile or directly execute it in the terminal:

    # vale sync
Note

The Vale extension included in the che-docs repository follows the grammatical, spelling and stylistic rules from the Red Hat supplementary style guide.

Writing tips

A good technical document is easy to read and easy to follow. Here are a few tips that will help you write great technical content:

  • Keep it simple. Avoid self-referential language ("this article is about…​"), overly long introductions, and deep-dives into the feature’s history.

  • Keep it accessible. Short paragraphs, sentences and words make your content easy to read.

  • Keep the focus on the user. Write the content around what the user can achieve when they follow your instructions.

  • Keep passive voice to a minimum.

The famous opening lines of Jane Austen’s Pride and Prejudice novel don’t follow any of the writing tips listed in this blog post. At grade 16, they also have a very high readability score in the Hemingway Editor. Your technical document should have a readability score between grade 9 and 11.
Figure 3. The famous opening lines of Jane Austen’s Pride and Prejudice novel don’t follow any of the writing tips listed in this blog post. At grade 16, they also have a very high readability score in the Hemingway Editor. Your technical document should have a readability score between grade 9 and 11.

If you want to learn more about technical writing in general, check out the Google developer documentation style guide. The readability test is a part of the Hemingway Editor.

Happy writing!

]]>Jana Vrbkova