Enable the managed Open VSX registry

The managed Open VSX registry is a Technology Preview feature only. Technology Preview features are not supported with Red Hat production service level agreements (SLAs) and might not be functionally complete. Red Hat does not recommend using them in production. These features provide early access to upcoming product features, enabling customers to test functionality and provide feedback during the development process. For more information about the support scope of Red Hat Technology Preview features, see https://access.redhat.com/support/offerings/techpreview/.

Enable Che to deploy and manage a dedicated Open VSX server with a PostgreSQL database as Operator-managed components. The managed registry is exposed through the Che gateway and provides a private, curated extension registry without requiring manual deployment or database administration.

When enabled, the Che Operator creates the following resources:

  • An Open VSX server Deployment with a PersistentVolumeClaim for extension storage.

  • A PostgreSQL database Deployment with a PersistentVolumeClaim for data.

  • A one-shot Job to provision the database with the required user and access token.

  • A ConfigMap for listing extensions to publish to the registry.

When disabled, the Operator removes all managed Open VSX resources.

Prerequisites
  • An active kubectl session with administrative permissions to the destination Kubernetes cluster. See Overview of kubectl.

Procedure
  1. Enable the managed Open VSX registry by patching the CheCluster custom resource:

    kubectl patch checluster eclipse-che \
      --namespace eclipse-che \
      --type merge \
      --patch '{
        "spec": {
          "components": {
            "openVSXRegistry": {
              "enable": true
            }
          }
        }
      }'

    The Operator deploys the Open VSX server and PostgreSQL database, provisions the database, and exposes the registry through the Che gateway.

    The managed registry starts empty with no pre-installed extensions. You must publish extensions to the registry after enabling it.
  2. Optional: Configure the server storage size by setting the claimSize field. The default is 3Gi.

    kubectl patch checluster eclipse-che \
      --namespace eclipse-che \
      --type merge \
      --patch '{
        "spec": {
          "components": {
            "openVSXRegistry": {
              "server": {
                "pvc": {
                  "claimSize": "<size>"
                }
              }
            }
          }
        }
      }'

    where <size> is the required storage size. For example: 5Gi.

  3. Optional: Configure the database storage size. The default is 1Gi.

    kubectl patch checluster eclipse-che \
      --namespace eclipse-che \
      --type merge \
      --patch '{
        "spec": {
          "components": {
            "openVSXRegistry": {
              "database": {
                "pvc": {
                  "claimSize": "<size>"
                }
              }
            }
          }
        }
      }'
  4. Optional: Publish extensions to the managed registry by editing the openvsx-server-extensions ConfigMap in the Che namespace. Add extension .vsix download URLs, one per line:

    kubectl edit configmap openvsx-server-extensions \
      --namespace eclipse-che

    The Operator automatically runs a publishing Job when the ConfigMap content changes.

Verification
  • Verify that the Open VSX server and database pods are running:

    kubectl get pods --namespace eclipse-che -l app.kubernetes.io/component=openvsx-server
    kubectl get pods --namespace eclipse-che -l app.kubernetes.io/component=openvsx-database
  • Access the Open VSX registry UI by navigating to https://<che_host>/openvsx in a browser, where <che_host> is the hostname of your Che instance. You can retrieve the URL from the CheCluster status:

    kubectl get checluster eclipse-che \
      --namespace eclipse-che \
      -o jsonpath='{.status.openVSXURL}'
  • Open a workspace and verify that extensions from the managed registry are available in the Extensions view.

Configure custom credentials for the managed Open VSX registry

By default, the Operator generates an openvsx-credentials secret with random passwords and access tokens. To use custom database credentials and Open VSX user accounts, create a secret and reference it in the CheCluster custom resource.

The secret must exist before it is referenced in the CheCluster custom resource. The Operator validates the secret on create and update and rejects the change if the secret is missing or incomplete.

Prerequisites
  • An active kubectl session with administrative permissions to the destination Kubernetes cluster. See Overview of kubectl.

Procedure
  1. Create a secret with the required credentials:

    kubectl create secret generic <secret_name> \
      --namespace eclipse-che \
      --from-literal=database-user=<db_user> \
      --from-literal=database-password=<db_password> \
      --from-literal=database-name=<db_name> \
      --from-literal=openvsx-publisher-name=<publisher_name> \
      --from-literal=openvsx-publisher-token=<publisher_token> \
      --from-literal=openvsx-admin-name=<admin_name> \
      --from-literal=openvsx-admin-token=<admin_token>
    kubectl label secret <secret_name> \
      --namespace eclipse-che \
      app.kubernetes.io/part-of=che.eclipse.org

    The secret must contain all of the following keys:

    Key Description

    database-user

    PostgreSQL username.

    database-password

    PostgreSQL password.

    database-name

    PostgreSQL database name.

    openvsx-publisher-name

    Login name of the Open VSX publisher account with the privileged role.

    openvsx-publisher-token

    Personal access token for the publisher account.

    openvsx-admin-name

    Login name of the Open VSX admin account.

    openvsx-admin-token

    Personal access token for the admin account.

  2. Reference the secret in the CheCluster custom resource:

    kubectl patch checluster eclipse-che \
      --namespace eclipse-che \
      --type merge \
      --patch '{
        "spec": {
          "components": {
            "openVSXRegistry": {
              "enable": true,
              "credentialsSecretName": "<secret_name>"
            }
          }
        }
      }'
Verification
  1. Verify that the Open VSX server pod is running:

    kubectl get pods --namespace eclipse-che -l app.kubernetes.io/component=openvsx-server
  2. Verify that the custom credentials are injected as environment variables in the Open VSX server pod:

    kubectl exec deploy/openvsx-server \
      --namespace eclipse-che -- \
      env | grep -E 'OPENVSX_ADMIN_PAT|OPENVSX_USER_PAT'

    The output should include OPENVSX_ADMIN_PAT and OPENVSX_USER_PAT.

  3. Verify that the database pod uses the custom credentials:

    kubectl exec deploy/openvsx-database \
      --namespace eclipse-che -- \
      env | grep -E 'POSTGRESQL_'

Customize the Open VSX server configuration

The Operator creates an openvsx-server ConfigMap with a default application.yml configuration when the managed registry is first enabled. This ConfigMap is user-editable: the Operator creates it once and does not overwrite subsequent changes. Modifying the ConfigMap automatically triggers a rolling restart of the Open VSX server pod.

Prerequisites
  • An active kubectl session with administrative permissions to the destination Kubernetes cluster. See Overview of kubectl.

  • The managed Open VSX registry is enabled and running.

Procedure
  1. Edit the openvsx-server ConfigMap:

    kubectl edit configmap openvsx-server \
      --namespace eclipse-che

    The ConfigMap contains a single application.yml key with the Open VSX Spring Boot configuration.

Verification
  • Verify that the Open VSX server pod has restarted with the updated configuration:

    kubectl get pods --namespace eclipse-che -l app.kubernetes.io/component=openvsx-server

Delete extensions from the managed Open VSX registry

Delete individual extensions or specific extension versions from the managed Open VSX registry by using the Open VSX admin API.

Prerequisites
  • An active kubectl session with administrative permissions to the destination Kubernetes cluster. See Overview of kubectl.

  • The managed Open VSX registry is enabled and running.

Procedure
  1. Get the Open VSX server pod name:

    kubectl get pods --namespace eclipse-che -l app.kubernetes.io/component=openvsx-server -o name
  2. Delete an entire extension with all its versions:

    kubectl exec <openvsx_server_pod> \
      --namespace eclipse-che -- \
      sh -c 'curl -X POST "http://openvsx-server:8080/openvsx/admin/api/extension/<extension_namespace>/<extension_name>/delete?token=$OPENVSX_ADMIN_PAT"'

    where:

    <openvsx_server_pod>

    The pod name from the previous step.

    <extension_namespace>

    The namespace (publisher) of the extension. For example: redhat.

    <extension_name>

    The name of the extension. For example: java.

  3. Alternatively, to delete only a specific version of an extension:

    kubectl exec <openvsx_server_pod> \
      --namespace eclipse-che -- \
      sh -c 'curl -X POST -H "Content-Type: application/json" \
      -d '"'"'[{"version": "<extension_version>"}]'"'"' \
      "http://openvsx-server:8080/openvsx/admin/api/extension/<extension_namespace>/<extension_name>/delete?token=$OPENVSX_ADMIN_PAT"'

    where <extension_version> is the version to delete. For example: 1.2.3.

Verification
  • Open the Open VSX registry UI and verify that the deleted extension is no longer listed.

Disable the managed Open VSX registry

Disable the managed Open VSX registry to remove the Open VSX server, PostgreSQL database, and all associated resources from the namespace.

Prerequisites
  • An active kubectl session with administrative permissions to the destination Kubernetes cluster. See Overview of kubectl.

Procedure
  1. Set the enable field to false:

    kubectl patch checluster eclipse-che \
      --namespace eclipse-che \
      --type merge \
      --patch '{
        "spec": {
          "components": {
            "openVSXRegistry": {
              "enable": false
            }
          }
        }
      }'

    The Operator removes all managed Open VSX resources, including deployments, services, persistent volume claims, and secrets.

Verification
  • Verify that no Open VSX pods remain in the namespace:

    kubectl get pods --namespace eclipse-che -l app.kubernetes.io/component=openvsx-server
    kubectl get pods --namespace eclipse-che -l app.kubernetes.io/component=openvsx-database