RHDH 1.9 turns community plugins into a registry-planning problem

Red Hat Developer Hub 1.9 changed where a large part of its plugin surface lives. Community-supported plugins that were previously wrapped inside the RHDH application image are now independent OCI artifacts served from ghcr.io. Red Hat’s verified support note says the practical symptom is an install-dynamic-plugins init container that cannot start because it times out while fetching package metadata. (Red Hat Customer Portal)

What moved outside the image

The 1.9 migration table maps 40 community-plugin artifacts from local ./dynamic-plugins/dist/... paths to oci://ghcr.io/redhat-developer/rhdh-plugin-export-overlays/...:<tag> references. (Dynamic plugins reference)

The affected set spans the integration surface platform teams are likely to enable:

• Delivery and source control: Argo CD frontend/backend; Azure DevOps frontend/backend, annotator, search and scaffolder modules; Bitbucket Cloud and Server catalog/scaffolder modules; GitHub Actions, Issues, Insights and Pull Requests; GitLab frontend/backend; Jenkins frontend/backend/scaffolder; Gerrit scaffolder.
• Operations and security: Datadog, Dynatrace, Lighthouse frontend/backend, PagerDuty frontend/backend and Security Insights.
• Artifact and code quality: JFrog Artifactory, Nexus Repository Manager, Quay backend and SonarQube frontend/backend plus its scaffolder module.
• Platform services: 3scale, Jira, ServiceNow and the DotNet and utility scaffolder modules.

That is the key boundary change: the core product image no longer carries these extensions, even when dynamic-plugins.default.yaml still describes them. Red Hat’s 1.9 release notes direct air-gapped users to add the OCI images they use to their mirroring workflow. (RHDH 1.9 release notes)

Choose allowlisting or mirroring

For a restricted cluster with controlled outbound access, the smaller operational change is to permit pulls from ghcr.io and update plugin configuration from the old local path to the exact OCI reference and tag in Red Hat’s migration table. This keeps GHCR in the runtime dependency chain, so it is unsuitable where external access is prohibited. (Dynamic plugins reference)

For a partially disconnected environment, Red Hat documents mirror-plugins.sh: mirror the 1.9 plugin catalog or a selected list directly into an internal registry, then replace the plugin references in the Backstage custom resource or Helm values. The script produces rhdh-plugin-mirroring-summary.txt with source-to-mirror mappings. (Installation guide)

For a fully air-gapped site, use the documented two-stage flow: export the catalog artifacts to disk on a connected host, transfer them across the boundary, then import them into the internal registry. The same guide also supports mirroring only explicit plugin URLs or a file containing one URL per line, which avoids importing a catalog larger than the approved plugin set. (Installation guide)

The upgrade check is therefore concrete: inventory enabled community plugins, match each to the migration table, choose direct GHCR access or an internal mirror, update every package reference, and verify the init-container logs before promoting RHDH 1.9.