Release notes


Red Hat Developer Hub 1.4

Release notes for Red Hat Developer Hub 1.4

Red Hat Customer Content Services

Abstract

Red Hat Developer Hub is a developer platform for building developer portals. This document contains release notes for the Red Hat Developer Hub 1.4.

Preface

Red Hat Developer Hub (Developer Hub) 1.4 is now generally available. Developer Hub is a fully supported, enterprise-grade productized version of upstream Backstage v1.32.6. You can access and download the Red Hat Developer Hub application from the Red Hat Customer Portal or from the Ecosystem Catalog.

Chapter 1. New features

This section highlights new features in Red Hat Developer Hub 1.4.

1.1. Added an individual mountPath

This update adds an individual mountPath for extra ConfigMaps or Secrets.

1.2. PersistentVolumeClaims support is available

With this update, PersistentVolumeClaims (PVC) support is available.

1.3. Enhanced use of kube-rbac-proxy

This update removes the kube-rbac-proxy sidecar container from the RHDH Operator Pod. This sidecar container protected the operator metrics endpoint. However, the main container now provides this functionality out-of-the-box. Removing this sidecar container allows for reducing the resources required to run the Operator.

1.4. Identifying Backstage flavor for plugins by using the developerHub.flavor field

With this update, you can use the developerHub.flavor field to identify whether plugins are running on RHDH, RHTAP, or vanilla Backstage, as shown in the following example:

app-config.yaml fragment with the developerhub.flavor field

developerHub:
  flavor: <flavor>

flavor
Identify the flavor of Backstage that is running. Default value: rhdh

1.5. Ability to manage Persistent Volume Claim (PVCs) in RHDH Operator

You can now mount directories from pre-created PersistentVolumeClaims (PVCs) using the spec.application.extraFiles.pvcs field, while configuring RHDH Operator. For more information, see Configuring Red Hat Developer Hub deployment when using the Operator.

1.6. Authenticating with Red Hat Build of Keycloak

With this update, you can use Red Hat Build of Keycloak as an authentication provider. The Keycloak plugin will now support ingesting users and groups with Red Hat Build of Keycloak. For more details, see Authenticating with Red Hat Build of Keycloak.

1.7. Ability to install third-party plugins in RHDH

You can now install third-party plugins in Red Hat Developer Hub without rebuilding the RHDH application.

For more information, see Installing third-party plugins in Red Hat Developer Hub.

1.8. The catalog backend module logs plugin is enabled

With this update, the backstage-plugin-catalog-backend-module-logs is enabled and converted to a static plugin improving performance and stability. The dynamic plugin was disabled in version 1.3.

1.9. Google Kubernetes Engine now supported

Google Kubernetes Engine (GKE) is out of Developer Preview and is now fully supported as of RHDH 1.4.

See the full list of supported platforms on the Life Cycle page.

Chapter 2. Breaking changes

This section lists breaking changes in Red Hat Developer Hub 1.4.

2.1. Updated monitoring and logging metrics

Prom-client metrics have been removed and replaced with OpenTelemetry metrics. As a result, the metrics port has changed from 7007 to 9464. Deprecated metrics have also been removed. If you had dependencies on these, ensure your prometheus queries are updated. For further information, see Monitoring and logging.

Additional resources

2.2. Plugins with updated scope

To upgrade from RHDH 1.3 to 1.4, you must update your configuration to use the latest versions of the following plugins from the new scope.

With this update, the following plugins, previously under the @janus-idp scope, have now been moved to the @backstage-community scope:

RHDH 1.3 Plugin Name

RHDH 1.4 Plugin Name

@janus-idp/backstage-plugin-acr

@backstage-community/plugin-acr

@janus-idp/backstage-plugin-acr

@backstage-community/plugin-acr

@janus-idp/backstage-plugin-analytics-provider-segment

@backstage-community/plugin-analytics-provider-segment

@janus-idp/backstage-plugin-jfrog-artifactory

@backstage-community/plugin-jfrog-artifactory

@janus-idp/backstage-plugin-keycloak-backend

@backstage-community/plugin-catalog-backend-module-keycloak

@janus-idp/backstage-plugin-nexus-repository-manager

@backstage-community/plugin-nexus-repository-manager

@janus-idp/backstage-plugin-ocm

@backstage-community/plugin-ocm

@janus-idp/backstage-plugin-ocm-backend

@backstage-community/plugin-ocm-backend

@janus-idp/backstage-plugin-quay

@backstage-community/plugin-quay

@janus-idp/backstage-plugin-rbac

