Red Hat Developer Hub 1.7

Installing Red Hat Developer Hub on Amazon Elastic Kubernetes Service (EKS)

Running Red Hat Developer Hub on Amazon Elastic Kubernetes Service (EKS) by using either the Operator or Helm chart

Red Hat Customer Content Services

Abstract

Red Hat Developer Hub (RHDH) is an enterprise-grade platform for building developer portals. Administrative users can configure roles, permissions, and other settings to enable other authorized users to deploy a RHDH instance on Amazon Elastic Kubernetes Service (EKS) using either the Operator or Helm chart.

Red Hat Developer Hub (RHDH) is an enterprise-grade platform for building developer portals. Administrative users can configure roles, permissions, and other settings to enable other authorized users to deploy a RHDH instance on Amazon Elastic Kubernetes Service (EKS) using either the Operator or Helm chart.

1. Installing Developer Hub on Amazon Elastic Kubernetes Service (EKS) by using the Operator

To benefit from over-the-air updates and catalogs provided by Operator-based applications distributed with the Operator Lifecycle Manager (OLM) framework, consider installing Red Hat Developer Hub by using the Red Hat Developer Hub Operator distributed in the Red Hat Ecosystem.

On EKS, the most notable differences over an OpenShift-based installation are:

  • The OLM framework and the Red Hat Ecosystem are not built-in.
  • The Red Hat Ecosystem pull-secret is not managed globally.
  • To expose the application, Ingresses replace OpenShift Routes.

For clarity, the content is broken down in sections highlighting these platform-specific additional steps.

1.1. Installing the Developer Hub Operator on Amazon Elastic Kubernetes Service (EKS) by using the OLM framework

The Red Hat Ecosystem, based on the Operator Lifecycle Manager (OLM) framework, contains a distribution of the Red Hat Developer Hub Operator, aimed at managing your Red Hat Developer Hub instance lifecycle.

However, on Amazon Elastic Kubernetes Service (EKS):

  • The Operator Lifecycle Manager (OLM) framework and the Red Hat Ecosystem are not built-in.
  • The Red Hat Ecosystem pull-secret is not managed globally.

Therefore, install the OLM framework, the Red Hat Ecosystem, and provision your Red Hat Ecosystem pull secret to install Developer Hub Operator.

Prerequisites

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 Ecosystem:

    $ 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 contains the Red Hat Ecosystem 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.18
      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.7.0
    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

Verification

  • Verify the deployment name:

    $ kubectl get deployment -n rhdh-operator

1.2. Provisioning your custom Red Hat Developer Hub configuration

To configure Red Hat Developer Hub, provision your custom Red Hat Developer Hub config maps and secrets to Amazon Elastic Kubernetes Service (EKS) before running Red Hat Developer Hub.

Tip

On Red Hat OpenShift Container Platform, you can skip this step to run Developer Hub with the default config map and secret. Your changes on this configuration might get reverted on Developer Hub restart.

Prerequisites

  • By using the Kubernetes CLI ('kubectl'), you have access, with developer permissions, to the Kubernetes cluster aimed at containing your Developer Hub instance.

Procedure

  1. Author your custom <my_product_secrets>.txt file to provision your secrets as environment variables values in a Kubernetes secret, rather than in clear text in your configuration files. It contains one secret per line in KEY=value form.

  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 EKS, 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:

      Example 1. 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:

  3. 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. Provision your app-config.yaml file to the my-rhdh-app-config config map in the <my-rhdh-project> project.

      $ oc create configmap my-rhdh-app-config --from-file=app-config.yaml --namespace=my-rhdh-project
    3. Provision your <my_product_secrets>.txt file to the <my_product_secrets> secret in the <my-rhdh-project> project.

      $ oc create secret generic <my_product_secrets> --from-file=<my_product_secrets>.txt --namespace=my-rhdh-project

Next steps

1.3. Provision your Red Hat Ecosystem pull secret to your Red Hat Developer Hub instance namespace

On Amazon Elastic Kubernetes Service (EKS), the Red Hat Ecosystem pull-secret is not managed globally. Therefore add your pull-secret in your Red Hat Developer Hub instance namespace.

