Enhancements
New chectl workspace commands for managing and connecting to DevWorkspaces
Before this update, managing DevWorkspaces and connecting to them over SSH required a separate devspaces-cli-connector application outside of chectl.
With this update, a workspace command group is built into chectl. The workspace init, list, create, start, stop, and delete commands manage DevWorkspaces directly from the CLI, and each command accepts an --auth flag to authenticate against the cluster beforehand. A workspace connect command establishes an SSH connection, with port forwarding, to a DevWorkspace that uses the Visual Studio Code (desktop) (SSH) editor. A workspace register-url-handler command registers a che:// URL handler so links can open directly in the connected CLI.
As a result, developers can manage and connect to DevWorkspaces without installing a separate tool.
Select Orca as a workspace editor
Before this update, Orca was not available as an editor option when creating a workspace.
With this update, an editor definition for Orca, an agent development environment for Eclipse Che provided by Stably AI under the MIT License, is available in the editor selection list.
As a result, developers can start a workspace with Orca to work with AI coding agents alongside their project.
Secure workspace networking and preserve external labels with DevWorkspace Operator 1.0.0
DevWorkspace Operator 1.0.0 introduces optional per-workspace NetworkPolicy provisioning, OpenShift-aware TLS configuration for the metrics and webhook servers, support for external labels and annotations on workspace deployments, and a fix for backup and restore on multi-node clusters.
.Optional per-workspace NetworkPolicy provisioning
Administrators can enable a NetworkPolicy for each workspace through DevWorkspaceOperatorConfig to control ingress and egress traffic. The feature is disabled by default, so existing clusters are unaffected until an administrator opts in.
.OpenShift-aware TLS configuration for metrics and webhook servers
On OpenShift clusters, the operator now retrieves TLS security profiles from the API server and applies them to the metrics and webhook servers, restarting them automatically when the profile changes. Kubernetes deployments are unaffected.
.External labels and annotations are preserved on workspace deployments
Labels and annotations added by admission webhooks or platform tooling to a workspace deployment are now preserved across reconciliation cycles instead of being removed. Labels and annotations managed by DevWorkspace Operator are still corrected if modified.
.Backup and restore no longer fails on multi-node clusters
Backup jobs for per-user common storage are now pinned to the node where the shared persistent volume claim is mounted, preventing multi-attach errors on multi-node clusters.
For the full list of changes, see the DevWorkspace Operator changelog.
Bug fixes
Publishing large extensions no longer crashes the built-in Open VSX registry
Before this update, publishing an extension of around 250 MB could cause the openvsx-server pod to fail with an OOMKilled error. The maximum heap size equaled the container memory limit, leaving no headroom for JVM non-heap memory or page cache, so the extension version remained permanently inactive and could not be republished.
With this update, the Open VSX server deployment requests 1Gi of memory and is limited to 4Gi, providing enough headroom to publish large extensions successfully.
As a result, publishing extensions around 250 MB no longer crashes the pod.
If an extension version is already stuck in an inactive state from before this fix, purge it through the Open VSX admin API before republishing. Deleting the version instead of purging it leaves a permanent tombstone that blocks republishing under the same version number.
Forcing a new workspace from a git URL no longer ignores the devfile path parameter
Before this update, query parameters appended to a Git URL in the Import from Git field could be dropped silently. Adding ?new to force a new workspace stopped working when one already existed for the repository, and the lowercase devfilepath parameter was not recognized, so the factory resolver fell back to the default devfile instead of the one specified in the URL.
With this update, the dashboard recognizes devfilepath alongside the existing devfilePath and df parameters in both the factory path builder and the Import from Git helpers. When a URL includes both devfilePath and devfilepath, devfilePath takes precedence, and the stored link is normalized to the canonical spelling.
As a result, developers can reliably force a new workspace and point it to a specific devfile when importing from a Git URL, regardless of parameter capitalization.
Mounting Secrets or ConfigMaps as subpath no longer causes endless Deployment updates
Before this update, mounting a Secret or ConfigMap with controller.devfile.io/mount-as: subpath that held more than one key caused the operator to repeatedly update Deployments (such as che-dashboard), spawning many ReplicaSets. The volume mounts were generated from an unordered map, so their order changed on every reconcile and the operator saw a difference each time.
With this update, keys are iterated in sorted order so the generated VolumeMounts are stable, the container image pull policy is preserved unless explicitly overridden, and resource override maps are initialized safely.
As a result, Deployments are no longer updated in a loop and excess ReplicaSets are no longer created.