Prerequisites

• Add Argo CD instance information to your app-config.yaml configmap as shown in the following example:

  argocd:
    appLocatorMethods:
      - type: 'config'
        instances:
          - name: argoInstance1
            url: https://argoInstance1.com
            username: ${ARGOCD_USERNAME}
            password: ${ARGOCD_PASSWORD}
          - name: argoInstance2
            url: https://argoInstance2.com
            username: ${ARGOCD_USERNAME}
            password: ${ARGOCD_PASSWORD}

  Note

  Avoid using a trailing slash in the url, as it might cause unexpected behavior.

• Add the following annotation to the entity's catalog-info.yaml file to identify the Argo CD applications.

  annotations:
    ...
    # The label that Argo CD uses to fetch all the applications. The format to be used is label.key=label.value. For example, rht-gitops.com/janus-argocd=quarkus-app.
  
    argocd/app-selector: '${ARGOCD_LABEL_SELECTOR}'

• (Optional) Add the following annotation to the entity's catalog-info.yaml file to switch between Argo CD instances as shown in the following example:

   annotations:
     ...
      # The Argo CD instance name used in `app-config.yaml`.
  
      argocd/instance-name: '${ARGOCD_INSTANCE}'

  Note

  If you do not set this annotation, the Argo CD plugin defaults to the first Argo CD instance configured in app-config.yaml.

Procedure

• Add the following to your dynamic-plugins ConfigMap to enable the Argo CD plugin.

  global:
    dynamic:
      includes:
        - dynamic-plugins.default.yaml
      plugins:
        - package: oci://ghcr.io/redhat-developer/rhdh-plugin-export-overlays/roadiehq-backstage-plugin-argo-cd-backend:<tag>
          disabled: false
        - package: oci://ghcr.io/redhat-developer/rhdh-plugin-export-overlays/backstage-community-plugin-argocd:<tag>
          disabled: false

• To find the correct image tag for <tag>:

  1. Look in the RHDH release notes preface for your Backstage version.
  2. Locate the plugin version for paths starting with oci://ghcr.io within one of the tables in the Dynamic Plugins Reference guide.

Prerequisites

• The Developer Hub Kubernetes plugin (@backstage/plugin-kubernetes) is installed and configured.

  • To install and configure Kubernetes plugin in Developer Hub, see Installation and Configuration guide.
• You have access to the Kubernetes cluster with the necessary permissions to create and manage custom resources and ClusterRoles.
• The Kubernetes cluster has the argoproj.io group resources (for example, Rollouts and Analysis Runs) installed.

Procedure

• Set the value to false as follows:

  global:
    dynamic:
      includes:
        - dynamic-plugins.default.yaml
      plugins:
        - package: oci://ghcr.io/redhat-developer/rhdh-plugin-export-overlays/backstage-community-plugin-jfrog-artifactory:<tag>
          disabled: false

  The <tag> variable is your RHDH application's version of Backstage and the plugin version, in the format: bs_<backstage-version>__<plugin-version> (note the double underscore delimiter).

• To find the correct image tag for <tag>:

  1. Look in the RHDH release notes preface for your Backstage version.
  2. Locate the plugin version for paths starting with oci://ghcr.io within one of the tables in the Dynamic Plugins Reference guide.

Prerequisites

• To enable the Keycloak plugin, you must set the following environment variables:

  • KEYCLOAK_BASE_URL
  • KEYCLOAK_LOGIN_REALM
  • KEYCLOAK_REALM
  • KEYCLOAK_CLIENT_ID
  • KEYCLOAK_CLIENT_SECRET

Procedure

• The Keycloak plugin is pre-loaded in Developer Hub with basic configuration properties. To enable it, set the disabled property to false as follows:

  global:
    dynamic:
      includes:
        - dynamic-plugins.default.yaml
      plugins:
        - package: ./dynamic-plugins/dist/backstage-community-plugin-catalog-backend-module-keycloak-dynamic
          disabled: false

Procedure

• Set the value to false as follows:

  global:
    dynamic:
      includes:
        - dynamic-plugins.default.yaml
      plugins:
        - package: oci://ghcr.io/redhat-developer/rhdh-plugin-export-overlays/backstage-community-plugin-nexus-repository-manager:<tag>
          disabled: false

  The <tag> variable is your RHDH application's version of Backstage and the plugin version, in the format: bs_<backstage-version>__<plugin-version> (note the double underscore delimiter).

• To find the correct image tag for <tag>:

  1. Look in the RHDH release notes preface for your Backstage version.
  2. Locate the plugin version for paths starting with oci://ghcr.io within one of the tables in the Dynamic Plugins Reference guide.

Prerequisites

• You have installed and configured the @backstage/plugin-kubernetes-backend dynamic plugins.
• You have configured the Kubernetes plugin to connect to the cluster using a ServiceAccount.