Prerequisites

  • Your credentials to the Red Hat Container Registry:

    • <redhat_user_name>
    • <redhat_password>
    • <email>
  • You created the {my-rhdh-project} namespace on EKS to host your Developer Hub instance.

Procedure

  1. Create a pull secret using your Red Hat credentials to pull the container images from the protected Red Hat Ecosystem:

    $ 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 Ecosystem Catalog, 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}

1.4. Using the Red Hat Developer Hub Operator to run Developer Hub with your custom configuration

To use the Developer Hub Operator to run Red Hat Developer Hub with your custom configuration, create your Backstage custom resource (CR) that:

  • Mounts files provisioned in your custom config maps.
  • Injects environment variables provisioned in your custom secrets.

Prerequisites

  • By using the Kubernetes CLI ('kubectl'), you have access, with developer permissions, to the EKS cluster aimed at containing your Developer Hub instance.
  • Your administrator has installed the Red Hat Developer Hub Operator in the cluster.
  • You have provisioned your custom config maps and secrets in your <my-rhdh-project> project.

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/v1alpha3
    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/v1alpha3
    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

1.5. Exposing your operator-based Red Hat Developer Hub instance on Amazon Elastic Kubernetes Service (EKS)

On Amazon Elastic Kubernetes Service (EKS), to expose your Red Hat Developer Hub instance, Kubernetes ingresses replace OpenShift Container Platform routes. The Red Hat Developer Hub operator does not create ingresses. Therefore, to access your Developer Hub instance via a domain name, create the required ingresses on EKS and point your domain name to it.

Prerequisites

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. To deploy the created Ingress, run:

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

Verification

  • Wait until the DNS name is responsive, indicating that your Developer Hub instance is ready for use.

2. Installing Developer Hub on EKS with the Helm chart

When you install the Developer Hub Helm chart in Elastic Kubernetes Service (EKS), it orchestrates the deployment of a Developer Hub instance, which provides a robust developer platform within the AWS ecosystem.

Prerequisites

Procedure

  1. Go to your terminal and run the following command to add the Helm chart repository containing the Developer Hub chart to your local Helm registry:

    helm repo add openshift-helm-charts https://charts.openshift.io/
  2. Create a pull secret using the following command:

    kubectl create secret docker-registry rhdh-pull-secret \
        --docker-server=registry.redhat.io \
        --docker-username=<user_name> \ 1
        --docker-password=<password> \ 2
        --docker-email=<email> 3
    1
    Enter your username in the command.
    2
    Enter your password in the command.
    3
    Enter your email address in the command.

    The created pull secret is used to pull the Developer Hub images from the Red Hat Ecosystem.

  3. Create a file named values.yaml using the following template:

    global:
      # TODO: Set your application domain name.
      host: <your Developer Hub domain name>
    
    
    route:
      enabled: false
    
    
    upstream:
      service:
        # NodePort is required for the ALB to route to the Service
        type: NodePort
    
    
      ingress:
        enabled: true
        annotations:
          kubernetes.io/ingress.class: alb
    
    
          alb.ingress.kubernetes.io/scheme: internet-facing
    
    
          # 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:xxx:xxxx:certificate/xxxxxx
    
    
          alb.ingress.kubernetes.io/listen-ports: '[{"HTTP": 80}, {"HTTPS":443}]'
    
    
          alb.ingress.kubernetes.io/ssl-redirect: '443'
    
    
          # TODO: Set your application domain name.
          external-dns.alpha.kubernetes.io/hostname: <your rhdh domain name>
    
    
      backstage:
        image:
          pullSecrets:
          - rhdh-pull-secret
        podSecurityContext:
          # you can assign any random value as fsGroup
          fsGroup: 2000
      postgresql:
        image:
          pullSecrets:
          - rhdh-pull-secret
        primary:
          podSecurityContext:
            enabled: true
            # you can assign any random value as fsGroup
            fsGroup: 3000
      volumePermissions:
        enabled: true
  4. Run the following command in your terminal to deploy Developer Hub using the latest version of Helm Chart and using the values.yaml file created in the previous step:

    helm install rhdh \
      openshift-helm-charts/redhat-developer-hub \
      [--version 1.7.0] \
      --values /path/to/values.yaml

Verification

Wait until the DNS name is responsive, indicating that your Developer Hub instance is ready for use.

Legal Notice

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