Red Hat Developer Hub 1.9

Interacting with Red Hat Developer Lightspeed for Red Hat Developer Hub

Leverage Artificial Intelligence (AI)-driven expertise of the Red Hat Developer Lightspeed for Red Hat Developer Hub (Developer Lightspeed for RHDH) virtual assistant to help you use Red Hat Developer Hub (RHDH)

Red Hat Customer Content Services

Abstract

Leverage Artificial Intelligence (AI)-driven expertise of the Red Hat Developer Lightspeed for Red Hat Developer Hub (Developer Lightspeed for RHDH) virtual assistant to help you use Red Hat Developer Hub (RHDH)

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

Red Hat Developer Lightspeed for Red Hat Developer Hub (Developer Lightspeed for RHDH) is a virtual assistant powered by generative Artificial Intelligence (AI) designed for Red Hat Developer Hub(RHDH). The assistant offers in-depth insights into RHDH, including its wide range of capabilities. You can interact with this assistant to explore and learn more about RHDH in greater detail.

1.1. About Developer Lightspeed for RHDH

Important

This section describes Developer Preview features in the Red Hat Developer Lightspeed for Red Hat Developer Hub plugin. Developer Preview features are not supported by Red Hat in any way and are not functionally complete or production-ready. Do not use Developer Preview features for production or business-critical workloads. Developer Preview features provide early access to functionality in advance of possible inclusion in a Red Hat product offering. Customers can use these features to test functionality and provide feedback during the development process. Developer Preview features might not have any documentation, are subject to change or removal at any time, and have received limited testing. Red Hat might provide ways to submit feedback on Developer Preview features without an associated SLA.

For more information about the support scope of Red Hat Developer Preview features, see Developer Preview Support Scope.

This early access program enables customers to share feedback on the user experience, features, capabilities, and any issues encountered. Your input helps ensure that Developer Lightspeed for RHDH better meets your needs when it is officially released and made generally available.

Developer Lightspeed for RHDH provides a natural language interface within the RHDH console, helping you easily find information about the product, understand its features, and get answers to your questions.

You can experience Developer Lightspeed for RHDH Developer Preview by installing the Developer Lightspeed for RHDH plugin within an existing RHDH instance. Alternatively, if you prefer to test it locally first, you can try Developer Lightspeed for RHDH using RHDH Local.

Important

Developer Lightspeed for RHDH uses a FAB instead of a sidebar navigation item. If your environment uses another global FAB, you must move the existing button or disable it to prevent interface elements from overlapping. In your dynamic plugin configuration file, make the following update:

- package: ./dynamic-plugins/dist/red-hat-developer-hub-backstage-plugin-bulk-import
  disabled: true
  pluginConfig:
    dynamicPlugins:
      frontend:
        red-hat-developer-hub.backstage-plugin-bulk-import:
          mountPoints:
            - mountPoint: global.floatingactionbutton/config
              importName: BulkImportPage # Example
              config:
                slot: 'bottom-left'
                icon: BulkImportIcon
                label: 'Bulk import'
                toolTip: 'Register multiple repositories in bulk'
                to: /bulk-import
          translationResources:
          - importName: bulkImportTranslations
            module: Alpha
            ref: bulkImportTranslationRef
          appIcons:
          - name: bulkImportIcon
            importName: BulkImportIcon
          dynamicRoutes:
          - path: /bulk-import
            importName: BulkImportPage
            menuItem:
              icon: bulkImportIcon
              text: Bulk import
              textKey: menuItem.bulkImport
homepage lightspeed fab

Additional resources

1.2. Supported architecture for Red Hat Developer Lightspeed for Red Hat Developer Hub

Developer Lightspeed for RHDH is available as a plugin on all platforms that host RHDH. It requires two sidecar containers: the Lightspeed Core Service (LCS) and the Llama Stack service.

The LCS container acts as the intermediary layer, which interfaces with and manages the Llama Stack service.

developer lightspeed architecture 1 8 0

1.2.1. About Lightspeed Core Service and Llama Stack

The Lightspeed Core Service and Llama Stack deploy together as sidecar containers to augment RHDH functionality.

The Llama Stack delivers the augmented functionality by integrating and managing core components, which include:

  • Large language model (LLM) inference providers
  • Model Context Protocol (MCP) or Retrieval Augmented Generation (RAG) tool runtime providers

    Important

    You must verify that your model supports tool calling before you enable Model Context Protocol (MCP) features. Using an incompatible model results in error messages.

  • Safety providers
  • Vector database settings

The Lightspeed Core Service serves as the Llama Stack service intermediary. It manages the operational configuration and key data, specifically:

  • User feedback collection
  • MCP server configuration
  • Conversation history

Llama Stack provides the inference functionality that LCS uses to process requests. For more information, see What is Llama Stack.