@backstage-community/plugin-rbac

@janus-idp/backstage-plugin-tekton

@backstage-community/plugin-tekton

@janus-idp/backstage-plugin-topology

@backstage-community/plugin-topology

@janus-idp/backstage-scaffolder-backend-module-quay

@backstage-community/plugin-scaffolder-backend-module-quay

@janus-idp/backstage-scaffolder-backend-module-regex

@backstage-community/plugin-scaffolder-backend-module-regex

@janus-idp/backstage-scaffolder-backend-module-servicenow

@backstage-community/plugin-scaffolder-backend-module-servicenow

@janus-idp/backstage-scaffolder-backend-module-sonarqube

@backstage-community/plugin-scaffolder-backend-module-sonarqube

The following plugins, previously under the @backstage scope, have now been moved to the @backstage-community scope:

RHDH 1.3 Plugin Name

RHDH 1.4 Plugin Name

@backstage/plugin-azure-devops

@backstage-community/plugin-azure-devops

@backstage/plugin-azure-devops-backend

@backstage-community/plugin-azure-devops-backend

@backstage/plugin-dynatrace

@backstage-community/plugin-dynatrace

@backstage/plugin-github-actions

@backstage-community/plugin-github-actions

@backstage/plugin-github-issues

@backstage-community/plugin-github-issues

@backstage/plugin-jenkins

@backstage-community/plugin-jenkins

@backstage/plugin-jenkins-backend

@backstage-community/plugin-jenkins-backend

@backstage/plugin-lighthouse

@backstage-community/plugin-lighthouse

@backstage/plugin-sonarqube

@backstage-community/plugin-sonarqube

@backstage/plugin-sonarqube-backend

@backstage-community/plugin-sonarqube-backend

@backstage/plugin-tech-radar

@backstage-community/plugin-tech-radar

Two plugins previously under the @janus-idp scope have moved to @red-hat-developer-hub scope:

RHDH 1.3 Plugin Name

RHDH 1.4 Plugin Name

@janus-idp/backstage-plugin-bulk-import

@red-hat-developer-hub/backstage-plugin-bulk-import

@janus-idp/backstage-plugin-bulk-import-backend

@red-hat-developer-hub/backstage-plugin-bulk-import-backend

With the update to the plugin scope, the dynamic plugin configuration has also been modified.

RHDH 1.3 Configuration

RHDH 1.4 Configuration

dynamic-plugins.default.yaml

dynamic-plugins.default.yaml

Procedure

  • To upgrade from RHDH 1.3 to RHDH 1.4, you must update your configuration to use the latest versions of the plugins listed previously from the new scope.
Note

In addition to the previously provided tables, you can compare the RHDH 1.4 CSV file with the RHDH 1.3 CSV file to identify the changes in dynamic plugins.

Additional resources

Chapter 3. Deprecated functionalities

This section lists deprecated functionalities in Red Hat Developer Hub 1.4.

3.1. ./dynamic-plugins/dist/janus-idp-backstage-plugin-aap-backend-dynamic plugin is deprecated

The ./dynamic-plugins/dist/janus-idp-backstage-plugin-aap-backend-dynamic plugin has been deprecated and will be removed in the next release. You can use Ansible plug-ins for Red Hat Developer Hub instead.

Additional resources

3.2. Audit log rotation is deprecated

With this update, you can evaluate your platform's log forwarding solutions to align with your security and compliance needs. Most of these solutions offer configurable options to minimize the loss of logs in the event of an outage.

Additional resources

3.3. Red Hat Single-Sign On 7.6 is deprecated as an authentication provider

Red Hat Single-Sign On (RHSSO) 7.6 is deprecated as an authentication provider. You can continue to use RHSSO until the end of maintenance support. For details, see RHSSO lifecycle dates. As an alternative, migrate to Red Hat Build of Keycloak v24.

Additional resources

Chapter 4. Technology Preview

This section lists Technology Preview features in Red Hat Developer Hub 1.4.

Important

Technology Preview features provide early access to upcoming product innovations, enabling you to test functionality and provide feedback during the development process. However, these features are not fully supported under Red Hat Subscription Level Agreements, may not be functionally complete, and are not intended for production use. As Red Hat considers making future iterations of Technology Preview features generally available, we will attempt to resolve any issues that customers experience when using these features. See: Technology Preview support scope.

4.1. Added notifcation backend plugins

With this update, Developer Hub includes the following dynamic plugins to manage and streamline notification delivery:

These plugins are disabled by default.

Additional resources

Chapter 5. Fixed issues