• The ClusterRole must be granted to ServiceAccount accessing the cluster.

  Note

  If you have the Developer Hub Kubernetes plugin configured, then the ClusterRole is already granted.

Procedure

• The Topology plugin is pre-loaded in Developer Hub with basic configuration properties. To enable it, set the disabled property to false as follows:

  app-config.yaml fragment

  auth:
  global:
    dynamic:
      includes:
        - dynamic-plugins.default.yaml
      plugins:
        - package: ./dynamic-plugins/dist/backstage-community-plugin-topology
          disabled: false

Prerequisites

• For GitHub only: You have enabled GitHub repository discovery.

Prerequisites

• You have enabled the Bulk Import feature and given access to it.

Prerequisites

• You have enabled the Bulk Import feature and given access to it.
• You have set up a GitLab personal access token (PAT).

• You configured the GitLab integration by adding the following section to your RHDH app-config.yaml file:

  integrations:
    gitlab:
      - host: ${GITLAB_HOST}
        token: ${GITLAB_TOKEN}

• You enabled the GitLab catalog provider plugin in your dynamic-plugins.yaml file to import GitLab users and groups:

  plugins:
    - package: './dynamic-plugins/dist/backstage-plugin-catalog-backend-module-gitlab-org-dynamic'
      disabled: false

• Importing existing catalog entities from a repository
• Creating pull requests for cleanup
• Calling webhooks for external system integration

Prerequisites

• You created a custom Scaffolder template for the Bulk Import plugin.

• You have run your RHDH instance with the following environment variable enabled to allow the use of the Scaffolder functionality:

  export NODE_OPTIONS=--no-node-snapshot

Procedure

• Configure your app-config.yaml configuration to instruct the Bulk Import plugin to use your custom template as shown in the following example:

  bulkImport:
    importTemplate: <your_template_entity_reference_or_template_name>
    importAPI: `open-pull-requests` | `scaffolder`;

  where:

  importTemplate:

  Enter your Scaffolder template entity reference.

  importAPI

  Set the API to 'scaffolder' to trigger the defined workflow for high-fidelity automation. This field defines the import workflow and currently supports two following options:

  open-pull-requests

  This is the default import workflow, which includes the logic for creating pull requests for every selected repository.

  scaffolder

  This workflow uses an import scenario defined in the Scaffolder template to create import jobs. Select this option to use the custom import scenario defined in your Scaffolder template.

  Optional: You can direct the Bulk Import plugin to hand off the entire list of selected repositories to a custom Orchestrator workflow.

  Important

  The Scaffolder template must be generic and not specific to a single repository if you want your custom Scaffolder template to run successfully for every repository in the bulk list.

Verification

• The Bulk Import plugin runs the custom Scaffolder template for the list of repositories using the /task-imports API endpoint.

Prerequisites

• You have installed and configured the Orchestrator plugin in your Developer Hub instance.
• You have registered a generic custom workflow (for example, universal-pr) in the Orchestrator plugin.
• You have role-based access control (RBAC) permissions to configure the Bulk Import plugin.

Verification

• Locate your repository and confirm status is COMPLETED.

Prerequisites

• Red Hat Developer Hub is installed and running.
• You have created a project in the Developer Hub.

• GET: Retrieves specified information from a specified resource endpoint
• POST: Creates or updates a resource
• PUT: Modify a resource
• PATCH: Updates a resource

