Platform Engineering - Red Hat Developer Hub

Before RHDH:

With RHDH:

Verify the RHDH pods are running:

You should see:

By default, RHDH only reads catalog files from within the cluster. To register components from Git repositories (where real teams store their catalog-info.yaml files), we need to allow external reads. This is a common ops task when setting up RHDH.

Add the GitHub reading configuration to the existing RHDH app config:

Restart the deployment to pick up the config change:

Wait for the new pod to be ready (this takes about a minute):

Click the Developer Hub tab at the top of Showroom. You’ll see the login page — select Guest and click Enter.

Click on a pod to see:

The RHDH Operator manages the Backstage instance:

Click on the Red Hat Developer Hub tab to see the deployed instances:

View the Backstage CR via CLI:

Get detailed status:

The catalog is the heart of Developer Hub — a unified view of every service your organization runs. Right now it’s empty because nobody has registered anything. Let’s fix that.

Applications are registered via catalog-info.yaml files — simple YAML that describes what the service is, who owns it, and where it runs. Here’s what one looks like:

Register two applications from this workshop into the catalog:

Now click Catalog in the left navigation. You should see two components registered:

Click on either one to see the component overview page showing the owner, lifecycle, tags, and the OpenShift namespace annotation.

In production, this catalog would contain hundreds of services across dozens of teams. Developers find services, understand who owns them, read documentation, and check deployment status — all without asking ops. When teams leave or services are deprecated, the catalog makes it visible instead of leaving orphaned workloads running in the cluster.

But right now, this catalog is just a list. Click on weather-app — you see metadata, but nothing about what’s actually running in the cluster. A developer looking at this would still have to ask you: "Is my app running? How many pods are up? Any restarts?"

Let’s fix that.

RHDH needs read access to the cluster to display Kubernetes resources. We’ll create a dedicated service account with least-privilege access — cluster-reader, not cluster-admin:

Create a token for the service account and store it as a Secret that RHDH can use:

RHDH ships with dozens of plugins bundled in the image — they just need to be switched on. We’ll enable three:

Create a ConfigMap that tells RHDH which plugins to activate:

Now tell RHDH where to find the cluster and how to authenticate. We need the API server URL and the console URL (so developers can click through to OpenShift):

Now patch the Backstage Custom Resource to tell the Operator about our new dynamic plugins ConfigMap and the service account token Secret:

The Operator sees the CR change and triggers a rolling restart — new pods with plugins enabled, old pods terminated, zero downtime. Watch it happen:

This takes 2-3 minutes as the init container installs the dynamic plugins before the main container starts.

The Kubernetes plugin discovers pods by matching a label on the workloads to the backstage.io/kubernetes-id annotation on the catalog component. Label the weather app deployments:

Go back to the Developer Hub tab and click on weather-app in the catalog. You should now see:

This is the moment. A developer clicks a service in the catalog and sees exactly what’s running — pod count, restart history, resource usage — without oc access, without opening a ticket, without messaging you on Slack.

You configured this once. Every service in the catalog gets this for free when it has the right annotations and labels. That’s the Kubernetes plugin eliminating your most common developer question: "Is my app running?"