This section lists issues fixed in Red Hat Developer Hub 1.4.

5.1. Fixed issues in 1.4.1

5.1.1. Updating Channel does not trigger an Operator Update

Administrators may encounter problems updating Developer Hub across channels. As a workaround, to upgrade across channels:

  • Delete the RHDH Operator subscription. Do not delete the operands.
  • Create a new subscription pointing to the new channel (fast or fast-1.4), using the latest CSV.
  • When you install the new operator, the existing Backstage objects will be upgraded.
Note

If plugin names or configuration requirements have been changed, you may need to update your application configuration. See Plugins with updated scope.

Additional resources

5.1.2. RHDH fails on table lock when deploying using RHDH Operator 1.4

In the previous version, operator deployment could fail due to a database table lock. This is fixed in 1.4.1.

Additional resources

5.2. Fixed issues in 1.4

5.2.1. GitHub issues plugin supports multiple GitHub integration hosts

Previously, the GitHub issues plugin defaulted to using the first GitHub integration it detected for all components. This behavior made it incompatible with setups involving multiple GitHub integration hosts.

Now, GitHub issues plugin supports multiple GitHub integration hosts. It uses the well-known entity slug annotation backstage.io/source-location or backstage.io/managed-by-location to determine the appropriate GitHub integration for a component. If no integration matches the slug, the first GitHub integration is selected, maintaining the previous behavior.

Additional resources

5.2.2. All API documentation is defined in the 3scale backend plugin

Previously, some API documentation defined in the 3scale backend plugin was not accessible in RHDH.

With this update, all API documentation defined in the 3scale backend plugin is imported and merged in the RHDH.

Additional resources

5.2.3. RHDH helm chart deployment throws NotAllowedError

Previously, when deploying with the Helm Chart, there could be a mismatch between the Route hostname and the baseUrl fields added to the generated app-config ConfigMap. This could sometimes cause failure to authenticate against some providers due to an origin mismatch.

This update fixes this issue by ensuring no mismatch between those values.

Additional resources

5.2.4. Disable the creation of permission policies and roles when disabling the RBAC backend plugin

Previously, disabling the Role-Based Access Control (RBAC) backend plugin created roles and permission policies, whether the permission framework was enabled or not.

With this update, disabling the RBAC backend plugin no longer creates roles and permission policies.

Additional resources

5.2.5. Added alert on the deletion icon during bulk imports

Before this update, repositories were added to the Developer Hub from various sources, such as app-config files or GitHub discovery. The Bulk Import plugin only tracked repositories accessible using the configured GitHub integrations. When both plugins were enabled, repositories discovered by GitHub Discovery appeared on Bulk Import pages. However, deleting these repositories from Bulk Import Jobs had no effect, as entities from discovery or app-config.yaml file remained in the Developer Hub catalog.

With this update, an alert on the deletion icon notifies the user to modify the source (either the catalog-info within the repository or the app-config.yaml file if the file originates from there) to remove the catalog entity.

Additional resources

5.2.6. Removed the pre-configured custom resources from the Kubernetes configuration

Before this update, the custom resources in Kubernetes configuration were pre-configured. As a result, users could see Tekton warnings without configuring the custom resources in Kubernetes.

This update removes the pre-configured custom resources from the Kubernetes configuration. Therefore, users can customize resources to the Kubernetes configuration based on their requirements, preventing unrelated warnings from appearing.

Additional resources

5.2.7. RBAC Plugin is broken with latest Backstage version (1.31)

Before this update, Role-Based Access Control (RBAC) backend plugin broke in Backstage 1.31 with an error.

This update resolves compatibility issues with RBAC backend plugin on Backstage versions 1.31 and 1.32 without displaying any errors.

Additional resources

5.2.8. The backstage instance always failed to start in version 5.1.0

Before this update, the backstage instance failed to start in version 5.1.0, showing an error.

With this update, the Role-Based Access Control (RBAC) Backend plugin now starts successfully in version 5.1.0 without displaying any errors.

Additional resources

5.2.9. Resolved RBAC API inconsistency when scaling deployments to more than one pod

Before this update, scaling the deployment to more than one pod caused Role-Based Access Control (RBAC) roles to remain unsynced, allowing only the pod that created the resource to serve it.

With this update, RBAC roles are now properly synced across all pods, with Redis cache and traffic routing configured to ensure consistency across the deployment.

Additional resources

5.2.10. export-dynamic-plugin fails to find dependencies nested deeper than one level in node_modules

Previously, the CLI examined the dependencies of embedded packages during the export process to know if other packages should be embedded. One of the methods was calling require when the CLI encountered a built embedded package, which was the case when wrapping an existing plugin.

This update changes the parent directory that the require uses from the monorepo root to the embedded package. Therefore, the dependent package found is the dependency that is most relevant to the embedded package.

Additional resources

5.2.11. suppress-native-package and allow-native-package flags to handle native modules

Previously, the CLI failed with a message that native modules are not supported.

This update introduces two new CLI flags that help dynamic plugin developers handle native modules. Both flags accept a list of packages. The --suppress-native-package flag does not require the native module at runtime. It replaces the native module with an empty package that displays an error. The --allow-native-package flag instructs the CLI to allow the native package during checks, and tests a plugin that uses a native module.

Additional resources

5.2.12. Resolved the issue with text selection when reporting a TechDoc issue

Previously, the feature to report a documentation (TechDoc) issue failed. Therefore, when a user selected a text in a TechDoc, a large icon appeared instead of a tooltip button.

With this update, users can select texts when reporting a documentation (TechDoc) issue.

Additional resources

5.2.13. Resolved the stdout maxBuffer error

Previously, the export-dynamic-plugin failed with an error that the stdout maxBuffer length was exceeded.

With this update, the CLI redirects the output of the yarn install command it performs during the export process to a file. Therefore, a successful completion of the yarn install command and verification of the export-dynamic-plugin, cleans up the file. The file is available for troubleshooting when the dynamic plugin validation checks fail.

Additional resources

5.2.14. Added an --ignore-version-check flag

Previously, exporting a plugin that has not been updated to a newer backstage version failed due to a semver check performed on dependencies of the dynamic plugin package.

With this update, an --ignore-version-check flag accepts a list of package names causing the CLI to selectively ignore the semver check the CLI performs when evaluating the plugin package dependencies. Therefore, a plugin that has not been updated works because it relies on unchanged interfaces and functions.

Additional resources

5.2.15. Updated the Tech Radar plugin

With this update, you are now required to enable both ./dynamic-plugins/dist/backstage-community-tech-radar and ./dynamic-plugins/dist/backstage-community-tech-radar-backend-dynamic to use the Tech Radar plugin. You must configure additional settings depending on where you choose to load the JSON data for the plugin.

Additional resources

Chapter 6. Fixed security issues

This section lists security issues fixed in Red Hat Developer Hub 1.4.

6.1. Red Hat Developer Hub 1.4.1

6.1.1. Red Hat Developer Hub dependency updates

CVE-2024-45338
A flaw was found in golang.org/x/net/html. This flaw allows an attacker to craft input to the parse functions that would be processed non-linearly with respect to its length, resulting in extremely slow parsing. This issue can cause a denial of service.
CVE-2024-52798
A flaw was found in path-to-regexp. A path-to-regexp turns path strings into regular expressions. In certain cases, path-to-regexp will output a regular expression that can be exploited to cause poor performance.
CVE-2024-55565
nanoid (aka Nano ID) before 5.0.9 mishandles non-integer values. 3.3.8 is also a fixed version.
CVE-2024-56201
A flaw was found in the Jinja2 package. A bug in the Jinja compiler allows an attacker that controls both the content and filename of a template to execute arbitrary Python code, regardless of Jinja’s sandbox being used. An attacker needs to be able to control both the filename and the contents of a template. Whether that is the case depends on the type of application using Jinja. This vulnerability impacts users of applications that execute untrusted templates where the template author can also choose the template filename.
CVE-2024-56326
A flaw was found in the Jinja package. In affected versions of Jinja, an oversight in how the Jinja sandboxed environment detects calls to str.format allows an attacker that controls the content of a template to execute arbitrary Python code. To exploit the vulnerability, an attacker needs to control the content of a template. Whether that is the case depends on the type of application using Jinja. This vulnerability impacts users of applications that execute untrusted templates. Jinja’s sandbox does catch calls to str.format and ensures they don’t escape the sandbox. However, storing a reference to a malicious string’s format method is possible, then passing that to a filter that calls it. No such filters are built into Jinja but could be present through custom filters in an application. After the fix, such indirect calls are also handled by the sandbox.
CVE-2024-56334
A flaw was found in the systeminformation library for Node.js. In Windows systems, the SSID parameter of the getWindowsIEEE8021x function is not sanitized before it is passed to cmd.exe. This may allow a remote attacker to execute arbitrary commands on the target system.

6.2. Red Hat Developer Hub 1.4.0

6.2.1. Red Hat Developer Hub dependency updates

