Procedure

1. In the Administrator perspective of the OpenShift Container Platform web console, click Operators > Installed Operators.
2. On the Installed Operators page, click Red Hat Developer Hub Operator.
3. On the Red Hat Developer Hub Operator page, click the Subscription tab.

4. From the Upgrade status field on the Subscription details page, click Upgrade available.

   Note

   If there is no upgrade available, the Upgrade status field value is Up to date.

5. On the InstallPlan details page, click Preview InstallPlan > Approve.

   Important

   If you are on the Orchestrator plugin 1.7, you must manually update the plugin configuration after approval to avoid a failed deployment. For more information, see Upgrading the Orchestrator plugin from 1.7 to 1.10.

Procedure

1. OpenShift Container Platform web console

   Warning

   If you have installed Developer Hub manually using the Helm CLI, the Helm chart release upgrade in the OpenShift Container Platform web console is going to fail. The failure is due to the limitations when using the OpenShift Container Platform console to upgrade a Helm release that was initially deployed using the Helm CLI. You can bypass this limitation by using the Helm CLI to upgrade. However, if you still want to upgrade using the console, select the Helm Chart version from the drop-down list and select the Developer Hub version you want to upgrade to. Before performing this step, save your values.yaml configuration file in a different location.

   Important

   You can upgrade Red Hat Developer Hub directly from any earlier version to the latest release without installing intermediate versions. Before upgrading, you must review the release notes for every skipped version to identify breaking changes, deprecations, or required migration steps. For example, if upgrading from version 1.5 to 1.7, check the release notes for both 1.6 and 1.7.

2. In the Developer perspective, click Helm to open the Helm Releases tab.
3. Click the overflow menu on the Helm release that you want to use and select Upgrade.
4. On the Upgrade Helm Release page, select the version of Developer Hub that you want to upgrade to from the chart version drop-down list.

5. Click Upgrade.

   Note

   It might take a few minutes to delete the resources in the older versions and to start the newer versions of the Developer Hub pods.

6. Close all open Developer Hub web pages, and log in again to verify that the upgrade was successful.
7. OpenShift Container Platform CLI

8. Log in to the OpenShift Container Platform cluster as the cluster administrator and switch to the project or namespace where you installed Developer Hub.

   $ oc login -u <user> -p <password> https://api.<HOSTNAME>:6443
   $ oc project my-rhdh-project

9. For a new version of the Developer Hub Helm chart, run the following upgrade command:

   $ helm upgrade -i rhdh -f new-values.yml \
     openshift-helm-charts/redhat-developer-hub --version 1.10.1

   Note

   You can also give extra values to the chart by creating a new-values.yml file on your workstation with values that override the attributes in the installed chart or by adding new attributes.

Procedure

1. In your dynamic-plugins.yaml file, identify the plugin entry that uses the {{inherit}} tag or the version you want to roll back.

2. List the available version tags for the plugin image:

   $ skopeo list-tags docker://<plugin_image>

   where:

   <plugin_image>

   The OCI image path without the tag or digest. For example, registry.access.redhat.com/rhdh/backstage-community-plugin-topology or ghcr.io/redhat-developer/rhdh-plugin-export-overlays/backstage-community-plugin-tech-radar.

3. Get the SHA256 digest for the version tag you want to roll back to:

   $ skopeo inspect docker://<plugin_image>:<tag> | jq '.Digest'

   where:

   <tag>

   Enter your RHDH version of Backstage and the plugin version, in the format bs_<backstage-version>__<plugin-version> (note the double underscore delimiter). To find these versions, complete the following steps:

   1. Find your Backstage version in the RHDH release notes preface.

   2. Locate the plugin version in the Dynamic Plugins Reference guide. For example, for RHDH 1.9 based on Backstage 1.45.3, use the format bs_1.45.3__<plugin-version>.

      Tip

      To ensure environment stability, use a SHA256 digest instead of a version tag. See Determining SHA256 Digests.

4. In your dynamic-plugins.yaml file, replace the {{inherit}} tag or current version with the pinned digest:

   plugins:
     - package: oci://<plugin_image>@<digest>
       disabled: false

   where:

   <digest>

   The SHA256 digest value returned by the skopeo inspect command. For example, sha256:28036abec4dffc714394e4ee433f16a59493db8017795049c831be41c02eb5dc.

5. Apply the configuration change:

   1. If you deployed RHDH by using the Operator, update your Backstage custom resource (CR).
   2. If you deployed RHDH by using the Helm chart, update your Helm chart values and run the helm upgrade command.
6. Restart the RHDH application.

Verification

1. Check the Developer Hub application logs to confirm the plugin loaded at the expected version.
2. Verify the plugin behavior in the Developer Hub web console.

Procedure

1. Open a terminal and change to the directory that contains your RHDH configuration files.

2. Start the upgrade helper as a Claude Code slash command. Provide each configuration file with a separate --config flag. The skill auto-detects the file type from the file content, so Helm values files, app-config files, dynamic plugins files, and Backstage CR files all use the same --config flag:

   /rhdh-upgrade-helper \
     --from <current_version> \
     --to <target_version> \
     --config app-config.yaml \
     --config dynamic-plugins.yaml

   Replace <current_version> with your installed RHDH version (for example, 1.8) and <target_version> with the version you are upgrading to (for example, 1.10).

3. Optional: Instead of the slash command, start the skill by describing your upgrade in natural language. Claude Code detects the request and runs the skill. For example:

   • Analyze my values.yaml for upgrading from RHDH 1.8 to 1.10
   • What breaks if I upgrade to RHDH 1.10?

4. Optional: If your configuration files are collected in a directory, use --config-path to scan all files in that directory at once:

   /rhdh-upgrade-helper \
     --from <current_version> \
     --to <target_version> \
     --config-path ./my-configs/

5. Optional: If you have additional individual configuration files relevant to your deployment, provide them by repeating the --config flag:

   /rhdh-upgrade-helper \
     --from 1.5 \
     --to 1.9 \
     --config app-config.yaml \
     --config app-config.production.yaml \
     --config dynamic-plugins.yaml

6. Optional: To avoid re-entering flags on every run, create a .rhdh-upgrade-helper.yaml file in your working directory and define all inputs there:

   from: "1.8"
   to: "1.10"
   configs:
     - ./values.yaml
     - ./app-config.yaml
     - ./dynamic-plugins.yaml

   When this file is present, run the skill with no flags:

   /rhdh-upgrade-helper

   Note

   If you run /rhdh-upgrade-helper without passing --config or --config-path flags and without a .rhdh-upgrade-helper.yaml file in the current directory, the skill enters interactive mode and asks intake questions to build an environment profile. Providing configuration files is therefore optional; you can rely on interactive mode if you prefer.

7. Review the predicted-issues report that the skill writes to your terminal. The report lists each issue in priority order. Address the issues listed before starting the upgrade.

Verification

1. The skill produces a prioritised report in your terminal that lists predicted breaking changes, configuration drift, and plugin compatibility issues for your specified upgrade path.
2. If the skill detects that you are not using Red Hat Developer Hub Local (RHDH Local), it recommends using it to validate your configuration against the target version in a cluster-free environment before upgrading production.