Procedure

1. Add the following YAML file as a config map to your namespace:

   version: 2
   image_name: redhat-ai-dev-llama-stack-no-guard
   apis:
     - agents
     - inference
     - safety
     - tool_runtime
     - vector_io
     - files
   container_image:
   external_providers_dir:
   providers:
     agents:
       - config:
           persistence:
             agent_state:
               namespace: agents
               backend: kv_default
             responses:
               table_name: responses
               backend: sql_default
         provider_id: meta-reference
         provider_type: inline::meta-reference
     inference:
       - provider_id: ${env.ENABLE_VLLM:+vllm}
         provider_type: remote::vllm
         config:
           url: ${env.VLLM_URL:=}
           api_token: ${env.VLLM_API_KEY:=}
           max_tokens: ${env.VLLM_MAX_TOKENS:=4096}
           tls_verify: ${env.VLLM_TLS_VERIFY:=true}
       - provider_id: ${env.ENABLE_OLLAMA:+ollama}
         provider_type: remote::ollama
         config:
           url: ${env.OLLAMA_URL:=http://localhost:11434}
       - provider_id: ${env.ENABLE_OPENAI:+openai}
         provider_type: remote::openai
         config:
           api_key: ${env.OPENAI_API_KEY:=}
       - provider_id: ${env.ENABLE_VERTEX_AI:+vertexai}
         provider_type: remote::vertexai
         config:
           project: ${env.VERTEX_AI_PROJECT:=}
           location: ${env.VERTEX_AI_LOCATION:=us-central1}
       - provider_id: sentence-transformers
         provider_type: inline::sentence-transformers
         config: {}
     tool_runtime:
       - provider_id: model-context-protocol
         provider_type: remote::model-context-protocol
         config: {}
       - provider_id: rag-runtime
         provider_type: inline::rag-runtime
         config: {}
     vector_io:
       - provider_id: faiss
         provider_type: inline::faiss
         config:
           persistence:
             namespace: vector_io::faiss
             backend: faiss_kv
     files:
       - provider_id: localfs
         provider_type: inline::localfs
         config:
           storage_dir: /tmp/llama-stack-files
           metadata_store:
             table_name: files_metadata
             backend: sql_files
   storage:
     backends:
       kv_default:
         type: kv_sqlite
         db_path: /tmp/kvstore.db
       sql_default:
         type: sql_sqlite
         db_path: /tmp/sql_store.db
       sql_files:
         type: sql_sqlite
         db_path: /rag-content/vector_db/rhdh_product_docs/1.9/files_metadata.db
       faiss_kv:
         type: kv_sqlite
         db_path: /rag-content/vector_db/rhdh_product_docs/1.9/faiss_store.db
     stores:
       metadata:
         namespace: registry
         backend: faiss_kv
       inference:
         table_name: inference_store
         backend: sql_default
         max_write_queue_size: 10000
         num_writers: 4
       conversations:
         table_name: openai_conversations
         backend: sql_default
   registered_resources:
     models:
       - model_id: sentence-transformers/all-mpnet-base-v2
         metadata:
           embedding_dimension: 768
         model_type: embedding
         provider_id: sentence-transformers
         provider_model_id: /rag-content/embeddings_model
     tool_groups:
       - provider_id: rag-runtime
         toolgroup_id: builtin::rag
     vector_dbs:
       - vector_db_id: rhdh-product-docs-1_8
         embedding_model: sentence-transformers/all-mpnet-base-v2
         embedding_dimension: 768
         provider_id: faiss
   server:
     auth:
     host:
     port: 8321
     quota:
     tls_cafile:
     tls_certfile:
     tls_keyfile:

2. Mount the config map to your Llama Stack container at /app-root/run.yaml to make sure it overrides the default image file:

   name: llama-stack
   volumeMounts:
   - mountPath: /app-root/run.yaml
     subPath: run.yaml
     name: llama-stack-config

3. Configure the required volume:

   volumes:
   - name: llama-stack-config
     configMap:
       name: llama-stack-config

   where:

   llama-stack-config

   The config map where you added the new no-guard configuration file.

4. Restart the deployment if it does not trigger an automatic rollout.

Procedure

1. Click the Lightspeed button at the lower right of the screen to open the chat overlay.

2. Optional: Configure the interface display and server settings:

   • Click the Chatbot options icon (⋮) to view chat history or start a new chat.

   • Click the Display mode icon and select any of the following views:

     

     • Overlay: A floating window is displayed over the current page content.

       

     • Dock to window: A panel attaches to the right side of the screen. Activating this mode automatically closes the quick start panel if it is already open.

       

     • Fullscreen: A dedicated page opens for intensive chat sessions. This mode displays a revised header containing the Lightspeed logo and a horizontal tab bar, which replaces the previous main menu. Bookmark the URL in your browser to save a direct link to the chat interface.

       
     • Optional: Toggle Enable pinned chats/Disable pinned chats to enable or hide the pinned chats. The system enables this option by default.

     • Available only if MCP is configured: Manage Model Context Protocol connections.

       

3. Start a chat or load an earlier session:

   • Enter a prompt: Type a query in the Enter a prompt for Lightspeed chat field and press Enter.
   • Use a sample: Click a prompt tile.

   • Change the AI model: Select a model from the model selector dropdown menu inside the prompt bar.

     

   • Attach a file: Click the (+) icon on the left of the prompt bar to upload a .yaml, .json, or .txt file. Descriptive text clarifies the function of the icon.

     1. Click the file name to open the preview model.

     2. View or edit the content of the file:

        
   • Use voice: Click the Use microphone icon. The microphone and send buttons are located on the right side of the prompt bar.

   • Control AI generation: Use the control buttons on the right side of the prompt bar. Click the start/send (>) button to submit queries, or click the stop ([]) button to halt AI generation.

     
   • Resume a chat: Select a title from the Recent list.

4. Organize your chat history:

   • Start a new topic: Click New chat to reset the assistant’s context. When the history panel is collapsed, you must click the Edit square icon to create a new chat.

     
   • Search history: Enter a keyword in the Search field.

   • Rename a session: Click Options next to a chat title, select Rename, and enter a new name.

     
   • Pin a chat: Click Options next to a chat title and select Pin. The chat moves to the Pinned group.

   • Sort chats: Click Sort control and choose a sorting criteria, such as Date (Newest first).

     

   • Delete a chat: Click Options next to a chat title and select Delete.

     

   • Expand or collapse the panel: Click the Expand/collapse icon to toggle the history panel.

     
     Note

     The expanded panel is resizable up to a defined maximum width.

5. Optional: To hide the interface, if you are in the Overlay or Dock to window mode, click the Close Lightspeed icon (X) to hide the window. If you are in Fullscreen mode, revert to the other modes and click the Close Lightspeed icon (X). The system preserves your active query and history.
6. Optional: In Fullscreen mode, bookmark the URL in your browser to save a direct link to the chat interface.

Verification

1. The main window displays the active chat or selected history.
2. The chat history list reflects renamed, pinned, or deleted entries.

Procedure

1. Clone the evaluation repository and navigate to the directory:

   git clone https://github.com/lightspeed-core/lightspeed-evaluation
   cd lightspeed-evaluation

2. Synchronize the environment and install dependencies:

   uv sync

3. Configure the environment variables for the judge LLM. You can create a .env file in the root directory or export the keys directly to your terminal.

   • If you use Gemini, you must set the Gemini API key:

     export GEMINI_API_KEY="your-google-api-key"

   • If you use OpenAI, you must set the OpenAI API key:

     export OPENAI_API_KEY="your-key"

4. Optional: If you test with a live service, set your Developer Lightspeed for RHDH service API key:

   export API_KEY="your-lightspeed-service-key"

Procedure

1. Download pre-generated data sets: Use this method to test the performance of specific RHDH releases. These data sets are generated using Ragas testset generation for RAG.

   1. In your terminal, navigate to the /dataset folder in the evaluation repository.
   2. Locate the .evaluation_dataset_yaml files. These files are pre-configured for the evaluation tool.

   3. To test a historical release, switch to the corresponding branch.

      For example, to access the Red Hat Developer Hub 1.8 data set, switch to the 1.8 branch.

      Important

      The main branch contains work-in-progress (WIP) data sets. Avoid using this branch for stable evaluations.

2. Generate custom data sets: Use this method to create a new test set from your own technical documentation.

   1. Generate a diverse set of question-and-answer (Q&A) pairs by following the Ragas test data generation documentation.
   2. Ensure your Q&A pairs match the required format by reviewing the evaluation data structure configuration.

Procedure

1. Download the system.yaml configuration template from the repository.

2. Configure the parameters in the system.yaml file based on your evaluation mode:

   Field	Description
   llm	Defines the judge LLM that scores the responses, such as gemini-2.5-pro.
   api.enabled	Set to false for static mode to use pre-filled data. Set to true for dynamic mode to call a live service.
   api.api_base	(Required for dynamic mode only) Provide the URL of your Developer Lightspeed for RHDH service.
   api.endpoint_type	Specify the service configuration type: streaming or query.

3. Execute the evaluation by using the lightspeed-eval command:

   lightspeed-eval \
     --system-config config/system.yaml \
     --eval-data config/evaluation_data.yaml \
     --output-dir ./my_evaluation_results

Procedure

1. In the root of the repository, navigate to the version-specific folder within the /evaluation-result directory.

2. Open the following files to evaluate performance:

   • Model Pass Rate: Compare the overall performance between different LLMs.
   • Topic Pass Rate: Identify performance trends and gaps within specific documentation areas.

Procedure

1. In the RHDH interface, click the Lightspeed button.
2. In your Developer Lightspeed for RHDH page, select the Notebooks tab.
3. Click Create a new notebook to start a new workspace.

4. Optional: To manage your workspaces, click the More options icon on a notebook card to Rename, Delete, or add Tags to the session.

   
   
   

Procedure

1. Open a Notebook card from the dashboard.

2. Add resources by using one of the following methods:

   • In the sidebar, click the Add (+) icon.

   • In the main user interface, click Upload a resource.

     
3. Select and upload your local files. Supported formats include .txt, .md, .pdf, .docx, .log, .yaml, and .json.

4. Adhere to the following constraints:

   File size

   Individual files or URL content must be 20MB or smaller.

   Notebook Capacity

   The total token count per session must not exceed 100k.

   Unsupported content

   Avoid scanned PDF images without text, audio, video, and general image files.

   Persistence requirement

   The internal SQL and KV stores must be mapped to a persistent backend to maintain the 100k token context across sessions.

5. Wait for the system to process and vectorize the files. This might take several seconds for larger PDFs.

Procedure

1. Navigate to the RHDH URL provided by your administrator.
2. On the login page, select the appropriate authentication method configured for your environment:
3. Enterprise authentication: Log in with your corporate credentials, such as Single Sign-On or Keycloak.
4. OAuth provider: Select an external provider, such as GitHub or GitLab, if your organization manages developer identities through those services.

5. Guest access: If available, select Enter as Guest for read-only exploration.

   Note

   Guest access has limited permissions. You cannot create or register components with guest access. Production environments typically disable guest access for security. To perform these actions, you must use an authenticated account with the required permissions.

6. Enter your credentials and complete the required authentication prompts.

Verification

1. The portal redirects you to the Home page.

1. The system displays your personalized dashboard, showing your username and recently accessed items.

Procedure

1. Log in to the RHDH interface.
2. In the navigation sidebar, click Catalog.
3. Click the Kind filter and select Component.
4. Optional: Click the Type filter to select a functional category, such as Library, Website, or Tool.
5. In the Search field, enter the name of the component.
6. Select the component card to view the Overview, Docs, and Relationships tabs.

Procedure

1. Navigate to the RHDH interface.
2. In the left navigation sidebar, click Catalog.
3. Select a Component or Service card.
4. Review the tabs at the top of the entity page to view configured plugins:
5. CI/CD: Displays build status and history from tools such as Jenkins or GitHub Actions.
6. Kubernetes: Shows deployment status and pod health.
7. Topology: Visualizes the relationships and status of running resources.

Next steps

1. If a build fails in the CI/CD tab, select the build number to view the logs in the source provider.
2. If a pod is failing in the Kubernetes tab, examine the error events to troubleshoot the deployment.

Procedure

1. Navigate to the RHDH interface.
2. In the left navigation sidebar, click Catalog.
3. Click the Kind filter and select Component.
4. Click the Type filter and select Service.
5. Optional: Narrow the list by selecting a specific Owner or Lifecycle, such as production or experimental.
6. Select a service card to open the detailed entity view.
7. Review the Overview tab to identify the assigned owner and access links to the source code repository.
8. Select the Dependencies or Relations tab to see upstream and downstream connections for that service.

Procedure

1. On the Red Hat Developer Hub navigation menu, click Catalog > Self-service or in the Global Header, click Create (+).
2. On the Self-service page, locate the Templates you want to use and click Choose to start the scaffolding process.
3. Follow the wizard instructions to enter the required project details.

4. In the Review step, verify your parameters and click Create.

   The scaffolding process begins. You can monitor the progress in the logs or click Cancel to stop the operation.

Procedure

1. Open your RHDH app-config.yaml configuration file.

2. In the catalog.rules section, add a rule to allow Templates kinds, as shown in the following example:

   # ...
   catalog:
     rules:
       - allow: [Template]
     locations:
       - type: url
         target: https://<repository_url/template-name>.yaml
   # ...

   where:

   catalog.rules.allow

   Specify the Template rule to allow new Software Templates in the catalog.

   catalog.locations.type

   Specify the url type when importing templates from a repository (for example, GitHub or GitLab).

   catalog.locations.target

   Specify the full URL to the template file.

Verification

1. In the Red Hat Developer Hub navigation menu, click Catalog.
2. From the Kind list, select Template.
3. Verify that the Template list displays your template.

Procedure

1. In the Red Hat Developer Hub navigation menu, click Catalog > Self-service.
2. In the Search field, enter the name for the Software Template.
3. Optional: To refine the results, select a category from the Category list.

Procedure

1. In the left navigation sidebar, click Extensions.
2. Browse the marketplace to review the following categories:
3. Installed: Review the integrations currently active in your instance, such as Jira, ArgoCD, or GitHub.

4. Available: Examine additional integrations supported by the platform that are not yet enabled for your workspace.

   Note

   End users typically cannot install plugins. If you locate a plugin in the marketplace or the Backstage Plugin Directory that your team requires, contact your administrator to request its installation.

Procedure

1. Log in to your RHDH instance.
2. In the left navigation sidebar, locate the standard or custom items that represent specific global extensions, such as:
3. Tech Radar: Use this to visualize your organization’s approved and deprecated technologies.
4. Cost Insights: Use this to track and analyze cloud infrastructure spending for your projects.
5. Developer Lightspeed for RHDH: Access this conversational interface for AI-assisted development help and platform queries.
6. Learning Paths: Access training and educational resources to improve your technical skills.

Procedure

1. In the OpenShift Container Platform web console, find and install the Red Hat Developer Hub Operator from the software catalog.

   For the detailed console steps, see Installing from the software catalog by using the web console in the Red Hat OpenShift Container Platform documentation.

2. On the Install Operator page, configure the following options:

   1. From the Update channel drop-down menu, select fast or fast-1.10.

      Important

      The fast channel includes all of the updates available for a particular version. Any update might introduce unexpected changes in your Red Hat Developer Hub deployment. Check the release notes for details about any potentially breaking changes.

      The fast-1.10 channel only provides z-stream updates, for example, updating from version 1.10.1 to 1.10.2. If you want to update the Red Hat Developer Hub y-version in the future, for example, updating from 1.10 to 2.1, you must switch to the fast-2.1 channel manually.

   2. From the Version drop-down menu, select the version of the Red Hat Developer Hub Operator that you want to install.

   3. For Installation mode, keep the default All namespaces on the cluster option.

      Note

      The Specific namespace on the cluster option is not currently supported.

   4. For Installed Namespace, select Operator recommended Namespace to use the default rhdh-operator namespace.

      Important

      For enhanced security, better control over the Operator lifecycle, and preventing potential privilege escalation, install the Red Hat Developer Hub Operator in a dedicated default rhdh-operator namespace. You can restrict other users' access to the Operator resources through role bindings or cluster role bindings.

      You can also install the Operator in another namespace by creating the necessary resources, such as an Operator group. For more information, see Installing global Operators in custom namespaces.

      However, if the Red Hat Developer Hub Operator shares a namespace with other Operators, then it shares the same update policy as well, preventing the customization of the update policy. For example, if one Operator is set to manual updates, the Red Hat Developer Hub Operator update policy is also set to manual. For more information, see Colocation of Operators in a namespace.

   5. Select the Update approval method and click Install.

Procedure

1. For security, store your secrets as environment variables values in an OpenShift Container Platform secret, rather than in plain text in your configuration files. Collect all your secrets in the secrets.txt file, with one secret per line in KEY=value form.

   Enter your authentication secrets.

2. Author your custom app-config.yaml file. This is the main Developer Hub configuration file. You need a custom app-config.yaml file to avoid the Developer Hub installer to revert user edits during upgrades. When your custom app-config.yaml file is empty, Developer Hub is using default values.

   • To prepare a deployment with the Red Hat Developer Hub Operator on OpenShift Container Platform, you can start with an empty file.

   • To prepare a deployment with the Red Hat Developer Hub Helm chart, or on Kubernetes, enter the Developer Hub base URL in the relevant fields in your app-config.yaml file to ensure proper functionality of Developer Hub. The base URL is what a Developer Hub user sees in their browser when accessing Developer Hub. The relevant fields are baseUrl in the app and backend sections, and origin in the backend.cors subsection:

     Configuring the baseUrl in app-config.yaml:

     app:
       title: Red Hat Developer Hub
       baseUrl: https://<my_developer_hub_domain>
     
     backend:
       auth:
         externalAccess:
           - type: legacy
             options:
               subject: legacy-default-config
               secret: "${BACKEND_SECRET}"
       baseUrl: https://<my_developer_hub_domain>
       cors:
         origin: https://<my_developer_hub_domain>

   • Optionally, enter your configuration such as:

     • Authentication in Red Hat Developer Hub.
     • Authorization in Red Hat Developer Hub.
     • Customization.
     • Configure your OpenShift Container Platform integration.

3. Author your custom dynamic-plugins.yaml file to enable plugins. By default, Developer Hub enables a minimal plugin set, and disables plugins that require configuration or secrets, such as the GitHub repository discovery plugin and the Role-based access control (RBAC) plugin.

   Enable the GitHub repository discovery and the RBAC features:

   dynamic.plugins.yaml

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

4. Provision your custom configuration files to your OpenShift Container Platform cluster.

   1. Create the <my-rhdh-project> project aimed at containing your Developer Hub instance.

      $ oc create namespace my-rhdh-project

   2. Create config maps for your app-config.yaml and dynamic-plugins.yaml files in the <my-rhdh-project> project.

      $ oc create configmap my-rhdh-app-config --from-file=app-config.yaml --namespace=my-rhdh-project
      $ oc create configmap dynamic-plugins-rhdh --from-file=dynamic-plugins.yaml --namespace=my-rhdh-project

      You can also create the config maps by using the web console.

   3. Provision your secrets.txt file to the my-rhdh-secrets secret in the <my-rhdh-project> project.

      $ oc create secret generic my-rhdh-secrets --from-file=secrets.txt --namespace=my-rhdh-project

      You can also create the secret by using the web console.

Procedure

1. From the Developer perspective on the Developer Hub web console, click +Add.
2. From the Developer Catalog panel, click Helm Chart.
3. In the Filter by keyword box, enter Developer Hub and click the Red Hat Developer Hub card.
4. From the Red Hat Developer Hub page, click Create.
5. From your cluster, copy the OpenShift Container Platform router host (for example: apps.<clusterName>.com).

6. Select the radio button to configure the Developer Hub instance with either the form view or YAML view. The Form view is selected by default.

   • Using Form view

     1. To configure the instance with the Form view, go to Root Schema → global → Enable service authentication within Red Hat Developer Hub instance and paste your OpenShift Container Platform router host into the field on the form.

   • Using YAML view

     1. To configure the instance with the YAML view, paste your OpenShift Container Platform router hostname in the global.clusterRouterBase parameter value as shown in the following example:

        global:
          auth:
            backend:
              enabled: true
          clusterRouterBase: apps.<clusterName>.com

7. Edit the other values if needed.
8. Click Create and wait for the database and Developer Hub to start.

9. Click the Open URL icon to start using the Developer Hub platform.

   
   Note

   The host information is copied and can be accessed by the Developer Hub backend.

   When an OpenShift Container Platform route is generated automatically, the host value for the route is inferred and the same host information is sent to the Developer Hub. Also, if the Developer Hub is present on a custom domain by setting the host manually using values, the custom host takes precedence.

Procedure

1. Create and activate the <my-rhdh-project> OpenShift Container Platform project:

   NAMESPACE=<emphasis><rhdh></emphasis>
   oc new-project ${NAMESPACE} || oc project ${NAMESPACE}

2. Install the Red Hat Developer Hub Helm chart:

   helm upgrade redhat-developer-hub -i https://github.com/openshift-helm-charts/charts/releases/download/redhat-redhat-developer-hub-1.10.1/redhat-developer-hub-1.10.1.tgz

3. Configure your Developer Hub Helm chart instance with the Developer Hub database password and router base URL values from your OpenShift Container Platform cluster:

   PASSWORD=$(oc get secret redhat-developer-hub-postgresql -o jsonpath="{.data.password}" | base64 -d)
   CLUSTER_ROUTER_BASE=$(oc get route console -n openshift-console -o=jsonpath='{.spec.host}' | sed 's/^[^.]*\.//')
   helm upgrade redhat-developer-hub -i "https://github.com/openshift-helm-charts/charts/releases/download/redhat-redhat-developer-hub-1.10.1/redhat-developer-hub-1.10.1.tgz" \
       --set global.clusterRouterBase="$CLUSTER_ROUTER_BASE" \
       --set global.postgresql.auth.password="$PASSWORD"

4. Display the running Developer Hub instance URL:

   echo "https://redhat-developer-hub-$NAMESPACE.$CLUSTER_ROUTER_BASE"

Procedure

1. Create the rhdh-operator namespace to contain the Red Hat Developer Hub Operator:

   $ kubectl create namespace rhdh-operator

2. Create a pull secret using your Red Hat credentials to pull the container images from the protected Red Hat Container Registry (registry.redhat.io):

   $ kubectl -n rhdh-operator create secret docker-registry rhdh-pull-secret \
       --docker-server=registry.redhat.io \
       --docker-username=<redhat_user_name> \
       --docker-password=<redhat_password> \
       --docker-email=<email>

3. Create a catalog source that has the Red Hat operators:

   $ cat <<EOF | kubectl -n rhdh-operator apply -f -
   apiVersion: operators.coreos.com/v1alpha1
   kind: CatalogSource
   metadata:
     name: redhat-catalog
   spec:
     sourceType: grpc
     image: registry.redhat.io/redhat/redhat-operator-index:v4.21
     secrets:
     - "rhdh-pull-secret"
     displayName: Red Hat Operators
   EOF

4. Create an operator group to manage your operator subscriptions:

   $ cat <<EOF | kubectl apply -n rhdh-operator -f -
   apiVersion: operators.coreos.com/v1
   kind: OperatorGroup
   metadata:
     name: rhdh-operator-group
   EOF

5. Create a subscription to install the Red Hat Developer Hub Operator:

   $ cat <<EOF | kubectl apply -n rhdh-operator -f -
   apiVersion: operators.coreos.com/v1alpha1
   kind: Subscription
   metadata:
     name: rhdh
     namespace: rhdh-operator
   spec:
     channel: fast
     installPlanApproval: Automatic
     name: rhdh
     source: redhat-catalog
     sourceNamespace: rhdh-operator
     startingCSV: rhdh-operator.v1.10.1
   EOF

6. To wait until the Operator deployment finishes to be able to run the next step, run:

   $ until kubectl -n rhdh-operator get deployment rhdh-operator &>/dev/null; do
     echo -n .
     sleep 3
   done
   echo "RHDH Operator Deployment created"

7. Include your pull secret name in the Operator deployment manifest, to avoid ImagePullBackOff errors:

   $ kubectl -n rhdh-operator patch deployment \
       rhdh-operator --patch '{"spec":{"template":{"spec":{"imagePullSecrets":[{"name":"rhdh-pull-secret"}]}}}}' \
       --type=merge

Procedure

1. For security, store your secrets as environment variables values in an OpenShift Container Platform secret, rather than in plain text in your configuration files. Collect all your secrets in the secrets.txt file, with one secret per line in KEY=value form.

   Enter your authentication secrets.

2. Author your custom app-config.yaml file. This is the main Developer Hub configuration file. You need a custom app-config.yaml file to avoid the Developer Hub installer to revert user edits during upgrades. When your custom app-config.yaml file is empty, Developer Hub is using default values.

   • To prepare a deployment with the Red Hat Developer Hub Operator on OpenShift Container Platform, you can start with an empty file.

   • To prepare a deployment with the Red Hat Developer Hub Helm chart, or on Kubernetes, enter the Developer Hub base URL in the relevant fields in your app-config.yaml file to ensure proper functionality of Developer Hub. The base URL is what a Developer Hub user sees in their browser when accessing Developer Hub. The relevant fields are baseUrl in the app and backend sections, and origin in the backend.cors subsection:

     Configuring the baseUrl in app-config.yaml:

     app:
       title: Red Hat Developer Hub
       baseUrl: https://<my_developer_hub_domain>
     
     backend:
       auth:
         externalAccess:
           - type: legacy
             options:
               subject: legacy-default-config
               secret: "${BACKEND_SECRET}"
       baseUrl: https://<my_developer_hub_domain>
       cors:
         origin: https://<my_developer_hub_domain>

   • Optionally, enter your configuration such as:

     • Authentication in Red Hat Developer Hub.
     • Authorization in Red Hat Developer Hub.
     • Customization.
     • Configure your OpenShift Container Platform integration.

3. Author your custom dynamic-plugins.yaml file to enable plugins. By default, Developer Hub enables a minimal plugin set, and disables plugins that require configuration or secrets, such as the GitHub repository discovery plugin and the Role-based access control (RBAC) plugin.

   Enable the GitHub repository discovery and the RBAC features:

   dynamic.plugins.yaml

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

4. Provision your custom configuration files to your EKS cluster.

   1. Create the <my-rhdh-project> namespace aimed at containing your Developer Hub instance.

      $ oc create namespace my-rhdh-project

   2. Create config maps for your app-config.yaml and dynamic-plugins.yaml files in the <my-rhdh-project> project.

      $ oc create configmap my-rhdh-app-config --from-file=app-config.yaml --namespace=my-rhdh-project
      $ oc create configmap dynamic-plugins-rhdh --from-file=dynamic-plugins.yaml --namespace=my-rhdh-project

      You can also create the config maps by using the web console.

   3. Provision your secrets.txt file to the my-rhdh-secrets secret in the <my-rhdh-project> project.

      $ oc create secret generic my-rhdh-secrets --from-file=secrets.txt --namespace=my-rhdh-project

      You can also create the secret by using the web console.

Procedure

1. Create a pull secret using your Red Hat credentials to pull the container images from the protected Red Hat Container Registry (registry.redhat.io):

   $ kubectl -n {my-rhdh-namespace} create secret docker-registry my-rhdh-pull-secret \
       --docker-server=registry.redhat.io \
       --docker-username=<redhat_user_name> \
       --docker-password=<redhat_password> \
       --docker-email=<email>

2. To enable pulling Developer Hub images from the Red Hat Container Registry, add the image pull secret in the default service account within the namespace where the Developer Hub instance is being deployed:

   $ kubectl patch serviceaccount default \
       -p '{"imagePullSecrets": [{"name": "my-rhdh-pull-secret"}]}' \
       -n {my-rhdh-namespace}

Procedure

1. Author your Backstage CR in a my-rhdh-custom-resource.yaml file to use your custom config maps and secrets.

   Minimal my-rhdh-custom-resource.yaml custom resource example:

   apiVersion: rhdh.redhat.com/v1alpha5
   kind: Backstage
   metadata:
     name: my-rhdh-custom-resource
   spec:
     application:
       appConfig:
         mountPath: /opt/app-root/src
         configMaps:
            - name: my-rhdh-app-config
       extraEnvs:
         secrets:
            - name: <my_product_secrets>
       extraFiles:
         mountPath: /opt/app-root/src
       route:
         enabled: true
     database:
       enableLocalDb: true

   my-rhdh-custom-resource.yaml custom resource example with dynamic plugins and RBAC policies config maps, and external PostgreSQL database secrets:

   apiVersion: rhdh.redhat.com/v1alpha5
   kind: Backstage
   metadata:
     name: <my-rhdh-custom-resource>
   spec:
     application:
       appConfig:
         mountPath: /opt/app-root/src
         configMaps:
            - name: my-rhdh-app-config
            - name: rbac-policies
       dynamicPluginsConfigMapName: dynamic-plugins-rhdh
       extraEnvs:
         secrets:
            - name: <my_product_secrets>
            - name: my-rhdh-database-secrets
       extraFiles:
         mountPath: /opt/app-root/src
         secrets:
           - name: my-rhdh-database-certificates-secrets
             key: postgres-crt.pem, postgres-ca.pem, postgres-key.key
       route:
         enabled: true
     database:
       enableLocalDb: false

   Mandatory fields

   No fields are mandatory. You can create an empty Backstage CR and run Developer Hub with the default configuration.

   Optional fields

   spec.application.appConfig.configMaps

   Enter your config map name list.

   Mount files in the my-rhdh-app-config config map:

   spec:
     application:
       appConfig:
         mountPath: /opt/app-root/src
         configMaps:
            - name: my-rhdh-app-config

   Mount files in the my-rhdh-app-config and rbac-policies config maps:

   spec:
     application:
       appConfig:
         mountPath: /opt/app-root/src
         configMaps:
            - name: my-rhdh-app-config
            - name: rbac-policies

   spec.application.extraEnvs.envs

   Optionally, enter your additional environment variables that are not secrets, such as your proxy environment variables.

   Inject your HTTP_PROXY, HTTPS_PROXY and NO_PROXY environment variables:

   spec:
     application:
       extraEnvs:
         envs:
           - name: HTTP_PROXY
             value: 'http://10.10.10.105:3128'
           - name: HTTPS_PROXY
             value: 'http://10.10.10.106:3128'
           - name: NO_PROXY
             value: 'localhost,example.org'

   spec.application.extraEnvs.secrets

   Enter your environment variables secret name list.

   Inject the environment variables in your Red Hat Developer Hub secret:

   spec:
     application:
       extraEnvs:
         secrets:
            - name: <my_product_secrets>

   Inject the environment variables in the Red Hat Developer Hub and my-rhdh-database-secrets secrets:

   spec:
     application:
       extraEnvs:
         secrets:
            - name: <my_product_secrets>
            - name: my-rhdh-database-secrets

   Note

   <my_product_secrets> is your preferred Developer Hub secret name, specifying the identifier for your secret configuration within Developer Hub.

   spec.application.extraFiles.secrets

   Enter your certificates files secret name and files list.

   Mount the postgres-crt.pem, postgres-ca.pem, and postgres-key.key files contained in the my-rhdh-database-certificates-secrets secret:

   spec:
     application:
       extraFiles:
         mountPath: /opt/app-root/src
         secrets:
           - name: my-rhdh-database-certificates-secrets
             key: postgres-crt.pem, postgres-ca.pem, postgres-key.key

   spec.database.enableLocalDb

   Enable or disable the local PostgreSQL database.

   Disable the local PostgreSQL database generation to use an external postgreSQL database:

   spec:
     database:
       enableLocalDb: false

   On a development environment, use the local PostgreSQL database:

   spec:
     database:
       enableLocalDb: true

   spec.deployment

   Optionally, enter your deployment configuration.

2. Apply your Backstage CR to start or update your Developer Hub instance:

   $ oc apply --filename=my-rhdh-custom-resource.yaml --namespace=my-rhdh-project

Procedure

1. Create an Ingress manifest file, named rhdh-ingress.yaml, specifying your Developer Hub service name as follows:

   apiVersion: networking.k8s.io/v1
   kind: Ingress
   metadata:
     name: my-rhdh-ingress
     annotations:
       alb.ingress.kubernetes.io/scheme: internet-facing
       alb.ingress.kubernetes.io/target-type: ip
       # TODO: Using an ALB HTTPS Listener requires a certificate for your own domain. Fill in the ARN of your certificate, e.g.:
       alb.ingress.kubernetes.io/certificate-arn: arn:aws:acm:us-xxx:xxxx:certificate/xxxxxx
       alb.ingress.kubernetes.io/listen-ports: '[{"HTTP": 80}, {"HTTPS":443}]'
       alb.ingress.kubernetes.io/ssl-redirect: '443'
       external-dns.alpha.kubernetes.io/hostname: <my_developer_hub_domain>
   spec:
     ingressClassName: alb
     rules:
       - host: <my_developer_hub_domain>
         http:
           paths:
           - path: /
             pathType: Prefix
             backend:
               service:
                 name: my-rhdh-custom-resource
                 port:
                   name: http-backend
   EOF

   Replace <my_developer_hub_domain> with your Developer Hub domain name and update the value of alb.ingress.kubernetes.io/certificate-arn with your certificate ARN.

2. Update your required domain name, (for example, in Route 53 or your external DNS service) to point to the provisioned IP address. Elastic Kubernetes Service provisions an Application Load Balancer (ALB) with a corresponding IP address.

3. To deploy the created Ingress, run:

   $ kubectl -n my-rhdh-project apply -f rhdh-ingress.yaml

Procedure

1. For security, store your secrets as environment variables values in an OpenShift Container Platform secret, rather than in plain text in your configuration files. Collect all your secrets in the secrets.txt file, with one secret per line in KEY=value form.

   Enter your authentication secrets.

2. Author your custom app-config.yaml file. This is the main Developer Hub configuration file. You need a custom app-config.yaml file to avoid the Developer Hub installer to revert user edits during upgrades. When your custom app-config.yaml file is empty, Developer Hub is using default values.

   • To prepare a deployment with the Red Hat Developer Hub Operator on OpenShift Container Platform, you can start with an empty file.

   • To prepare a deployment with the Red Hat Developer Hub Helm chart, or on Kubernetes, enter the Developer Hub base URL in the relevant fields in your app-config.yaml file to ensure proper functionality of Developer Hub. The base URL is what a Developer Hub user sees in their browser when accessing Developer Hub. The relevant fields are baseUrl in the app and backend sections, and origin in the backend.cors subsection:

     Configuring the baseUrl in app-config.yaml:

     app:
       title: Red Hat Developer Hub
       baseUrl: https://<my_developer_hub_domain>
     
     backend:
       auth:
         externalAccess:
           - type: legacy
             options:
               subject: legacy-default-config
               secret: "${BACKEND_SECRET}"
       baseUrl: https://<my_developer_hub_domain>
       cors:
         origin: https://<my_developer_hub_domain>

   • Optionally, enter your configuration such as:

     • Authentication in Red Hat Developer Hub.
     • Authorization in Red Hat Developer Hub.
     • Customization.
     • Configure your OpenShift Container Platform integration.

3. Author your custom dynamic-plugins.yaml file to enable plugins. By default, Developer Hub enables a minimal plugin set, and disables plugins that require configuration or secrets, such as the GitHub repository discovery plugin and the Role-based access control (RBAC) plugin.

   Enable the GitHub repository discovery and the RBAC features:

   dynamic.plugins.yaml

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

4. Provision your custom configuration files to your GKE cluster.

   1. Create the <my-rhdh-project> namespace aimed at containing your Developer Hub instance.

      $ oc create namespace my-rhdh-project

   2. Create config maps for your app-config.yaml and dynamic-plugins.yaml files in the <my-rhdh-project> project.

      $ oc create configmap my-rhdh-app-config --from-file=app-config.yaml --namespace=my-rhdh-project
      $ oc create configmap dynamic-plugins-rhdh --from-file=dynamic-plugins.yaml --namespace=my-rhdh-project

      You can also create the config maps by using the web console.

   3. Provision your secrets.txt file to the my-rhdh-secrets secret in the <my-rhdh-project> project.

      $ oc create secret generic my-rhdh-secrets --from-file=secrets.txt --namespace=my-rhdh-project

      You can also create the secret by using the web console.

Procedure

1. Create a pull secret using your Red Hat credentials to pull the container images from the protected Red Hat Container Registry (registry.redhat.io):

   $ kubectl -n {my-rhdh-namespace} create secret docker-registry my-rhdh-pull-secret \
       --docker-server=registry.redhat.io \
       --docker-username=<redhat_user_name> \
       --docker-password=<redhat_password> \
       --docker-email=<email>

2. To enable pulling Developer Hub images from the Red Hat Container Registry, add the image pull secret in the default service account within the namespace where the Developer Hub instance is being deployed:

   $ kubectl patch serviceaccount default \
       -p '{"imagePullSecrets": [{"name": "my-rhdh-pull-secret"}]}' \
       -n {my-rhdh-namespace}

Procedure

1. Author your Backstage CR in a my-rhdh-custom-resource.yaml file to use your custom config maps and secrets.

   Minimal my-rhdh-custom-resource.yaml custom resource example:

   apiVersion: rhdh.redhat.com/v1alpha5
   kind: Backstage
   metadata:
     name: my-rhdh-custom-resource
   spec:
     application:
       appConfig:
         mountPath: /opt/app-root/src
         configMaps:
            - name: my-rhdh-app-config
       extraEnvs:
         secrets:
            - name: <my_product_secrets>
       extraFiles:
         mountPath: /opt/app-root/src
       route:
         enabled: true
     database:
       enableLocalDb: true

   my-rhdh-custom-resource.yaml custom resource example with dynamic plugins and RBAC policies config maps, and external PostgreSQL database secrets:

   apiVersion: rhdh.redhat.com/v1alpha5
   kind: Backstage
   metadata:
     name: <my-rhdh-custom-resource>
   spec:
     application:
       appConfig:
         mountPath: /opt/app-root/src
         configMaps:
            - name: my-rhdh-app-config
            - name: rbac-policies
       dynamicPluginsConfigMapName: dynamic-plugins-rhdh
       extraEnvs:
         secrets:
            - name: <my_product_secrets>
            - name: my-rhdh-database-secrets
       extraFiles:
         mountPath: /opt/app-root/src
         secrets:
           - name: my-rhdh-database-certificates-secrets
             key: postgres-crt.pem, postgres-ca.pem, postgres-key.key
       route:
         enabled: true
     database:
       enableLocalDb: false

   Mandatory fields

   No fields are mandatory. You can create an empty Backstage CR and run Developer Hub with the default configuration.

   Optional fields

   spec.application.appConfig.configMaps

   Enter your config map name list.

   Mount files in the my-rhdh-app-config config map:

   spec:
     application:
       appConfig:
         mountPath: /opt/app-root/src
         configMaps:
            - name: my-rhdh-app-config

   Mount files in the my-rhdh-app-config and rbac-policies config maps:

   spec:
     application:
       appConfig:
         mountPath: /opt/app-root/src
         configMaps:
            - name: my-rhdh-app-config
            - name: rbac-policies

   spec.application.extraEnvs.envs

   Optionally, enter your additional environment variables that are not secrets, such as your proxy environment variables.

   Inject your HTTP_PROXY, HTTPS_PROXY and NO_PROXY environment variables:

   spec:
     application:
       extraEnvs:
         envs:
           - name: HTTP_PROXY
             value: 'http://10.10.10.105:3128'
           - name: HTTPS_PROXY
             value: 'http://10.10.10.106:3128'
           - name: NO_PROXY
             value: 'localhost,example.org'

   spec.application.extraEnvs.secrets

   Enter your environment variables secret name list.

   Inject the environment variables in your Red Hat Developer Hub secret:

   spec:
     application:
       extraEnvs:
         secrets:
            - name: <my_product_secrets>

   Inject the environment variables in the Red Hat Developer Hub and my-rhdh-database-secrets secrets:

   spec:
     application:
       extraEnvs:
         secrets:
            - name: <my_product_secrets>
            - name: my-rhdh-database-secrets

   Note

   <my_product_secrets> is your preferred Developer Hub secret name, specifying the identifier for your secret configuration within Developer Hub.

   spec.application.extraFiles.secrets

   Enter your certificates files secret name and files list.

   Mount the postgres-crt.pem, postgres-ca.pem, and postgres-key.key files contained in the my-rhdh-database-certificates-secrets secret:

   spec:
     application:
       extraFiles:
         mountPath: /opt/app-root/src
         secrets:
           - name: my-rhdh-database-certificates-secrets
             key: postgres-crt.pem, postgres-ca.pem, postgres-key.key

   spec.database.enableLocalDb

   Enable or disable the local PostgreSQL database.

   Disable the local PostgreSQL database generation to use an external postgreSQL database:

   spec:
     database:
       enableLocalDb: false

   On a development environment, use the local PostgreSQL database:

   spec:
     database:
       enableLocalDb: true

   spec.deployment

   Optionally, enter your deployment configuration.

2. Apply your Backstage CR to start or update your Developer Hub instance:

   $ oc apply --filename=my-rhdh-custom-resource.yaml --namespace=my-rhdh-project

Procedure

1. Create a Google-managed certificate manifest file, named managed-certificate.yaml:

   apiVersion: networking.gke.io/v1
   kind: ManagedCertificate
   metadata:
     name: my-rhdh-certificate-name
   spec:
     domains:
       - <my_developer_hub_domain>

   For more information about setting up a Google-managed certificate, see Setting up a Google-managed certificate.

2. Deploy the managed certificate:

   $ kubectl -n my-rhdh-project apply -f managed-certificate.yaml

3. Create a front-end config manifest file, named frontend-config.yaml, to set a policy for redirecting to HTTPS.

   apiVersion: networking.gke.io/v1beta1
   kind: FrontendConfig
   metadata:
     name: my-ingress_security_config
   spec:
     sslPolicy: gke-ingress-ssl-policy-https
     redirectToHttps:
       enabled: true

   For more information about setting a policy to redirect to HTTPS, see HTTP to HTTPS redirects.

4. Deploy the front-end config:

   $ kubectl -n my-rhdh-project apply -f frontend-config.yaml

5. Create an ingress manifest file, named rhdh-ingress.yaml, specifying your Developer Hub service name, and using your managed certificate and your front-end config:

   apiVersion: networking.k8s.io/v1
   kind: Ingress
   metadata:
     name: my-rhdh-ingress
     annotations:
       kubernetes.io/ingress.class: "gce"
       kubernetes.io/ingress.global-static-ip-name: <ADDRESS_NAME>
       networking.gke.io/managed-certificates: my-rhdh-certificate-name
       networking.gke.io/v1beta1.FrontendConfig: my-ingress_security_config
   spec:
     ingressClassName: gce
     rules:
       - host: <my_developer_hub_domain>
         http:
           paths:
           - path: /
             pathType: Prefix
             backend:
               service:
                 name: my-rhdh-custom-resource
                 port:
                   name: http-backend

6. Deploy the ingress:

   $ kubectl -n my-rhdh-project apply -f rhdh-ingress.yaml

Verification

1. Wait for the system to provision the ManagedCertificate. This process can take a couple of hours.
2. Access RHDH with https://<my_developer_hub_domain>.

Procedure

1. Create the rhdh-operator namespace to contain the Red Hat Developer Hub Operator:

   $ kubectl create namespace rhdh-operator

2. Create a pull secret using your Red Hat credentials to pull the container images from the protected Red Hat Container Registry (registry.redhat.io):

   $ kubectl -n rhdh-operator create secret docker-registry rhdh-pull-secret \
       --docker-server=registry.redhat.io \
       --docker-username=<redhat_user_name> \
       --docker-password=<redhat_password> \
       --docker-email=<email>

3. Create a catalog source that has the Red Hat operators:

   $ cat <<EOF | kubectl -n rhdh-operator apply -f -
   apiVersion: operators.coreos.com/v1alpha1
   kind: CatalogSource
   metadata:
     name: redhat-catalog
   spec:
     sourceType: grpc
     image: registry.redhat.io/redhat/redhat-operator-index:v4.21
     secrets:
     - "rhdh-pull-secret"
     displayName: Red Hat Operators
   EOF

4. Create an operator group to manage your operator subscriptions:

   $ cat <<EOF | kubectl apply -n rhdh-operator -f -
   apiVersion: operators.coreos.com/v1
   kind: OperatorGroup
   metadata:
     name: rhdh-operator-group
   EOF

5. Create a subscription to install the Red Hat Developer Hub Operator:

   $ cat <<EOF | kubectl apply -n rhdh-operator -f -
   apiVersion: operators.coreos.com/v1alpha1
   kind: Subscription
   metadata:
     name: rhdh
     namespace: rhdh-operator
   spec:
     channel: fast
     installPlanApproval: Automatic
     name: rhdh
     source: redhat-catalog
     sourceNamespace: rhdh-operator
     startingCSV: rhdh-operator.v1.10.1
   EOF

6. To wait until the Operator deployment finishes to be able to run the next step, run:

   $ until kubectl -n rhdh-operator get deployment rhdh-operator &>/dev/null; do
     echo -n .
     sleep 3
   done
   echo "RHDH Operator Deployment created"

7. Include your pull secret name in the Operator deployment manifest, to avoid ImagePullBackOff errors:

   $ kubectl -n rhdh-operator patch deployment \
       rhdh-operator --patch '{"spec":{"template":{"spec":{"imagePullSecrets":[{"name":"rhdh-pull-secret"}]}}}}' \
       --type=merge

Procedure

1. For security, store your secrets as environment variables values in an OpenShift Container Platform secret, rather than in plain text in your configuration files. Collect all your secrets in the secrets.txt file, with one secret per line in KEY=value form.

   Enter your authentication secrets.

2. Author your custom app-config.yaml file. This is the main Developer Hub configuration file. You need a custom app-config.yaml file to avoid the Developer Hub installer to revert user edits during upgrades. When your custom app-config.yaml file is empty, Developer Hub is using default values.

   • To prepare a deployment with the Red Hat Developer Hub Operator on OpenShift Container Platform, you can start with an empty file.

   • To prepare a deployment with the Red Hat Developer Hub Helm chart, or on Kubernetes, enter the Developer Hub base URL in the relevant fields in your app-config.yaml file to ensure proper functionality of Developer Hub. The base URL is what a Developer Hub user sees in their browser when accessing Developer Hub. The relevant fields are baseUrl in the app and backend sections, and origin in the backend.cors subsection:

     Configuring the baseUrl in app-config.yaml:

     app:
       title: Red Hat Developer Hub
       baseUrl: https://<my_developer_hub_domain>
     
     backend:
       auth:
         externalAccess:
           - type: legacy
             options:
               subject: legacy-default-config
               secret: "${BACKEND_SECRET}"
       baseUrl: https://<my_developer_hub_domain>
       cors:
         origin: https://<my_developer_hub_domain>

   • Optionally, enter your configuration such as:

     • Authentication in Red Hat Developer Hub.
     • Authorization in Red Hat Developer Hub.
     • Customization.
     • Configure your OpenShift Container Platform integration.

3. Author your custom dynamic-plugins.yaml file to enable plugins. By default, Developer Hub enables a minimal plugin set, and disables plugins that require configuration or secrets, such as the GitHub repository discovery plugin and the Role-based access control (RBAC) plugin.

   Enable the GitHub repository discovery and the RBAC features:

   dynamic.plugins.yaml

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

4. Provision your custom configuration files to your AKS cluster.

   1. Create the <my-rhdh-project> namespace aimed at containing your Developer Hub instance.

      $ oc create namespace my-rhdh-project

   2. Create config maps for your app-config.yaml and dynamic-plugins.yaml files in the <my-rhdh-project> project.

      $ oc create configmap my-rhdh-app-config --from-file=app-config.yaml --namespace=my-rhdh-project
      $ oc create configmap dynamic-plugins-rhdh --from-file=dynamic-plugins.yaml --namespace=my-rhdh-project

      You can also create the config maps by using the web console.

   3. Provision your secrets.txt file to the my-rhdh-secrets secret in the <my-rhdh-project> project.

      $ oc create secret generic my-rhdh-secrets --from-file=secrets.txt --namespace=my-rhdh-project

      You can also create the secret by using the web console.

Procedure

1. Create a pull secret using your Red Hat credentials to pull the container images from the protected Red Hat Container Registry (registry.redhat.io):

   $ kubectl -n {my-rhdh-namespace} create secret docker-registry my-rhdh-pull-secret \
       --docker-server=registry.redhat.io \
       --docker-username=<redhat_user_name> \
       --docker-password=<redhat_password> \
       --docker-email=<email>

2. To enable pulling Developer Hub images from the Red Hat Container Registry, add the image pull secret in the default service account within the namespace where the Developer Hub instance is being deployed:

   $ kubectl patch serviceaccount default \
       -p '{"imagePullSecrets": [{"name": "my-rhdh-pull-secret"}]}' \
       -n {my-rhdh-namespace}

Procedure

1. Author your Backstage CR in a my-rhdh-custom-resource.yaml file to use your custom config maps and secrets.

   Minimal my-rhdh-custom-resource.yaml custom resource example:

   apiVersion: rhdh.redhat.com/v1alpha5
   kind: Backstage
   metadata:
     name: my-rhdh-custom-resource
   spec:
     application:
       appConfig:
         mountPath: /opt/app-root/src
         configMaps:
            - name: my-rhdh-app-config
       extraEnvs:
         secrets:
            - name: <my_product_secrets>
       extraFiles:
         mountPath: /opt/app-root/src
       route:
         enabled: true
     database:
       enableLocalDb: true

   my-rhdh-custom-resource.yaml custom resource example with dynamic plugins and RBAC policies config maps, and external PostgreSQL database secrets:

   apiVersion: rhdh.redhat.com/v1alpha5
   kind: Backstage
   metadata:
     name: <my-rhdh-custom-resource>
   spec:
     application:
       appConfig:
         mountPath: /opt/app-root/src
         configMaps:
            - name: my-rhdh-app-config
            - name: rbac-policies
       dynamicPluginsConfigMapName: dynamic-plugins-rhdh
       extraEnvs:
         secrets:
            - name: <my_product_secrets>
            - name: my-rhdh-database-secrets
       extraFiles:
         mountPath: /opt/app-root/src
         secrets:
           - name: my-rhdh-database-certificates-secrets
             key: postgres-crt.pem, postgres-ca.pem, postgres-key.key
       route:
         enabled: true
     database:
       enableLocalDb: false

   Mandatory fields

   No fields are mandatory. You can create an empty Backstage CR and run Developer Hub with the default configuration.

   Optional fields

   spec.application.appConfig.configMaps

   Enter your config map name list.

   Mount files in the my-rhdh-app-config config map:

   spec:
     application:
       appConfig:
         mountPath: /opt/app-root/src
         configMaps:
            - name: my-rhdh-app-config

   Mount files in the my-rhdh-app-config and rbac-policies config maps:

   spec:
     application:
       appConfig:
         mountPath: /opt/app-root/src
         configMaps:
            - name: my-rhdh-app-config
            - name: rbac-policies

   spec.application.extraEnvs.envs

   Optionally, enter your additional environment variables that are not secrets, such as your proxy environment variables.

   Inject your HTTP_PROXY, HTTPS_PROXY and NO_PROXY environment variables:

   spec:
     application:
       extraEnvs:
         envs:
           - name: HTTP_PROXY
             value: 'http://10.10.10.105:3128'
           - name: HTTPS_PROXY
             value: 'http://10.10.10.106:3128'
           - name: NO_PROXY
             value: 'localhost,example.org'

   spec.application.extraEnvs.secrets

   Enter your environment variables secret name list.

   Inject the environment variables in your Red Hat Developer Hub secret:

   spec:
     application:
       extraEnvs:
         secrets:
            - name: <my_product_secrets>

   Inject the environment variables in the Red Hat Developer Hub and my-rhdh-database-secrets secrets:

   spec:
     application:
       extraEnvs:
         secrets:
            - name: <my_product_secrets>
            - name: my-rhdh-database-secrets

   Note

   <my_product_secrets> is your preferred Developer Hub secret name, specifying the identifier for your secret configuration within Developer Hub.

   spec.application.extraFiles.secrets

   Enter your certificates files secret name and files list.

   Mount the postgres-crt.pem, postgres-ca.pem, and postgres-key.key files contained in the my-rhdh-database-certificates-secrets secret:

   spec:
     application:
       extraFiles:
         mountPath: /opt/app-root/src
         secrets:
           - name: my-rhdh-database-certificates-secrets
             key: postgres-crt.pem, postgres-ca.pem, postgres-key.key

   spec.database.enableLocalDb

   Enable or disable the local PostgreSQL database.

   Disable the local PostgreSQL database generation to use an external postgreSQL database:

   spec:
     database:
       enableLocalDb: false

   On a development environment, use the local PostgreSQL database:

   spec:
     database:
       enableLocalDb: true

   spec.deployment

   Optionally, enter your deployment configuration.

2. Apply your Backstage CR to start or update your Developer Hub instance:

   $ oc apply --filename=my-rhdh-custom-resource.yaml --namespace=my-rhdh-project

Procedure

1. Create an Ingress manifest file, named rhdh-ingress.yaml, specifying your Developer Hub service name as follows:

   apiVersion: networking.k8s.io/v1
   kind: Ingress
   metadata:
     name: my-rhdh-ingress
     namespace: my-rhdh-project
   spec:
     ingressClassName: webapprouting.kubernetes.azure.com
     rules:
       - http:
           paths:
             - path: /
               pathType: Prefix
               backend:
                 service:
                   name: my-rhdh-custom-resource
                   port:
                     name: http-backend

2. To deploy the created Ingress, run the following command:

   $ kubectl -n my-rhdh-project apply -f rhdh-ingress.yaml

Procedure

1. Download the mirroring script to disk by running the following command:

   $ curl -sSLO https://raw.githubusercontent.com/redhat-developer/rhdh-operator/refs/heads/release-1.10/.rhdh/scripts/prepare-restricted-environment.sh

2. Run the mirroring script by using the bash command with the appropriate set of options:

   $ bash prepare-restricted-environment.sh
    --filter-versions "1.10"
    --to-dir <my_pulled_image_location>
    [--use-oc-mirror true]

   where:

   --to-dir <my_pulled_image_location>

   Enter the absolute path to a directory where you want to pull all of the necessary images, for example, /home/user/rhdh-operator-mirror-dir.

   --use-oc-mirror true

   (Recommended on OpenShift Container Platform) Use the oc-mirror OpenShift Container Platform CLI plugin to mirror images.

   Note

   The script can take several minutes to complete as it copies many images to the mirror registry.

3. Transfer the directory specified by the --to-dir option to your disconnected environment.

4. From a machine in your disconnected environment that has access to both the cluster and the target mirror registry, run the mirroring script by using the bash command with the appropriate set of options:

   $ bash <my_pulled_image_location>/install.sh
       --from-dir <my_pulled_image_location>
       [--to-registry <my.registry.example.com>]
       [--use-oc-mirror true]

   where:

   <my_pulled_image_location>/install.sh

   Enter the downloaded installation script and the absolute path to the directory where you stored it on your system.

   --from-dir <my_pulled_image_location>

   Enter the directory where you want to pull all of the necessary images.

   --to-registry

   (Optional) Enter the URL for the target mirror registry where you want to mirror the images.

   --use-oc-mirror true

   Recommended on OpenShift Container Platform: Use the oc mirror OpenShift Container Platform CLI plugin to mirror images.

   Important

   If you used oc mirror to mirror the images to disk, you must also use oc mirror to mirror the images from disk due to the folder layout that oc mirror uses.

   Note

   The script can take several minutes to complete as it automatically installs the Red Hat Developer Hub Operator.

5. If deploying on OpenShift Container Platform, update the cluster pull secret to allow the kubelet to pull all Red Hat Developer Hub images from your mirror registry:

   $ oc get secret pull-secret -n openshift-config -o json | \
     jq -r '.data.".dockerconfigjson"' | base64 -d | \
     jq --arg registry "<mirror_registry>" \
        --arg auth "$(echo -n '<username>:<password>' | base64)" \
        '.auths[$registry] = {"auth": $auth}' | \
     oc set data secret/pull-secret -n openshift-config --from-file=.dockerconfigjson=/dev/stdin

   where:

   <mirror_registry>

   Enter the hostname and port of your mirror registry, for example, registry.example.com:5000.

   <username>:<password>

   Enter the credentials for authenticating to your mirror registry.

   Note

   Wait for all machine config pools to finish updating before proceeding.

6. If deploying on a supported Kubernetes platform, create a pull secret to allow the kubelet to pull all Red Hat Developer Hub images from your mirror registry:

   $ kubectl create secret docker-registry rhdh-pull-secret \
       --docker-server=<mirror_registry> \
       --docker-username=<username> \
       --docker-password=<password> \
       --namespace=<target_namespace>
   
   $ kubectl patch serviceaccount default \
       --namespace=<target_namespace> \
       --type='json' \
       --patch='[{"op":"add","path":"/imagePullSecrets/-","value":{"name":"rhdh-pull-secret"}}]'

   where:

   <mirror_registry>

   Enter the hostname and port of your mirror registry.

   <username>

   Enter the username for authenticating to your mirror registry.

   <password>

   Enter the password for authenticating to your mirror registry.

   <target_namespace>

   Enter the namespace where the Operator will deploy Red Hat Developer Hub instances, for example, rhdh.

7. Download the plugin mirroring script by running the following command:

   $ curl -sSLO https://raw.githubusercontent.com/redhat-developer/rhdh-operator/refs/heads/release-1.10/.rhdh/scripts/mirror-plugins.sh

8. Export the plugin catalog index and all referenced plugin OCI artifacts to disk by running the following command:

   $ bash mirror-plugins.sh \
     --plugin-index oci://registry.access.redhat.com/rhdh/plugin-catalog-index:1.10 \
     --to-dir <my_plugin_mirror_dir>

   where:

   <my_plugin_mirror_dir>

   Enter the absolute path to a directory where you want to export the plugin artifacts, for example, /home/user/rhdh-plugins-mirror.

   Note

   The script can take several minutes to complete. It mirrors the catalog index image and all plugin OCI artifacts that the index references.

9. Transfer the directory specified by the --to-dir option to your disconnected environment.

10. From a machine in your disconnected environment that has access to the target mirror registry, import the plugin artifacts by running the following command:

    $ bash mirror-plugins.sh \
      --from-dir <my_plugin_mirror_dir> \
      --to-registry <target_registry>

    where:

    <my_plugin_mirror_dir>

    Enter the path to the directory containing the exported plugin artifacts.

    <target_registry>

    Enter the URL of the target mirror registry, for example, registry.example.com.

11. Create a config map containing a registries.conf file that redirects the install-dynamic-plugins init container to your mirror registry:

    apiVersion: v1
    kind: ConfigMap
    metadata:
      name: rhdh-plugin-mirror-conf
    data:
      rhdh-registries.conf: |
        [[registry]]
        prefix = "registry.access.redhat.com/rhdh"
        location = "<target_registry>/rhdh"
    
        [[registry]]
        prefix = "quay.io/rhdh"
        location = "<target_registry>/rhdh"

    where:

    <target_registry>

    Enter the URL of your mirror registry, for example, registry.example.com.

12. Mount the config map in the install-dynamic-plugins init container by adding the following to your Backstage CR:

    spec:
      application:
        extraFiles:
          configMaps:
            - name: rhdh-plugin-mirror-conf
              key: rhdh-registries.conf
              mountPath: /etc/containers/registries.conf.d
              containers:
                - install-dynamic-plugins

    Note

    Cluster-level mirroring resources such as ImageDigestMirrorSet or ImageContentSourcePolicy do not apply to the install-dynamic-plugins init container because it uses skopeo directly to pull plugin artifacts.

13. Optional: To enforce signature verification in production environments, create a policy.json config map and mount it in the install-dynamic-plugins init container:

    apiVersion: v1
    kind: ConfigMap
    metadata:
      name: rhdh-mirror-policy
    data:
      policy.json: |
        {
          "transports": {
            "docker": {
              "<target_registry>/<namespace>": [
                {
                  "type": "signedBy",
                  "keyType": "GPGKeys",
                  "keyPath": "<path_to_gpg_key>"
                }
              ]
            }
          }
        }

    Then add the following to the extraFiles.configMaps list in your Backstage CR:

            - name: rhdh-mirror-policy
              key: policy.json
              mountPath: /etc/containers
              containers:
                - install-dynamic-plugins

    For a full example CR showing how to configure plugin mirroring when using the Operator, see plugin-mirroring.yaml.

Verification

1. If you are using Red Hat OpenShift Container Platform, the Red Hat Developer Hub Operator is in the Installed Operators list in the web console.

2. If you are using a supported Kubernetes platform, you can check the list of pods running in the rhdh-operator namespace by running the following command in your terminal:

   kubectl -n rhdh-operator get pods

Next steps

1. Use the Operator to create a Red Hat Developer Hub instance on a supported platform. For more information, see the following documentation for the platform that you want to use:

   • Installing Red Hat Developer Hub on OpenShift Container Platform with the Operator
   • Installing Developer Hub on EKS with the Operator
   • Installing Developer Hub on AKS with the Operator
   • Installing Developer Hub on Google Cloud with the Operator
   • Deploying Developer Hub on GKE with the Operator

Procedure

1. In your terminal, navigate to the directory where you want to save the mirroring script.

2. Download the mirroring script by running the following command:

   $ curl -sSLO https://raw.githubusercontent.com/redhat-developer/rhdh-operator/refs/heads/release-1.10/.rhdh/scripts/prepare-restricted-environment.sh

3. Run the mirroring script by using the bash command with the appropriate set of options:

   $ bash prepare-restricted-environment.sh \
    --filter-versions "1.10" \
     [--to-registry <my.registry.example.com>] \
     [--use-oc-mirror true]

   where:

   --to-registry _<my.registry.example.com>

   Enter the URL for the target mirror registry where you want to mirror the images.

   --use-oc-mirror true

   Optional: Use the oc mirror OpenShift Container Platform CLI plugin to mirror images.

   Note

   The script can take several minutes to complete as it copies many images to the mirror registry.

4. If deploying on OpenShift Container Platform, update the cluster pull secret to allow the kubelet to pull all Red Hat Developer Hub images from your mirror registry:

   $ oc get secret pull-secret -n openshift-config -o json | \
     jq -r '.data.".dockerconfigjson"' | base64 -d | \
     jq --arg registry "<mirror_registry>" \
        --arg auth "$(echo -n '<username>:<password>' | base64)" \
        '.auths[$registry] = {"auth": $auth}' | \
     oc set data secret/pull-secret -n openshift-config --from-file=.dockerconfigjson=/dev/stdin

   where:

   <mirror_registry>

   Enter the hostname and port of your mirror registry, for example, registry.example.com:5000.

   <username>:<password>

   Enter the credentials for authenticating to your mirror registry.

   Note

   Wait for all machine config pools to finish updating before proceeding.

5. If deploying on a supported Kubernetes platform, create a pull secret to allow the kubelet to pull all Red Hat Developer Hub images from your mirror registry:

   $ kubectl create secret docker-registry rhdh-pull-secret \
       --docker-server=<mirror_registry> \
       --docker-username=<username> \
       --docker-password=<password> \
       --namespace=<target_namespace>
   
   $ kubectl patch serviceaccount default \
       --namespace=<target_namespace> \
       --type='json' \
       --patch='[{"op":"add","path":"/imagePullSecrets/-","value":{"name":"rhdh-pull-secret"}}]'

   where:

   <mirror_registry>

   Enter the hostname and port of your mirror registry.

   <username>

   Enter the username for authenticating to your mirror registry.

   <password>

   Enter the password for authenticating to your mirror registry.

   <target_namespace>

   Enter the namespace where the Operator will deploy Red Hat Developer Hub instances, for example, rhdh.

6. Download the plugin mirroring script by running the following command:

   $ curl -sSLO https://raw.githubusercontent.com/redhat-developer/rhdh-operator/refs/heads/release-1.10/.rhdh/scripts/mirror-plugins.sh

7. Mirror the plugin catalog index and all referenced plugin OCI artifacts to your target registry by running the following command:

   $ bash mirror-plugins.sh \
     --plugin-index oci://registry.access.redhat.com/rhdh/plugin-catalog-index:1.10 \
     --to-registry <target_registry>

   where:

   <target_registry>

   Enter the URL of the target mirror registry, such as, registry.example.com.

   Note

   The script can take several minutes to complete. It mirrors the catalog index image and all plugin OCI artifacts that the index references.

8. Create a config map containing a registries.conf file that redirects the install-dynamic-plugins init container to your mirror registry:

   apiVersion: v1
   kind: ConfigMap
   metadata:
     name: rhdh-plugin-mirror-conf
   data:
     rhdh-registries.conf: |
       [[registry]]
       prefix = "registry.access.redhat.com/rhdh"
       location = "<target_registry>/rhdh"
   
       [[registry]]
       prefix = "quay.io/rhdh"
       location = "<target_registry>/rhdh"

   where:

   <target_registry>

   Enter the URL of your mirror registry, for example, registry.example.com.

9. Mount the config map in the install-dynamic-plugins init container by adding the following to your Backstage CR:

   spec:
     application:
       extraFiles:
         configMaps:
           - name: rhdh-plugin-mirror-conf
             key: rhdh-registries.conf
             mountPath: /etc/containers/registries.conf.d
             containers:
               - install-dynamic-plugins

   Note

   Cluster-level mirroring resources such as ImageDigestMirrorSet or ImageContentSourcePolicy do not apply to the install-dynamic-plugins init container because it uses skopeo directly to pull plugin artifacts.

10. Optional: To enforce signature verification in production environments, create a policy.json config map and mount it in the install-dynamic-plugins init container:

    apiVersion: v1
    kind: ConfigMap
    metadata:
      name: rhdh-mirror-policy
    data:
      policy.json: |
        {
          "transports": {
            "docker": {
              "<target_registry>/<namespace>": [
                {
                  "type": "signedBy",
                  "keyType": "GPGKeys",
                  "keyPath": "<path_to_gpg_key>"
                }
              ]
            }
          }
        }

    Then add the following to the extraFiles.configMaps list in your Backstage CR:

            - name: rhdh-mirror-policy
              key: policy.json
              mountPath: /etc/containers
              containers:
                - install-dynamic-plugins

    For a full example CR showing how to configure plugin mirroring when using the Operator, see plugin-mirroring.yaml.

Verification

1. If you are using Red Hat OpenShift Container Platform, the Red Hat Developer Hub Operator is in the Installed Operators list in the web console.

2. If you are using a supported Kubernetes platform, you can check the list of pods running in the rhdh-operator namespace by running the following command in your terminal:

   $ kubectl -n rhdh-operator get pods

Next steps

1. Use the Operator to create a Red Hat Developer Hub instance on a supported platform. For more information, see the following documentation for the platform that you want to use:

   • Installing Red Hat Developer Hub on OpenShift Container Platform with the Operator
   • Installing Developer Hub on EKS with the Operator
   • Installing Developer Hub on AKS with the Operator
   • Installing Developer Hub on Google Cloud with the Operator
   • Deploying Developer Hub on GKE with the Operator

Procedure

1. Create an ImageSetConfiguration file to specify the resources that you want to mirror. For example:

   apiVersion: mirror.openshift.io/v2alpha1
   kind: ImageSetConfiguration
   mirror:
     helm:
       repositories:
         - name: openshift-charts
           url: https://charts.openshift.io
           charts:
             - name: redhat-developer-hub
               version: "1.10"

   where:

   version: "1.10"

   Enter the Red Hat Developer Hub version to mirror.

2. Mirror the resources specified in the ImageSetConfiguration.yaml file by running the oc mirror command. For example:

   $ oc mirror --v2 -c <mirror_config_directory>/ImageSetConfiguration.yaml file://<mirror_archive_directory>/

   where:

   <mirror_config_directory>

   Enter the location of your image set configuration file on your system, for example, .user.

   <mirror_archive_directory>

   Enter the location of your directory where the system creates the mirror archive, for example, file://.user.

   Note

   1. The --v2 flag is required for OpenShift Container Platform 4.21 and later.
   2. Running the oc mirror command generates a local workspace containing the mirror archive file, the Helm chart, ImageDigestMirrorSet (IDMS) and ImageTagMirrorSet (ITMS) manifests. The IDMS and ITMS manifests contain files that you must apply against the cluster in a later step.

   Example output:

   Creating archive /path/to/mirror-archive/mirror_seq1_000000.tar

3. Transfer the generated archive file (for example, mirror_seq1_000000.tar) to the air-gapped environment.
4. Connect to your air-gapped environment and make sure that you are also connected to the following objects:
5. The local target registry
6. The target OpenShift Container Platform cluster

7. From your air-gapped environment, mirror the resources from the archive to the target registry by running the oc mirror command. For example:

   $ oc mirror --v2 -c <image_set_config> --from file://<mirror_archive_directory> docker://<target_registry>

   where:

   <mirror_archive_file>

   Enter the name of the file containing the resources that you want to mirror, for example,mirror_seq1_0000.tar.

   <target_registry>

   Enter the name of the target registry that you want to push the mirrored images to, for example, docker://registry.localhost:5000.

8. In your workspace, locate the IDMS and ITMS files by running the following command. For example:

   $ ls <workspace_directory>/working-dir/cluster-resources/

   where:

   <workspace_directory>

   Specifies the name of your workspace directory, for example, oc-mirror-workspace.

   <results_directory>

   Specifies the name of your results directory, for example, results-1738070846.

9. To mirror the Helm chart, deploy the IDMS and ITMS files in the disconnected cluster by running the oc apply command. For example:

   $ oc apply -f <workspace_directory>/working-dir/cluster-resources

   where:

   <workspace_directory>

   Enter the name of your workspace directory, for example, oc-mirror-workspace.

   <results_directory>

   Enter the name of your results directory, for example, results-1738070846.

10. Update the cluster pull secret to allow the kubelet to pull all Red Hat Developer Hub images from your mirror registry:

    $ oc get secret pull-secret -n openshift-config -o json | \
      jq -r '.data.".dockerconfigjson"' | base64 -d | \
      jq --arg registry "<mirror_registry>" \
         --arg auth "$(echo -n '<username>:<password>' | base64)" \
         '.auths[$registry] = {"auth": $auth}' | \
      oc set data secret/pull-secret -n openshift-config --from-file=.dockerconfigjson=/dev/stdin

    where:

    <mirror_registry>

    Enter the hostname and port of your mirror registry, for example, registry.example.com:5000.

    <username>:<password>

    Enter the credentials for authenticating to your mirror registry.

    Note

    Wait for all machine config pools to finish updating before proceeding.

11. In your air-gapped environment, deploy the Helm chart to the namespace that you want to use by running the helm install command with namespace and set options. For example:

    CLUSTER_ROUTER_BASE=$(oc get route console -n openshift-console -o=jsonpath='{.spec.host}' | sed 's/[.]*\.//') helm install <rhdh_instance> <workspace_directory>/working-dir/helm/charts/<archive_file> --namespace <your_namespace> --create-namespace \ --set global.clusterRouterBase="$CLUSTER_ROUTER_BASE"

    where:

    <rhdh_instance>

    Enter the name of your Red Hat Developer Hub instance, for example, my-rhdh-project.

    <workspace_directory>

    Enter the name of your workspace directory, for example, oc-mirror-workspace.

    <results_directory>

    Enter the name of your results directory, for example, results-1738070846.

    <archive_file>

    Enter the name of the archive file containing the resources that you want to mirror, for example, redhat-developer-hub-1.4.1.tgz.

    <your_namespace>

    Enter the namespace that you want to deploy the Helm chart to, for example, my-rhdh-project.

1. Download the plugin mirroring script by running the following command:

   $ curl -sSLO https://raw.githubusercontent.com/redhat-developer/rhdh-operator/refs/heads/release-1.10/.rhdh/scripts/mirror-plugins.sh

2. Export the plugin catalog index and all referenced plugin OCI artifacts to disk by running the following command:

   $ bash mirror-plugins.sh \
     --plugin-index oci://registry.access.redhat.com/rhdh/plugin-catalog-index:1.10 \
     --to-dir <my_plugin_mirror_dir>

   where:

   <my_plugin_mirror_dir>

   Enter the absolute path to a directory where you want to export the plugin artifacts, for example, /home/user/rhdh-plugins-mirror.

   Note

   The script can take several minutes to complete. It mirrors the catalog index image and all plugin OCI artifacts that the index references.

3. Transfer the directory specified by the --to-dir option to your disconnected environment.

4. From a machine in your disconnected environment that has access to the target mirror registry, import the plugin artifacts by running the following command:

   $ bash mirror-plugins.sh \
     --from-dir <my_plugin_mirror_dir> \
     --to-registry <target_registry>

   where:

   <my_plugin_mirror_dir>

   Enter the path to the directory containing the exported plugin artifacts.

   <target_registry>

   Enter the URL of the target mirror registry, for example, registry.example.com.

1. Create a config map containing a registries.conf file that redirects the install-dynamic-plugins init container to your mirror registry:

   apiVersion: v1
   kind: ConfigMap
   metadata:
     name: rhdh-plugin-mirror-conf
   data:
     rhdh-registries.conf: |
       [[registry]]
       prefix = "registry.access.redhat.com/rhdh"
       location = "<target_registry>/rhdh"
   
       [[registry]]
       prefix = "quay.io/rhdh"
       location = "<target_registry>/rhdh"

   where:

   <target_registry>

   Enter the URL of your mirror registry, for example, registry.example.com.

2. Mount the config map in the install-dynamic-plugins init container by adding the following to your Helm values file:

   upstream:
     backstage:
       extraVolumes:
         - name: rhdh-plugin-mirror-conf
           configMap:
             name: rhdh-plugin-mirror-conf
       initContainers:
         - name: install-dynamic-plugins
           volumeMounts:
             - name: rhdh-plugin-mirror-conf
               mountPath: /etc/containers/registries.conf.d/rhdh-registries.conf
               subPath: rhdh-registries.conf
               readOnly: true

   Important

   Because of Helm merge limitations, you must include all existing default volumes, volume mounts, and init container fields from the Red Hat Developer Hub Helm chart alongside your additions. Omitting the defaults overwrites them and can break the deployment.

   Note

   Cluster-level mirroring resources, such as ImageDigestMirrorSet or ImageContentSourcePolicy, do not apply to the install-dynamic-plugins init container because it uses skopeo directly to pull plugin artifacts.

3. Optional: To enforce signature verification in production environments, create a policy.json config map and mount it in the install-dynamic-plugins init container:

   apiVersion: v1
   kind: ConfigMap
   metadata:
     name: rhdh-mirror-policy
   data:
     policy.json: |
       {
         "transports": {
           "docker": {
             "<target_registry>/<namespace>": [
               {
                 "type": "signedBy",
                 "keyType": "GPGKeys",
                 "keyPath": "<path_to_gpg_key>"
               }
             ]
           }
         }
       }

   Then add the following volumes and volume mount entries to your Helm values file:

   upstream:
     backstage:
       extraVolumes:
         - name: rhdh-mirror-policy
           configMap:
             name: rhdh-mirror-policy
       initContainers:
         - name: install-dynamic-plugins
           volumeMounts:
             - name: rhdh-mirror-policy
               mountPath: /etc/containers/policy.json
               subPath: policy.json
               readOnly: true