CVE-2024-21536
A flaw was found in the http-proxy-middleware package. Affected versions of this package are vulnerable to denial of service (DoS) due to an UnhandledPromiseRejection error thrown by micromatch. This flaw allows an attacker to kill the Node.js process and crash the server by requesting certain paths.
CVE-2024-21538
A Regular Expression Denial of Service (ReDoS) vulnerability was found in the cross-spawn package for Node.js. Due to improper input sanitization, an attacker can increase CPU usage and crash the program with a large, specially crafted string.
CVE-2024-45296
A flaw was found in path-to-regexp package, where it turns path strings into regular expressions. In certain cases, path-to-regexp will output a regular expression that can be exploited to cause poor performance. Because JavaScript is single-threaded and regex matching runs on the main thread, poor performance will block the event loop and lead to a denial of service (DoS).
CVE-2024-45590
A flaw was found in body-parser. This vulnerability causes denial of service via a specially crafted payload when the URL encoding is enabled.
CVE-2024-45815
A flaw was found in the backstage/plugin-catalog-backend package. A malicious actor with authenticated access to a Backstage instance with the catalog backend plugin installed is able to interrupt the service using a specially crafted query to the catalog API.
CVE-2024-45816
A directory traversal vulnerability was found in the backstage/plugin-techdocs-backend package. When using the AWS S3 or GCS storage provider for TechDocs, it is possible to access content in the entire storage bucket. This can leak contents of the bucket that are not intended to be accessible, as well as bypass permission checks in Backstage.
CVE-2024-46976
A flaw was found in the backstage/plugin-techdocs-backend package. An attacker with control of the contents of the TechDocs storage buckets may be able to inject executable scripts in the TechDocs content that will be executed in the victim’s browser when browsing documentation or navigating to an attacker provided link.
CVE-2024-47762
A flaw was found in the backstage/plugin-app-backend package. Configurations supplied through APP_CONFIG_* environment variables unexpectedly ignore the visibility defined in the configuration schema, potentially exposing sensitive configuration details intended to remain private or restricted to backend processes.

Chapter 7. Known issues

This section lists known issues in Red Hat Developer Hub 1.4.

7.1. Multi-Attached error for Volume (PVC)

Currently, when deploying Developer Hub using the Helm Chart, two replicas cannot run on different cluster nodes. This might also affect the upgrade from 1.3 to 1.4.0 if the new pod is scheduled on a different node.

A possible workaround for the upgrade is to manually scale down the number of replicas to 0 before upgrading your Helm release. Or manually remove the old Developer Hub pod after upgrading the Helm release. However, this would imply some application downtime. You can also leverage a Pod Affinity rule to force the cluster scheduler to run your Developer Hub pods on the same node.

Additional resources

7.2. Topology plugin permission is not displayed in the RBAC front-end UI

Permissions associated only with front-end plugins do not appear in the UI because they require a backend plugin to expose the permission framework's well-known endpoint. As a workaround, you can apply these permissions by using a CSV file or directly calling the REST API of the RBAC backend plugin. Affected plugins include Topology (topology.view.read), Tekton (tekton.view.read), ArgoCD (argocd.view.read), and Quay (quay.view.read).

Additional resources

Legal Notice

Copyright © 2025 Red Hat, Inc.
The text of and illustrations in this document are licensed by Red Hat under a Creative Commons Attribution–Share Alike 3.0 Unported license ("CC-BY-SA"). An explanation of CC-BY-SA is available at http://creativecommons.org/licenses/by-sa/3.0/. In accordance with CC-BY-SA, if you distribute this document or an adaptation of it, you must provide the URL for the original version.
Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law.
Red Hat, Red Hat Enterprise Linux, the Shadowman logo, the Red Hat logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.
Linux® is the registered trademark of Linus Torvalds in the United States and other countries.
Java® is a registered trademark of Oracle and/or its affiliates.
XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.
MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.
Node.js® is an official trademark of Joyent. Red Hat is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.
The OpenStack® Word Mark and OpenStack logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation's permission. We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.
All other trademarks are the property of their respective owners.
Red Hat logoGithubRedditYoutubeTwitter

Learn

Try, buy, & sell

Communities

About Red Hat Documentation

We help Red Hat users innovate and achieve their goals with our products and services with content they can trust.

Making open source more inclusive

Red Hat is committed to replacing problematic language in our code, documentation, and web properties. For more details, see the Red Hat Blog.

About Red Hat

We deliver hardened solutions that make it easier for enterprises to work across platforms and environments, from the core datacenter to the network edge.

© 2024 Red Hat, Inc.