• DELETE: Deletes a resource

  [GET] servicenow:now:table:retrieveRecord

  Retrieves information of a specified record from a table in the Developer Hub.

  Table 2. Input parameters

  Name	Type	Requirement	Description
  tableName	string	Required	Name of the table to retrieve the record from
  sysId	string	Required	Unique identifier of the record to retrieve
  sysparmDisplayValue	enum("true", "false", "all")	Optional	Returns field display values such as true, actual values as false, or both. The default value is false.
  sysparmExcludeReferenceLink	boolean	Optional	Set as true to exclude Table API links for reference fields. The default value is false.
  sysparmFields	string[]	Optional	Array of fields to return in the response
  sysparmView	string	Optional	Renders the response according to the specified UI view. You can override this parameter using sysparm_fields.
  sysparmQueryNoDomain	boolean	Optional	Set as true to access data across domains if authorized. The default value is false.

  Table 3. Output parameters

  Name	Type	Description
  result	Record<PropertyKey, unknown>	The response body of the request

  [GET] servicenow:now:table:retrieveRecords

  Retrieves information about multiple records from a table in the Developer Hub.

  Table 4. Input parameters

  Name	Type	Requirement	Description
  tableName	string	Required	Name of the table to retrieve the records from
  sysparamQuery	string	Optional	Encoded query string used to filter the results
  sysparmDisplayValue	enum("true", "false", "all")	Optional	Returns field display values such as true, actual values as false, or both. The default value is false.
  sysparmExcludeReferenceLink	boolean	Optional	Set as true to exclude Table API links for reference fields. The default value is false.
  sysparmSuppressPaginationHeader	boolean	Optional	Set as true to suppress pagination header. The default value is false.
  sysparmFields	string[]	Optional	Array of fields to return in the response
  sysparmLimit	int	Optional	Maximum number of results returned per page. The default value is 10,000.
  sysparmView	string	Optional	Renders the response according to the specified UI view. You can override this parameter using sysparm_fields.
  sysparmQueryCategory	string	Optional	Name of the query category to use for queries
  sysparmQueryNoDomain	boolean	Optional	Set as true to access data across domains if authorized. The default value is false.
  sysparmNoCount	boolean	Optional	Does not run a select count(*) on the table. The default value is false.

  Table 5. Output parameters

  Name	Type	Description
  result	Record<PropertyKey, unknown>	The response body of the request

  [POST] servicenow:now:table:createRecord

  Creates a record in a table in the Developer Hub.

  Table 6. Input parameters

  Name	Type	Requirement	Description
  tableName	string	Required	Name of the table to save the record in
  requestBody	Record<PropertyKey, unknown>	Optional	Field name and associated value for each parameter to define in the specified record
  sysparmDisplayValue	enum("true", "false", "all")	Optional	Returns field display values such as true, actual values as false, or both. The default value is false.
  sysparmExcludeReferenceLink	boolean	Optional	Set as true to exclude Table API links for reference fields. The default value is false.
  sysparmFields	string[]	Optional	Array of fields to return in the response
  sysparmInputDisplayValue	boolean	Optional	Set field values using their display value such as true or actual value as false. The default value is false.
  sysparmSuppressAutoSysField	boolean	Optional	Set as true to suppress auto-generation of system fields. The default value is false.
  sysparmView	string	Optional	Renders the response according to the specified UI view. You can override this parameter using sysparm_fields.

  Table 7. Output parameters

  Name	Type	Description
  result	Record<PropertyKey, unknown>	The response body of the request

  [PUT] servicenow:now:table:modifyRecord

  Modifies a record in a table in the Developer Hub.

  Table 8. Input parameters

  Name	Type	Requirement	Description
  tableName	string	Required	Name of the table to change the record from
  sysId	string	Required	Unique identifier of the record to change
  requestBody	Record<PropertyKey, unknown>	Optional	Field name and associated value for each parameter to define in the specified record
  sysparmDisplayValue	enum("true", "false", "all")	Optional	Returns field display values such as true, actual values as false, or both. The default value is false.
  sysparmExcludeReferenceLink	boolean	Optional	Set as true to exclude Table API links for reference fields. The default value is false.
  sysparmFields	string[]	Optional	Array of fields to return in the response
  sysparmInputDisplayValue	boolean	Optional	Set field values using their display value such as true or actual value as false. The default value is false.
  sysparmSuppressAutoSysField	boolean	Optional	Set as true to suppress auto-generation of system fields. The default value is false.
  sysparmView	string	Optional	Renders the response according to the specified UI view. You can override this parameter using sysparm_fields.
  sysparmQueryNoDomain	boolean	Optional	Set as true to access data across domains if authorized. The default value is false.

  Table 9. Output parameters

  Name	Type	Description
  result	Record<PropertyKey, unknown>	The response body of the request

  [PATCH] servicenow:now:table:updateRecord

  Updates a record in a table in the Developer Hub.

  Table 10. Input parameters

  Name	Type	Requirement	Description
  tableName	string	Required	Name of the table to update the record in
  sysId	string	Required	Unique identifier of the record to update
  requestBody	Record<PropertyKey, unknown>	Optional	Field name and associated value for each parameter to define in the specified record
  sysparmDisplayValue	enum("true", "false", "all")	Optional	Returns field display values such as true, actual values as false, or both. The default value is false.
  sysparmExcludeReferenceLink	boolean	Optional	Set as true to exclude Table API links for reference fields. The default value is false.
  sysparmFields	string[]	Optional	Array of fields to return in the response
  sysparmInputDisplayValue	boolean	Optional	Set field values using their display value such as true or actual value as false. The default value is false.
  sysparmSuppressAutoSysField	boolean	Optional	Set as true to suppress auto-generation of system fields. The default value is false.
  sysparmView	string	Optional	Renders the response according to the specified UI view. You can override this parameter using sysparm_fields.
  sysparmQueryNoDomain	boolean	Optional	Set as true to access data across domains if authorized. The default value is false.

  Table 11. Output parameters

  Name	Type	Description
  result	Record<PropertyKey, unknown>	The response body of the request

  [DELETE] servicenow:now:table:deleteRecord

  Deletes a record from a table in the Developer Hub.

  Table 12. Input parameters

  Name	Type	Requirement	Description
  tableName	string	Required	Name of the table to delete the record from
  sysId	string	Required	Unique identifier of the record to delete
  sysparmQueryNoDomain	boolean	Optional	Set as true to access data across domains if authorized. The default value is false.

Prerequisites

• You have installed Red Hat Developer Hub with the Helm chart.

Procedure

• In your Helm chart, add a package with the Kubernetes custom action plugin name and update the disabled field to enable the plugin. For example:

  global:
    dynamic:
      includes:
        - dynamic-plugins.default.yaml
      plugins:
        - package: ./dynamic-plugins/dist/backstage-community-plugin-scaffolder-backend-module-kubernetes-dynamic
          disabled: false

  Note

  The default configuration for a plugin is extracted from the dynamic-plugins.default.yaml file, however, you can use a pluginConfig entry to override the default configuration.

Procedure

• To use a Kubernetes custom action in your custom template, add the following Kubernetes actions to your template:

  action: kubernetes:create-namespace
  id: create-kubernetes-namespace
  name: Create kubernetes namespace
  input:
    namespace: my-rhdh-project
    clusterRef: bar
    token: TOKEN
    skipTLSVerify: false
    caData: Zm9v
    labels: app.io/type=ns; app.io/managed-by=org;

Procedure

• To create a template, define a Template object as a YAML file.

  The Template object describes the template and its metadata. It also contains required input variables and a list of actions that are executed by the scaffolding service.

  apiVersion: scaffolder.backstage.io/v1beta3
  kind: Template
  metadata:
    name: create-kubernetes-namespace
    title: Create a kubernetes namespace
    description: Create a kubernetes namespace
  spec:
    type: service
    parameters:
      - title: Information
        required: [namespace, token]
        properties:
          namespace:
            title: Namespace name
            type: string
            description: Name of the namespace to be created
          clusterRef:
            title: Cluster reference
            type: string
            description: Cluster resource entity reference from the catalog
            ui:field: EntityPicker
            ui:options:
              catalogFilter:
                kind: Resource
          url:
            title: Url
            type: string
            description: Url of the kubernetes API, will be used if clusterRef is not provided
          token:
            title: Token
            type: string
            ui:field: Secret
            description: Bearer token to authenticate with
          skipTLSVerify:
            title: Skip TLS verification
            type: boolean
            description: Skip TLS certificate verification, not recommended to use in production environment, default to false
          caData:
            title: CA data
            type: string
            ui:field: Secret
            description: Certificate Authority base64 encoded certificate
          labels:
            title: Labels
            type: string
            description: Labels to be applied to the namespace
            ui:widget: textarea
            ui:options:
              rows: 3
            ui:help: 'Hint: Separate multiple labels with a semicolon!'
            ui:placeholder: 'kubernetes.io/type=namespace; app.io/managed-by=org'
    steps:
      - id: create-kubernetes-namespace
        name: Create kubernetes namespace
        action: kubernetes:create-namespace
        input:
          namespace: ${ parameters.namespace }
          clusterRef: ${ parameters.clusterRef }
          url: ${ parameters.url }
          token: ${ secrets.token }
          skipTLSVerify: ${ parameters.skipTLSVerify }
          caData: ${ secrets.caData }
          labels: ${ parameters.labels }

Prerequisites

• You have added your GitHub integration credentials in the app-config.yaml file.
• You have defined the schedule.frequency in the app-config.yaml file as longer time period, such as 24 hours.
• For GitHub Discovery only: You have enabled GitHub Discovery.
• For GitHub Organizational Data only: You have enabled Github Authentication with user ingestion.

Verification

• Check the log for an entry that confirms that http endpoint was set up successfully to receive events from the GitHub webhook.

  Example of a log of successfully set up http endpoint

  {"level":"\u001b[32minfo\u001b[39m","message":"Registered /api/events/http/github to receive events","plugin":"events","service":"backstage","timestamp":"2025-11-03 02:19:12"}

• For GitHub Discovery only:

  • Trigger a GitHub push event by adding, modifying or deleting the catalog-info.yaml file in the repository where you set up your webhook. A record of this event should appear in the pod logs of your RHDH instance.

    Example of a log with changes to catalog-info.yaml file

    {"level":"\u001b[32minfo\u001b[39m","message":"Processed Github push event: added 0 - removed 0 - modified 1","plugin":"catalog","service":"backstage","span_id":"47534b96c4afc654","target":"github-provider:providerId","timestamp":"2025-06-15 21:33:14","trace_flags":"01","trace_id":"ecc782deb86aed2027da0ae6b1999e5c"}

• For GitHub Organizational Data only:

  • Newly added users and teams appear in the RHDH catalog.