The Red Hat Developer Lightspeed for Red Hat Developer Hub plugin in RHDH sends prompts and receives LLM responses through the LCS sidecar. LCS then uses the Llama Stack sidecar service to perform inference and MCP or RAG tool calling.

Note

Red Hat Developer Lightspeed for Red Hat Developer Hub is a Developer Preview release. You must manually deploy the Lightspeed Core Service and Llama Stack sidecar containers, and install the Red Hat Developer Lightspeed for Red Hat Developer Hub plugin on your RHDH instance.

1.3. Retrieval augmented generation (RAG) embeddings

The Red Hat Developer Hub documentation serves as the Retrieval-Augmented Generation (RAG) data source.

RAG initialization occurs through an initialization container, which copies the RAG data to a shared volume. The Llama Stack sidecar then mounts this shared volume to access the RAG data. The Llama Stack service uses the resulting RAG embeddings in the vector database as a reference. This allows the service to provide citations to production documentation during the inference process.

1.4. Installing and configuring Red Hat Developer Lightspeed for Red Hat Developer Hub

Developer Lightspeed for RHDH includes several components that work together to provide virtual assistant (chat) functionality:

Llama stack server (container sidecar)
Based on open source Llama Stack, this service is the gateway to your LLM inferencing provider for chat services. Its modular architecture supports integrating other services, such as Model Context Protocol (MCP). To enable chat functionality, you must integrate your LLM provider with the Llama Stack server using Bring Your Own Model or BYOM.
Lightspeed Core Service (LCS) (container sidecar)
Based on the open source Lightspeed Core, this service extends the Llama Stack server by maintaining chat history and gathering user feedback.
Red Hat Developer Lightspeed for Red Hat Developer Hub (dynamic plugins)
These plugins enable the Developer Lightspeed for RHDH user interface within your RHDH instance.

To provide Developer Lightspeed for RHDH to your users, you must configure these components to communicate with each other.

Note
  • If you are upgrading from the previous Developer Lightspeed for RHDH Developer Preview with Road-Core Service, you must remove all existing Developer Lightspeed for RHDH configurations before reinstalling.
  • To prevent or resolve upgrade inconsistencies, drop and recreate the dynamic plugins volume.

This reinstallation is required due to the following fundamental architectural changes:

  • The previous release used Road-Core Service as a sidecar container for interfacing with LLM providers.
  • The updated architecture replaces {rcs-short} with the new Lightspeed Core Service and Llama Stack server, which requires new configurations for the plugins, volumes, containers, and secrets.

Prerequisites

  • You are logged in to your OpenShift Container Platform account.
  • You have an RHDH instance installed using either the Operator or the Helm chart.
  • You have created a custom dynamic plugins ConfigMap.
  • You have administrative access to the RHDH configuration files.

Procedure

You must manually install and configure the Developer Lightspeed for RHDH plugin, the Lightspeed Core Service (LCS) sidecar container, and the Llama Stack sidecar container.

  1. Create the Lightspeed Core Service (LCS) ConfigMap to store the service configuration:

    1. In the OpenShift Container Platform web console, navigate to your RHDH instance and select the ConfigMaps tab.
    2. Click Create ConfigMaps.
    3. Select YAML view and edit the file using the following structure. This example demonstrates the configuration for the LCS ConfigMap, typically named lightspeed-stack, which connects to the Llama Stack service locally on port 8321:

      kind: ConfigMap
      apiVersion: v1
      metadata:
        name: lightspeed-stack
      data:
        lightspeed-stack.yaml: |
          name: Lightspeed Core Service (LCS)
          service:
            host: 0.0.0.0
          # Use ${LIGHTSPEED_SERVICE_PORT} if you are not running the Service on port `8080`
          # port: ${LIGHTSPEED_SERVICE_PORT}
            auth_enabled: false
            workers: 1
            color_log: true
            access_log: true
          llama_stack:
            use_as_library_client: false
            url: http://localhost:8321
          user_data_collection:
            feedback_enabled: true
            feedback_storage: "/tmp/data/feedback"
            transcripts_enabled: true
            transcripts_storage: "/tmp/data/transcripts"
          authentication:
            module: "noop"
          conversation_cache:
            type: "sqlite"
            sqlite:
              db_path: "/tmp/data/conversations/lcs_cache.db"
      Important

      LCS uses Llama Stack expansion syntax for environment variables. To make sure the service correctly parses variables in the lightspeed-stack.yaml file, you must use the ${env.VAR} format. Variable names are case-sensitive and must be uppercase. The syntax ${env.var} is not supported. For example:

      model_config:
        api_key: ${env.VAR}
    4. Click Create.
  2. Create the Developer Lightspeed for RHDH ConfigMap (lightspeed-app-config) for plugin configurations:

    1. In the OpenShift Container Platform web console, navigate to your RHDH instance and select the ConfigMaps tab.
    2. Click Create ConfigMap.
    3. Select the YAML view option and add the following configuration:

      kind: ConfigMap
      apiVersion: v1
      metadata:
        name: lightspeed-app-config
        namespace: <__namespace__> # Enter your RHDH instance namespace
      data:
        app-config.yaml: |-
          backend:
            csp:
              upgrade-insecure-requests: false
            img-src:
              - "'self'"
              - "data:"
              - https://img.freepik.com
              - https://cdn.dribbble.com
              - https://avatars.githubusercontent.com # This is to load GitHub avatars in the UI
            script-src:
              - "'self'"
              - "'unsafe-eval'"
              - https://cdn.jsdelivr.net
      
          lightspeed:
            # OPTIONAL: Custom users prompts displayed to users
            # If not provided, the plugin uses built-in default prompts
            prompts:
              - title: Getting Started with Red Hat Developer Hub
                message: Can you guide me through the first steps to start using {product-short} as a developer, like exploring the Software Catalog and adding my service?
      
            # OPTIONAL: Port for lightspeed service (default: 8080)
            # servicePort: ${LIGHTSPEED_SERVICE_PORT}
      
            # OPTIONAL: Override default RHDH system prompt
            # systemPrompt: "You are a helpful assistant focused on Red Hat Developer Hub development."
    4. Click Create.
  3. Create Llama Stack Secret file (llama-stack-secrets) for LLM provider credentials:

    Important

    Red Hat Developer Hub 1.9 configures the Llama Stack image to use the vLLM provider exclusively. The vLLM provider supports the OpenAI API schema but does not support connecting directly to the official OpenAI service (api.openai.com). Do not use the official OpenAI API URL or token with vLLM in this release. Attempting this might result in errors or improper responses. Native OpenAI provider support is planned for future releases.

    1. In the OpenShift Container Platform web console, navigate to Secrets.
    2. Click CreateKey/value secret.
    3. Select the YAML view option and add the following structure:

      apiVersion: v1
      kind: Secret
      metadata:
        name: llama-stack-secrets
      type: Opaque
      stringData:
        ENABLE_VLLM: "true"
        ENABLE_VERTEX_AI: ""
        ENABLE_OPENAI: ""
        ENABLE_OLLAMA: ""
        VLLM_URL: "_<api_endpoint>_"
        VLLM_API_KEY: "_<api_key>_"
        VLLM_MAX_TOKENS: ""
        VLLM_TLS_VERIFY: ""
        OPENAI_API_KEY: ""
        VERTEX_AI_PROJECT: ""
        VERTEX_AI_LOCATION: ""
        GOOGLE_APPLICATION_CREDENTIALS: ""
        OLLAMA_URL: ""
        SAFETY_MODEL: "llama-guard3:8b"
        SAFETY_URL: "http://localhost:#####/v1"
        SAFETY_API_KEY: ""

      where:

      ENABLE_VLLM
      Enables the vLLM provider. Set to true to activate.
      ENABLE_OPENAI
      Enables the OpenAI provider. Set to true to activate.
      ENABLE_VERTEX_AI
      Enables the Vertex AI provider. Set to true to activate.
      ENABLE_OLLAMA
      Enables the Ollama provider. Set to true to activate.

To disable a provider, leave the value blank. (for example: ENABLE_VLLM="")

