Developer Hub - Portal Operations

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

Click Catalog in the left navigation. You’ll see services registered by several teams across your organization:

This is what replaces the "who owns this workload?" question. Every service has an owner, a lifecycle stage, and metadata connecting it to the cluster. When a team leaves or a service is deprecated, it’s visible here instead of becoming an orphaned mystery workload.

The catalog isn’t just a list - it’s a searchable, filterable inventory. Try using the filters on the left sidebar. If you don’t see the filter options, click the filter icon or expand your browser window wider.

In a real organization with hundreds of services, these filters are how you answer questions that used to require searching through namespaces, Slack threads, or tribal knowledge.

Clear any filters and click on payments-platform in the catalog. You’ll see the component overview page with owner, lifecycle, and tags.

Now click the Kubernetes tab.

You should see 3 pods running - payments-api, payments-processor, and payments-gateway - with their status, restarts, and age. This data is live from the cluster.

This is the key. A developer clicks their 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. You didn’t have to do anything for this to work. The platform team configured it once, and every service with the right labels gets this for free.

Try clicking on weather-app and then the Kubernetes tab - you’ll see all 5 weather microservice pods.

Now click on inventory-system in the catalog and check its Kubernetes tab.

You’ll see an Error Reporting section at the top - the inventory-db-migrator pod is in CrashLoopBackOff. The error messages are right there: restart count, failure reason.

This is what a developer sees when something is broken - and what they’d show you in a ticket. Instead of "my app is broken, can you look?" they can tell you "inventory-db-migrator is crashlooping with a database connection error." That’s a much better starting point for troubleshooting.

Now click on order-tracker. Notice the Kubernetes tab shows nothing - this service is registered in the catalog but hasn’t been deployed yet.

You’ll fix that later in this module.

Switch to the OCP Console tab. Make sure the Administrator perspective is selected, then go to Workloads → Pods and select the backstage project from the dropdown.

You’ll see two pods:

Click on the backstage-developer-hub pod (it will have a random suffix like backstage-developer-hub-fcdd8d5df-2qf4b) and look at the Details tab. Scroll down to the Volumes section - you’ll see the ConfigMaps mounted into the pod: app-config-rhdh (application config), pre-built-catalog (catalog entries and template), and backstage-appconfig-developer-hub (default config).

Back in the terminal, let’s trace how RHDH is configured. Start with the Backstage Custom Resource - this is the single source of truth for the deployment:

This shows you four key configuration points:

What plugins are enabled? Check the dynamic plugins ConfigMap:

You should see the Kubernetes backend and frontend plugins (show pod data), Topology plugin (visual map), and scaffolder modules (power the software templates). The quickstart plugin is disabled - that’s the setup wizard we don’t need.

How does RHDH authenticate to the cluster? Check the app-config:

It uses authProvider: serviceAccount with a token stored in ${K8S_PLUGIN_SA_TOKEN} (from the Secret we saw above). Check what permissions that service account has:

The two that matter are rhdh-cluster-reader (can view pods across the cluster) and rhdh-scaffolder-binding (can create namespaces for templates). Ignore the rhdh-operator lines - those are the operator’s own permissions. This is least-privilege: RHDH can read cluster state and create namespaces, but nothing more.

The Kubernetes plugin discovers pods by matching labels. This is the contract between the catalog and the cluster:

Verify this on the weather app:

The weather microservice deployments should show weather-app as their backstage ID. You may see weather-db with <none> - that’s the debugging exercise pod from Module 05, which isn’t part of the catalog. Any deployment with a wrong or missing label won’t appear in the Kubernetes tab. You’ll see exactly this during the troubleshooting section.

In the Developer Hub tab, scroll down on the Home page to Explore Templates. You’ll see the Deploy a New Service template - this was built by the platform team to let developers provision their own namespaces following approved patterns.

Click Deploy a New Service, then click Launch Template to open the form.

Fill in:

Click Review, then Create.

Watch the template execute. You’ll see four steps complete:

This is the golden path. A developer filled in a form. The template created a namespace, deployed two services, and labeled everything for Developer Hub discovery - all following patterns your platform team defined. No tickets, no manual namespace creation, no "can you label this for me", no drift from standards.

Back in the terminal, verify what the template created:

The template created the namespace, deployed both services, and set the backstage labels - all in one click.

Now go to Developer Hub > Catalog > order-tracker > Kubernetes tab. You should see 2 pods running immediately - no manual labeling needed.

This is what replaced three separate requests to your team: "create me a namespace", "deploy my app", "wire it up to Developer Hub". One template, one click, done.

The payments team reports that their gateway service vanished from the Developer Hub Kubernetes tab, but the pod is still running.

Simulate the problem:

Go to Developer Hub > payments-platform > Kubernetes tab. You should see only 2 pods instead of 3.

The deployment is running, but it’s invisible. Diagnose it:

You should see payments-gateway has the value payments-gateway instead of payments-platform. The label doesn’t match the catalog annotation - so the plugin can’t find it.

Fix it:

Check the payments-platform Kubernetes tab again - all 3 pods should be back.

The inventory team reports their service is showing errors in Developer Hub. They want to know what’s wrong.

You already saw this in Step 5 - the inventory-db-migrator pod is crashlooping. Now diagnose it from the CLI like you would in production:

You’ll see inventory-db-migrator in CrashLoopBackOff. Check the logs:

The log shows: FATAL: Cannot connect to database at postgres.inventory-team:5432 - connection refused. The pod is trying to reach a database that doesn’t exist.

This is a development issue, not an ops issue - the inventory team deployed a database migration job before setting up their database. You’d respond to the ticket: "Your inventory-db-migrator is crashlooping because it can’t connect to postgres.inventory-team:5432. The database service doesn’t exist in that namespace. Check with your dev team that the database is deployed before running migrations."

Delete the broken deployment to clear the error:

Check the inventory-system Kubernetes tab in Developer Hub - the error reporting section should be gone, and you should see 3 healthy pods.

Two different failure modes, two different diagnosis paths:

The first is an ops fix (correct the label). The second is a dev team issue (tell them what’s wrong and let them fix their code). Knowing the difference saves you from chasing problems that aren’t yours.

The RHDH operator has a built-in monitoring toggle that creates a ServiceMonitor for Prometheus:

This doesn’t restart the pod - it just tells the operator to create a ServiceMonitor so Prometheus starts scraping the metrics endpoint that RHDH already exposes.

Verify the ServiceMonitor was created:

Navigate to the OCP Console > Observe > Metrics. Enter this query and click Run Queries:

You should see the catalog entity counts broken down by kind - the same components, templates, and groups you explored in the catalog earlier, now visible as metrics.

Try another query to see API traffic:

This shows the request rate to RHDH - if this drops to zero, the portal is down. If it spikes, something is hammering the API.

Clean up by disabling the monitoring toggle: