Enabling the managed Open VSX registry

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-extensions ConfigMap in the Che namespace. Add extension .vsix download URLs, one per line:

    kubectl edit configmap openvsx-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.

Configuring 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.

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": {
              "credentialsSecretName": "<secret_name>"
            }
          }
        }
      }'
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.

Customizing 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.

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.

Deleting 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.

Disabling 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.

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.