VLLM_URL
The API endpoint URL for the LLM provider. The provider must comply with the OpenAI API specification. Examples include OpenAI, Red Hat OpenShift AI, and vLLM.
VLLM_API_KEY
Required for remote services: Set this to the API key or token required for authentication with your remote LLM provider, if it is compatible with the OpenAI API specification.
VLLM_MAX_TOKENS
Optional. The maximum number of tokens the model generates.
VLLM_TLS_VERIFY
Optional. Specifies whether the system verifies the TLS certificate for the vLLM endpoint.
OPENAI_API_KEY
The API key required to access OpenAI models through the OpenAI API.
VERTEX_AI_PROJECT
The Google Cloud project ID required to access Gemini through Vertex AI.
VERTEX_AI_LOCATION
The Google Cloud region required to access Gemini through Vertex AI.
GOOGLE_APPLICATION_CREDENTIALS
The credentials required to authenticate with Google Cloud to access Vertex AI.
OLLAMA_URL
The URL for the Ollama service.
SAFETY_MODEL
The identifier for the safety model. The recommended value is llama-guard3:8b.
SAFETY_URL
The URL hosting the safety model. You must append /v1 to the host address (for example: localhost:#/v1).
SAFETY_API_KEY

The API key required to authenticate with the safety model, if applicable.

  1. Click Create.

    1. Update the dynamic plugins ConfigMap: Add the Developer Lightspeed for RHDH plugin image to your existing dynamic plugins ConfigMap (dynamic-plugins-rhdh).

      includes:
      - dynamic-plugins.default.yaml
      plugins:
      - disabled: false
        package: oci://ghcr.io/redhat-developer/rhdh-plugin-export-overlays/red-hat-developer-hub-backstage-plugin-lightspeed:bs_1.45.3__1.2.3
        pluginConfig:
          dynamicPlugins:
            frontend:
              red-hat-developer-hub.backstage-plugin-lightspeed:
                    translationResources:
                      - importName: lightspeedTranslations
                        module: Alpha
                        ref: lightspeedTranslationRef
                    dynamicRoutes:
                      - path: /lightspeed
                        importName: LightspeedPage
                    mountPoints:
                      - mountPoint: application/listener
                        importName: LightspeedFAB
                      - mountPoint: application/provider
                        importName: LightspeedDrawerProvider
                      - mountPoint: application/internal/drawer-state
                        importName: LightspeedDrawerStateExposer
                        config:
                          id: lightspeed
                      - mountPoint: application/internal/drawer-content
                        importName: LightspeedChatContainer
                        config:
                          id: lightspeed
                          priority: 100
      - disabled: false
        package: oci://ghcr.io/redhat-developer/rhdh-plugin-export-overlays/red-hat-developer-hub-backstage-plugin-lightspeed-backend:bs_1.45.3__1.2.3
    2. Required only if your environment uses another global floating action button (FAB): You must move the existing FAB or disable it to prevent interface elements from overlapping by updating your dynamic plugin configuration file with the following changes:

      - package: ./dynamic-plugins/dist/red-hat-developer-hub-backstage-plugin-bulk-import
        disabled: true
        pluginConfig:
          dynamicPlugins:
            frontend:
              red-hat-developer-hub.backstage-plugin-bulk-import:
                mountPoints:
                # START: If the user has an existing BulkImportPage FAB, move the FAB to the left
                  - mountPoint: global.floatingactionbutton/config
                    importName: BulkImportPage
                    config:
                      slot: 'bottom-left'
                # END
                      icon: BulkImportIcon
                      label: 'Bulk import'
                      toolTip: 'Register multiple repositories in bulk'
                      to: /bulk-import
                translationResources:
                - importName: bulkImportTranslations
                  module: Alpha
                  ref: bulkImportTranslationRef
                appIcons:
                - name: bulkImportIcon
                  importName: BulkImportIcon
                dynamicRoutes:
                - path: /bulk-import
                  importName: BulkImportPage
                  menuItem:
                    icon: bulkImportIcon
                    text: Bulk import
                    textKey: menuItem.bulkImport
    3. Update your deployment configuration: Update the deployment configuration based on how your RHDH instance was installed. You must add two sidecar containers: llama-stack and lightspeed-core.

      • For an Operator-installed RHDH instance (Update Backstage custom resource (CR)):

        1. In the spec.application.appConfig.configMaps section of your Backstage CR, add the Developer Lightspeed for RHDH custom app configuration:

          appConfig:
            configMaps:
              - name: lightspeed-app-config
        2. Update the spec.deployment.patch.spec.template.spec.volumes specification to include volumes for LCS configuration (lightspeed-stack), shared storage for feedback (shared-storage), and RAG data (rag-data-volume):

          volumes:
            - configMap:
                name: lightspeed-stack
              name: lightspeed-stack
            - emptyDir: {}
              name: shared-storage
            - emptyDir: {}
              name: rag-data-volume
        3. Add the initContainers section to initialize RAG data:
+
----
initContainers:
  - name: init-rag-data
    image: 'quay.io/redhat-ai-dev/rag-content:release-1.9-lcs'
    command:
      - "sh"
      - "-c"
      - "echo 'Copying RAG data...'; cp -r /rag/vector_db/rhdh_product_docs /rag-content/ && cp -r /rag/embeddings_model /rag-content/ && echo 'Copy complete.'"
    volumeMounts:
      - mountPath: /rag-content
        name: rag-data-volume
----
... Add the Llama Stack and the {lcs-short} containers to the `spec.deployment.patch.spec.template.spec.containers` section:

+

containers:
  # ... Your existing RHDH container definition ...
  - envFrom:
      - secretRef:
          name: llama-stack-secrets
    image: 'quay.io/redhat-ai-dev/llama-stack:0.1.4' # Llama Stack image
    name: llama-stack
    volumeMounts:
      - mountPath: /app-root/.llama
        name: shared-storage
      - mountPath: /rag-content
        name: rag-data-volume
  - image: 'quay.io/lightspeed-core/lightspeed-stack:0.4.0' # Lightspeed Core Service image
    name: lightspeed-core
    volumeMounts:
      - mountPath: /app-root/lightspeed-stack.yaml
        name: lightspeed-stack
        subPath: lightspeed-stack.yaml
      - mountPath: /tmp/data/feedback
        name: shared-storage
      - mountPath: /tmp/data/transcripts
        name: shared-storage
      - mountPath: /tmp/data/conversations
        name: shared-storage
  1. Click Save. The Pods are automatically restarted.

    • For a Helm-installed RHDH instance (Update the Helm chart):
  2. Add your dynamic plugins configuration in the global.dynamic property.

    global:
      dynamic:
        plugins:
          - package: oci://ghcr.io/redhat-developer/rhdh-plugin-export-overlays/red-hat-developer-hub-backstage-plugin-lightspeed:bs_1.45.3__1.2.3
            pluginConfig:
              dynamicPlugins:
                frontend:
                  red-hat-developer-hub.backstage-plugin-lightspeed:
                    translationResources:
                      - importName: lightspeedTranslations
                        module: Alpha
                        ref: lightspeedTranslationRef
                    dynamicRoutes:
                      - path: /lightspeed
                        importName: LightspeedPage
                    mountPoints:
                      - mountPoint: application/listener
                        importName: LightspeedFAB
                      - mountPoint: application/provider
                        importName: LightspeedDrawerProvider
                      - mountPoint: application/internal/drawer-state
                        importName: LightspeedDrawerStateExposer
                        config:
                          id: lightspeed
                      - mountPoint: application/internal/drawer-content
                        importName: LightspeedChatContainer
                        config:
                          id: lightspeed
                          priority: 100
          - package: oci://ghcr.io/redhat-developer/rhdh-plugin-export-overlays/red-hat-developer-hub-backstage-plugin-lightspeed-backend:bs_1.45.3__1.2.3
  3. Add your Developer Lightspeed for RHDH custom app config file to extraAppConfig:

        extraAppConfig:
          - configMapRef: lightspeed-app-config
            filename: app-config.yaml
  4. Add the Llama Stack Secret file to extraEnvVarsSecrets:

        extraEnvVarsSecrets:
          - llama-stack-secrets
  5. Update the extraVolumes section to include the LCS ConfigMap (lightspeed-stack), shared storage, and RAG data volume:

        extraVolumes:
          - configMap:
              name: lightspeed-stack
            name: lightspeed-stack
          - emptyDir: {}
            name: shared-storage
          - emptyDir: {}
            name: rag-data-volume
  6. Update the initContainers section (if supported by your Helm chart structure) to initialize RAG data.

      initContainers:
          - name: init-rag-data
            image: 'quay.io/redhat-ai-dev/rag-content:release-1.9-lcs'
            command:
              - "sh"
              - "-c"
              - "echo 'Copying RAG data...'; cp -r /rag/vector_db/rhdh_product_docs /data/ && cp -r /rag/embeddings_model /data/ && echo 'Copy complete.'"
            volumeMounts:
              - mountPath: /data
                name: rag-data-volume
  7. Add the Llama Stack and LCS container definitions to extraContainers.

    Note

    If you have Road-Core Service installed from the previous Red Hat Developer Lightspeed for Red Hat Developer Hub configuration, you must replace the older single container configuration found in source with the two sidecars.

        extraContainers:
          # Llama Stack Container
          - envFrom:
              - secretRef:
                  name: llama-stack-secrets
            image: 'quay.io/redhat-ai-dev/llama-stack:0.1.4'
            name: llama-stack
            volumeMounts:
              - mountPath: /app-root/.llama
                name: shared-storage
              - mountPath: /rag-content/embeddings_model
                name: rag-data-volume
                subPath: embeddings_model
              - mountPath: /rag-content/vector_db/rhdh_product_docs
                name: rag-data-volume
                subPath: rhdh_product_docs
          # Lightspeed Core Service Container
          - image: 'quay.io/lightspeed-core/lightspeed-stack:0.4.0'
            name: lightspeed-core
            volumeMounts:
              - mountPath: /app-root/lightspeed-stack.yaml
                name: lightspeed-stack
                subPath: lightspeed-stack.yaml
              - mountPath: /tmp/data/feedback
                name: shared-storage
              - mountPath: /tmp/data/transcripts
                name: shared-storage
              - mountPath: /tmp/data/conversations
                name: shared-storage
  8. Click Save and then Helm upgrade.

    1. Optional: Manage authorization (RBAC): If you have users who are not administrators, you must define permissions and roles for them to use Developer Lightspeed for RHDH. The Lightspeed Backend plugin uses Backstage RBAC for authorization.

      • For an Operator-installed RHDH instance:
  9. Configure the required RBAC permission by defining an rbac-policies.csv file, including lightspeed.chat.read, lightspeed.chat.create, and lightspeed.chat.delete permissions:

    p, role:default/_<your_team>_, lightspeed.chat.read, read, allow
    p, role:default/_<your_team>_, lightspeed.chat.create, create, allow
    p, role:default/_<your_team>_, lightspeed.chat.delete, delete, allow
    g, user:default/_<your_user>_, role:default/_<your_team>_
  10. Upload your rbac-policies.csv file to an rbac-policies ConfigMap in your OpenShift Container Platform project containing RHDH and update your Backstage CR:

    apiVersion: rhdh.redhat.com/v1alpha5
    kind: Backstage
    spec:
      application:
        extraFiles:
          mountPath: /opt/app-root/src
          configMaps:
            - name: rbac-policies
    • For a Helm-installed RHDH instance:
  11. Configure the required RBAC permission by defining an rbac-policies.csv file:

    p, role:default/_<your_team>_, lightspeed.chat.read, read, allow
    p, role:default/_<your_team>_, lightspeed.chat.create, create, allow
    p, role:default/_<your_team>_, lightspeed.chat.delete, delete, allow
    g, user:default/_<your_user>_, role:default/_<your_team>_
  12. Optional: Declare policy administrators by editing your custom RHDH ConfigMap (app-config.yaml) and adding the following code to enable selected authenticated users to configure RBAC policies through the REST API or Web UI:

      permission:
        enabled: true
        rbac:
          policies-csv-file: /opt/app-root/src/rbac-policies.csv
          policyFileReload: true
        admin:
          users:
            - name: user:default/<your_policy_administrator_name>

Verification

  1. Log in to your RHDH instance.
  2. Verify that you can see and access the Lightspeed FAB in the home page.
  3. Select the Lightspeed FAB and verify the chat screen loads.

1.5. Customizing Developer Lightspeed for RHDH

You can customize Developer Lightspeed for RHDH functionalities such as gathering feedback, storing chat history in PostgreSQL, and configuring Model Context Protocol (MCP) tools.

1.5.1. Gathering feedback in Developer Lightspeed for RHDH

Feedback collection is an optional feature configured on the LCS. This feature gathers user feedback by providing thumbs-up/down ratings and text comments directly from the chat window.

LCS collects the feedback, the user’s query, and the response of the model, storing the data as a JSON file on the local file system of the Pod. A platform administrator must later collect and analyze this data to assess model performance and improve the user experience.

The collected data resides in the cluster where RHDH and LCS are deployed, making it accessible only to platform administrators for that cluster. For data removal, users must request this action from their platform administrator, as Red Hat neither collects nor accesses this data.

Procedure

  • To enable feedback collection, in the LCS configuration file (lightspeed-stack.yaml), add the following settings:

      user_data_collection:
        feedback_enabled: true
        feedback_storage: "/tmp/data/feedback"
        transcripts_enabled: true
        transcripts_storage: "/tmp/data/transcripts"
  • To disable feedback collection, in the LCS configuration file (lightspeed-stack.yaml), add the following settings:

      user_data_collection:
        feedback_enabled: false
        feedback_storage: "/tmp/data/feedback"
        transcripts_enabled: true
        transcripts_storage: "/tmp/data/transcripts"

1.5.2. Updating the system prompt in Developer Lightspeed for RHDH

You can override the default system prompt that Developer Lightspeed for RHDH uses to better frame queries to your LLM. Customizing the system prompt allows you to refine the context, personality, and instructions that the LLM receives, improving the relevance and accuracy of the responses it creates for your specific environment.

Procedure

  • To set a custom system prompt, in your Developer Lightspeed for RHDH app config file, add or modify the lightspeed.systemPrompt key and set its value to your preferred prompt string as shown in the following example:

    lightspeed:
      # ... other lightspeed configurations
      systemPrompt: "You are a helpful assistant focused on Red Hat Developer Hub development."

Set systemPrompt to prefix all queries sent by Developer Lightspeed for RHDH to the LLM with this instruction, guiding the model to generate more tailored responses.

1.5.3. Customizing the chat history storage in Developer Lightspeed for RHDH

By default, the Developer Lightspeed for RHDH service stores chat history in a non-persistent local SQL database within the LCS container. This means that chat history is lost if you create and use a new LCS sidecar. You can manually configure Developer Lightspeed for RHDH to store the chat history persistently as a long-term backup with PostgreSQL by updating your LCS service configuration.

Warning

Configuring Developer Lightspeed for RHDH to use PostgreSQL records prompts and responses, which platform administrators can review. You must assess any data privacy and security implications if user chat history contains private, sensitive, or confidential information. For users that wish to have their chat data removed, they must request their respective platform administrator to perform this action. Red Hat does not collect or access this chat history data.

Procedure

  1. Configure the chat history storage type in the LCS configuration file (lightspeed-stack.yaml) using any of the relevant options:

    • To enable persistent storage with PostgreSQL, add the following configuration:

       conversation_cache:
          type: postgres
          postgres:
            host: _<your_database_host>_
            port: _<your_database_port>_
            db: _<your_database_name>_
            user: _<your_user_name>_
            password: _<postgres_password>_
      • To retain the default, non-persistent SQLite storage, make sure the configuration is set as shown in the following example:

        conversation_cache:
          type: "sqlite"
          sqlite:
            db_path: "/tmp/data/conversations/lcs_cache.db"
  2. Restart your LCS service to apply the new configuration.

1.6. Get AI-assisted help for your development tasks

To assist with development tasks, platform questions, and debugging, use Red Hat Developer Lightspeed for Red Hat Developer Hub, a generative AI virtual assistant integrated directly into Red Hat Developer Hub (RHDH). You can use the conversational interface to ask platform-specific questions, analyze logs, generate code, and create test plans, which reduces the time spent searching through official documentation or disparate tools.

1.6.1. Configure safety guards in Red Hat Developer Hub

To protect users from insecure or harmful AI model outputs, Red Hat Developer Hub (RHDH) uses Llama Guard as a default safety shield. You must configure these guards to align with your organization’s security policies.

Default safety guard configuration
The system uses Llama Guard as the default safety shield. Override these settings in the run.yaml file.
Note

The external_providers_dir parameter defaults to null and is no longer required in your configuration.

Overriding safety guards
To implement custom security layers or different safety shields, you must define a new safety provider within a custom run.yaml file.
Disabling safety guards
To run RHDH without safety guards, you must use the run-no-guard.yaml configuration file.
Important

Running without safety guards increases the risk of unvalidated model output. Only use this configuration in secure development environments.

Applying the no-guard configuration
To run the system without a safety guard, perform these steps:

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.

Prerequisites

  • Your platform engineer has installed and configured the Developer Lightspeed for RHDH plugin in your RHDH instance.

1.6.2. Get the best results for assistant queries

To resolve technical blockers and accelerate development tasks, you must structure your queries to provide specific context to the AI assistant. Using precise prompts ensures that Developer Lightspeed for RHDH generates relevant code snippets, architectural advice, or platform-specific instructions.

Use the following strategies to improve the accuracy of the assistant’s output during your development workflow:

Specify technologies
Instead of asking "How do I use templates?", ask "How do I create a Software Template that scaffolds a Node.js service with a CI/CD pipeline".
Provide context
Include details about your environment, such as "I am deploying to OpenShift; how do I configure my catalog-info.yaml to show pod health?".
Leverage conversation context
Ask follow-up questions to refine a previous answer. For example, if the assistant provides a code snippet, you can ask "Now rewrite that using TypeScript interfaces."
Validate with citations
Examine the provided documentation links and citations in the response to verify that the generated advice aligns with your organization’s official standards.
Improve assistant accuracy
Rate the utility of responses by selecting the Thumbs up or Thumbs down icons. This feedback helps tune the model for your organization’s specific requirements.
Important

To maintain security standards, do not include sensitive personal information, plain-text credentials, or confidential business data in your queries.

1.6.3. Monitor AI responses and context management

Developer Lightspeed for RHDH provides features to track the AI reasoning process and maintain the context of your development tasks.

Thinking cards
An expandable thinking card appears while the AI processes a query. A pulse animation indicates the reasoning phase. You can expand the card to view detailed reasoning or collapse it to minimize screen clutter.
Tool call transparency
An expandable card displays details for Model Context Protocol (MCP) tool calls, which allows you to monitor background processes.
Context-aware citations
Retrieval-Augmented Generation (RAG) citations appear only when the AI uses internal documentation. This makes sure that general knowledge responses remain concise.
Context preservation during model changes
When you select a different AI model, Developer Lightspeed for RHDH starts a new conversation. This makes sure that your previous chats remain available in your history.
Structural readability
The interface formats headings and bullet points automatically to make sure responses are scannable.

1.6.4. Managing chats

Manage your chat history in RHDH to organize your workspace, resume previous tasks, or find past solutions.

Prerequisites

  • You have configured the Developer Lightspeed for RHDH plugin in Red Hat Developer Hub.
  • You must be logged in to the portal.

Procedure

  1. Click the Lightspeed floating action button (FAB) at the bottom right of the screen to open the chat overlay.
  2. Optional: Configure the interface display:

    • Click the Chatbot options icon (⋮) to view chat history or start a new chat.
    • Click the Display menu icon and select any of the following views:

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

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

      • Fullscreen: A dedicated page opens for intensive chat sessions. You can bookmark this URL for direct access.

      • Optional: Toggle Enable pinned chats/Disable pinned chats to enable or hide the pinned chats. This is enabled by default.
  3. Start a chat or load a previous 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, such as Deploy with Tekton.
    • Attach a file: Click Attach to upload a .yaml, .json, or .txt file.

      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.
    • 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.
    • 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.

    • Hide the chat history section and reduce visual noise: Select the Close icon (x) next to New chat.
    • Restore access to your pinned chat: Select the Chat history menu icon.
  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

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

1.7. Appendix: LLM requirements

1.7.1. Large language model (LLM) requirements

Developer Lightspeed for RHDH follows a Bring Your Own Model approach. This model means that to function, Developer Lightspeed for RHDH requires access to a large language model (LLM) which you must provide. An LLM is a type of generative AI that interprets natural language and generates human-like text or audio responses. When an LLM is used as a virtual assistant, the LLM can interpret questions and provide answers in a conversational manner.

LLMs are usually provided by a service or server. Because Developer Lightspeed for RHDH does not provide an LLM for you, you must configure your preferred LLM provider during installation. You can configure the underlying Llama Stack server to integrate with a number of LLM providers that offer compatibility with the OpenAI API including the following inference providers:

  • OpenAI (cloud-based inference service)
  • Red Hat OpenShift AI (enterprise model builder and inference server)
  • Red Hat Enterprise Linux AI (enterprise inference server)
  • Ollama (popular desktop inference server)
  • vLLM (popular enterprise inference server)
  • Gemini (available through Vertex AI)

1.7.2. OpenAI

OpenAI offers a range of generative AI models, such as GPT 5, which can be used to provide inference services for applications like Developer Lightspeed for RHDH.

To use OpenAI with Developer Lightspeed for RHDH, you need access to the OpenAI API platform. For more information, see the OpenAI developer platform documentation.

1.7.3. Ollama

Ollama is a powerful and easy-to-use open-source project that simplifies the process of running large language models (LLMs) locally on your computer. It provides a simple command-line interface for downloading, managing, and running a wide variety of open-source models, such as Llama 3, Mistral, and many others, all without requiring a dedicated server or cloud service. By abstracting away the complex setup and dependencies, Ollama makes it accessible for developers, researchers, and enthusiasts to experiment with, build on, and integrate state-of-the-art LLMs into their applications directly from their personal machines.

The open source Ollama server in container form provides a convenient local testbed for LLM models that is very accessible and easily controlled.

Additional resources

1.7.4. vLLM

vLLM is an open-source, high-throughput serving engine for large language models (LLMs) that significantly improves upon traditional serving systems. It achieves this by introducing several key optimizations to reduce memory usage and eliminate redundant computations. vLLM prominently increases the number of concurrent requests an LLM can handle, making it a powerful tool for deploying and scaling LLM-based applications.

1.8. Appendix About user data security

1.8.1. About data use

Developer Lightspeed for RHDH is a virtual assistant you interact with using natural language. Using the Developer Lightspeed for RHDH interface, you send chat messages that Developer Lightspeed for RHDH transforms and sends to the large language model (LLM) provider you have configured for your environment. These messages could potentially contain information provided by your users about themselves, your cluster, cluster resources, or other aspects of your business or working environment.

Developer Lightspeed for RHDH has limited capabilities to filter or redact the information you provide to the LLM. Do not enter information into Developer Lightspeed for RHDH that you do not want to send to the LLM provider. To remind end users not to share private or confidential information, Developer Lightspeed for RHDH begins each new chat with an 'Important' message asking them not to “include personal or sensitive information” in their chat messages.

1.8.2. About feedback collection

Developer Lightspeed for RHDH collects feedback from users who engage with the feedback feature in the virtual assistant interface. If a user submits feedback, the feedback score (thumbs up or down), text feedback (if entered), the user query, and the LLM provider response are stored locally in the file system of the Pod. Red Hat does not have access to the collected feedback data.

1.8.3. About Bring Your Own Model

Developer Lightspeed for RHDH does not provide its own inference services, but uses a Bring Your Own Model approach. This means that you can configure the Lightspeed Core Service to talk to the inference server or service of your choice. This also means that you are responsible for ensuring that the configured service meets your particular company policies and legal requirements, including any applicable terms with the third-party model provider. The only technical requirements for inference services are:

  • The service must conform to the OpenAI API specification.
  • The service must be configured correctly following the installation and configuration instructions. There are many commercial and open source inference services that support the OpenAI API specification for chat completions. The cost, performance, and security of these services can differ and it is up to you to choose, through evaluation and testing, the inference service that best meets your company’s needs.

Additional resources

1.8.4. Your responsibility

All of the information your users share in their questions and responses with Developer Lightspeed for RHDH are shared with the LLM inference service you configured. You are responsible for ensuring compliance with your company’s policies regarding the sharing of data with your chosen inference service.

Legal Notice

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