Chapter 1. New features and enhancements

With this update, RHDH entity types documentation includes following topics:

For more information, see Catalog entity descriptor reference.

With this update, you can sign in to RHDH by using PingFederate credentials, where the user is resolved to the organization data in the software catalog.

Authentication with PingFederate is enabled by user and group provisioning with the LDAP catalog provider plugin.

With this update, you can create and deploy persona-specific homepages tailored for different user groups within RHDH.

This enhancement delivers personalized and targeted content, streamlines workflows, and improves user engagement by enabling platform engineers to attach homepages to specific Backstage or RBAC groups and configure layouts with dynamic plugins.

Additionally, visibility rules let you to control access to these persona-specific homepages, providing a customized starting experience for each user persona.

For more information, see Attaching homepages to groups.

This update introduces a comparison table of deployment methods for RHDH: Helm Chart and Operator. The table outlines benefits and drawbacks of each approach, aiding informed decisions.

See Compare the Helm chart and Operator to choose the optimal deployment method.

With this update, the Adoption Insights plugin displays human-readable entity titles instead of technical names in "Top 3" widgets (catalog entities, templates, and TechDocs), making it easier for users to identify popular resources at a glance.

With this update, RHDH Dynamic Plugin Factory received multiple enhancements:

This update introduces Red Hat Developer Lightspeed for Red Hat Developer Hub as a default plugin when you deploy Red Hat Developer Hub with the Operator or the Helm chart.

In this release, Red Hat Developer Lightspeed for Red Hat Developer Hub uses version 1.9 RAG embeddings. A future update will provide version 1.10 RAG embeddings to resolve this limitation.

See Interacting with Red Hat Developer Lightspeed for Red Hat Developer Hub.

With this update, Developer Lightspeed for RHDH lets users manage MCP servers directly from the chat interface. Administrators define available MCP servers in app-config.yaml, and users can personalize their experience through a settings panel accessible from the chat header.

You can view all configured MCP servers with their connection status and tool counts, toggle individual servers on or off, and provide personal access tokens for servers that require authentication. A token configuration modal validates credentials inline with real-time feedback as the user saves, and saved tokens can be cleared or replaced at any time.

On the backend, user-provided tokens are encrypted at rest using AES-256-GCM when backend.auth.keys is configured, with support for transparent key rotation and automatic migration of legacy plaintext tokens. New API endpoints handle server listing, per-user preference management, and on-demand server validation. Only servers that are enabled and have a valid token are included in requests to the Developer Lightspeed for RHDH Core Service.

Access is governed by the following two permissions:

With this update, RHDH exposes additional Scaffolder capabilities as MCP tools through the Backstage scaffolder and scaffolder-mcp-extras plugins. This enhancement centralizes access to Scaffolder actions.

As a result, you can use MCP to discover actions, validate and execute templates securely, and monitor task progress.

See Installing MCP server and tool plugins.

With this update, Scorecard supports file-level compliance checks for repositories. Platform engineers can configure checks for the presence of specific files ( such as LICENSE, CODEOWNERS, Dockerfile, or .gitignore), across repositories known to the platform. The file paths and names are fully configurable, letting customers customize checks for their own standards and workflows.

File-level compliance helps organizations verify that development teams are following repository best practices and identify repositories that are missing required files.

This update changes how Bulk Import discovers repositories. Listings are fetched on behalf of the signed-in user through SCM OAuth, so that each user sees only repositories and organizations their own GitHub or GitLab account can access.

The list also hides repositories that are already in the software catalog, so that only repositories that haven’t been imported yet are visible.

With this update, you can create aggregated cards to assess overall technical health, compliance, and risk without manually checking each service’s individual scorecard.

Additionally, this update introduces aggregation type: average. The average type rolls up each owned entity’s metric into status keys, applies weights per status key, and returns one normalized score as a percentage between 0 and 100.

This update introduces schema-based plugin isolation configuration. Each plugin uses its own PostgreSQL schema within a single shared database. This is useful for database users without CREATEDB privileges who can use the schema for single database deployments.

This update includes an alpha Backstage frontend system (app-next) as an alternative to the existing frontend. You can enable this frontend system by using the following environment variables in Helm chart or Operator configuration:

The new frontend system supports loading dynamic plugins that are compatible with it, and provides a path for migrating to the upstream Backstage frontend architecture.

This release adds New Frontend System (NFS) support to Red Hat-owned and GA frontend plugins, including Adoption Insights, Bulk Import, Extensions, Scorecard, RBAC, Orchestrator, Global Header, and others. Each plugin has been updated to work with NFS while maintaining backward compatibility with the legacy frontend system.

The plugins are available when running RHDH with NFS enabled. To enable NFS, use the following two variables:

With this update, the core RHDH user interface features are migrated to New Frontend System (NFS).

Key components such as the Homepage, Analytics Provider, Theme, and Translation plugins load as dynamic plugins. The Global Header and Drawer features have been migrated to Blueprints for compatibility.

With this update, aggregated Scorecard KPI cards on the RHDH homepage show when their data was last updated and let you navigate into the entities that contribute to each metric.

Select the entity count on a card to open the Scorecard Entities page, where you can sort and paginate through components (and other catalog kinds) with per-entity values, threshold status, owners, and sync timestamps.

This update introduces flavor-based configuration for the Operator by using the v1alpha5 API. You can deploy pre-configured RHDH instances by using the spec.flavours[] array in the Backstage CR to combine or disable specific flavors.

Additionally, support for defining multiple ConfigMaps in a single YAML file for the default configuration is added. This lets administrators organize related configuration files or environment variables and manage grouped configurations within the same file.

This update also introduces the rhdh.redhat.com/sub-path annotation for default configurations. The enhancement provides better control over volume mount behavior: you can configure the mount to behave as a directory, mount all files individually, or mount specific files.

See Automating environment provisioning with predefined Operator configurations.

With this update, the @red-hat-developer-hub/backstage-plugin-orchestrator-backend-module-loki package is supported as a GA feature. This module provides centralized log aggregation for serverless workflows using Loki.

With this update, you can configure Orchestrator widgets to retry failed HTTP fetches when a backend is briefly unavailable. Authors can turn this on per widget with optional settings:

With this update, Orchestrator supports an optional custom review page for workflow runs. You can implement getReviewComponent() on OrchestratorFormApi to replace the default review step with your own React component while other users keep the built-in review page.

The API exposes ReviewComponentProps and shared helpers in orchestrator-form-react for consistent handling of review data, hidden fields, and navigation.