Golden path templates (also known as Software Templates) are a core feature of Backstage, a framework for building internal developer portals (IDPs) that offer self-service capabilities to developers. When using Backstage as your IDP, Software Templates enable self-service capabilities, automation of best practices, and standardization of workflows. Codifying these capabilities using Software Templates reduces the cognitive load on developers and minimizes their time wrangling with YAML and underlying infrastructure concerns, thereby increasing their productivity. For example, a developer who creates a new application using a Software Template will start with a project that follows the organization’s best practices and has continuous integration (CI) and continuous delivery (CD) pipelines pre-configured.
The IDP is generally part of broader platform engineering initiatives that benefit the entire organization. In enterprise environments, changes to underlying tools and frameworks are subject to security review, compliance rules require that processes are auditable, and deployments to application environments must be reviewed and approved. An organization that adopts platform engineering and a set of standards can ensure that such requirements are satisfied with minimal impact on developer productivity.
Let’s dive in and learn how to use Software Templates to boost developer productivity and enable self-service deployments that include an approval process, using Backstage.
Solution overview
In this post I’ll outline a GitOps-based approach to standardized application delivery using Red Hat OpenShift GitOps (based on Argo CD) to manage the actual deployment, in tandem with Red Hat Developer Hub (based on Backstage) to provide simplified developer self-service—without the need for JIRA. We’re assuming that Red Hat OpenShift is the organization’s chosen application platform.
Using the App of Apps pattern with Argo CD allows the platform team to create a centralized app-of-apps
repository that developers use to request application deployments. The app-of-apps
repository should have access controls in place to ensure application deployments are reviewed before being merged, and subsequently deployed on your OpenShift and Kubernetes clusters.
Expecting a developer to become familiar with the complexity of the underlying platform and deployment processes can be a blocker to getting their code in production. To simplify the process from the developer’s perspective, we split the process into two steps that are executed using Software Templates from the IDP:
- Generate source code and Kubernetes manifests.
- Request deployment.
In step one, the developer creates a new project from scratch using a Software Template–this generates two repositories in the organization’s GitHub or alternative Git hosting solution. This process is illustrated in Figure 1.

The source code repository contains application source code, and uses a continuous integration (CI) system such as Jenkins or GitHub Actions to build container images. The development team can begin implementing features by modifying the code in the generated source code repository.
Once the development team is ready, the developers move on to the next step–deploying their code to the development environment. A second Software Template is used to open a pull request to the app-of-apps
repository within the GitHub organization. This pull request creates a new Argo CD application manifest that points to the Helm chart created by the first Software Template, and a container image built by the application code’s CI system. Once merged, Argo CD will detect the new application manifest and deploy it by rendering a set of Kubernetes resources using the application Helm chart.

The developer doesn’t need to write Helm charts or Custom Resources during this process; they can simply focus on application code, and the deployment is taken care of by the standard deployment manifests and Software Templates that were crafted by the platform team.
Note
The manifests repository can point to Helm charts developed by the platform engineering team to ensure all deployments follow a standard pattern. Development teams can use updated versions of the Helm charts created by platform engineers to access new features, instead of patching Kubernetes resources in their manifest repository manually.
Implementing the self-service solution
Before diving into the implementation details, let's review the necessary prerequisites and what we'll be doing at a high level.
Prerequisites and outline
To implement this flow in your own environment, you’ll need to meet the following requirements:
- Admin access to an OpenShift 4.16+ cluster (to install OpenShift GitOps)
- Admin access to an instance of Red Hat Developer Hub 1.5+
- Create a GitHub organization (you can do this for free)
- Configure the GitHub integration for Red Hat Developer Hub
A prior article, The fastest path to Backstage on Kubernetes, provides a quick start for deploying Red Hat Developer Hub on OpenShift. This post assumes that your GitHub integration for Red Hat Developer Hub targets a GitHub organization that you control, and matches the configuration outlined in another previous article.
Once the prerequisites have been met, you’ll:
- Install OpenShift GitOps.
- Load a set of sample Software Templates.
- Configure the app-of-apps pattern in OpenShift GitOps.
Note
The workflow outlined in this blogpost assumes that the repositories created by the Software Templates are public. This means your OpenShift environment can access the container images built using GitHub Actions and pushed to GitHub Container Registry without the use of a pull secret. For production scenarios you will most likely create private repositories and push images to a private container registry, which in turn means that OpenShift will need a pull secret to access those container images.
Install OpenShift GitOps
You’ll need an Argo CD instance to get up and running with this example. Follow the documented instructions to install the OpenShift GitOps Operator using the OpenShift web console to get started quickly. The OpenShift GitOps Operator automatically creates an openshift-gitops
namespace with Argo CD deployed.
Use the following commands to get the URL and password to log in to your Argo CD instance as the admin user:
oc project openshift-gitops
oc get secret argocd-cluster -o jsonpath="{.data['admin\.password']}"
oc get route argocd-server -o jsonpath='{.spec.host}'
Visit the URL in your web browser and log in as the admin user using the password you obtained from the Secret. If you see a dashboard similar to Figure 3, you’re ready to move to the next step.

You should also ensure that the OpenShift GitOps installation is added to the cluster-admins group, as outlined in our Getting Started with OpenShift GitOps article.
Enable the necessary Red Hat Developer Hub plug-ins
Update your Red Hat Developer Hub configuration to enable the required plug-ins to support the solution. Refer to the documentation for installing dynamic plug-ins to find the relevant steps for your installation type (i.e., Helm or Operator-based installation). The necessary plug-ins are listed in the following snippet:
- package: ./dynamic-plugins/dist/backstage-plugin-catalog-backend-module-github-dynamic
disabled: false
- package: ./dynamic-plugins/dist/backstage-plugin-catalog-backend-module-github-org-dynamic
disabled: false
- package: ./dynamic-plugins/dist/backstage-plugin-scaffolder-backend-module-github-dynamic
disabled: false
- package: ./dynamic-plugins/dist/backstage-community-plugin-github-actions
disabled: false
- package: ./dynamic-plugins/dist/roadiehq-scaffolder-backend-module-utils-dynamic
disabled: false
These plug-ins will be used by Software Templates to publish new repositories and open pull requests on GitHub, show the status of GitHub Actions for components, and modify files.
Add the Software Templates to Developer Hub
A set of sample templates are provided in the evanshortiss/backstage-gitops-blog-templates repository on GitHub. These templates implement the flow described in the Solution overview section.
Add the Software Templates to your instance of Red Hat Developer Hub by updating your Backstage catalog locations configuration, or by using the Register Existing Component button on the Create screen, as shown in Figure 4.

Return to the Create screen and confirm the new Software Templates are listed, as shown in Figure 5. The Next.js on OpenShift template creates a source code repository and set of manifests for a new application. The Deploy Application to Environment template can be used to open a pull request against the app-of-apps
repository to request an application deployment.

Set up the app-of-apps pattern
This is a two-step process:
- Create a repository named
app-of-apps
in your GitHub organization. - Create an Argo CD application that monitors the
app-of-apps
repository.
Get started by creating the app-of-apps
repository with the following structure. A real world example can be found in the rhdh-demo-gh/app-of-apps repository. The .gitkeep
files—as the name suggests—are used to ensure the empty folders that represent deployment environments can be checked into the repository:
app-of-apps/
├── README.md
├── development/.gitkeep
├── production/.gitkeep
Create a new application in Argo CD with the following YAML, being sure to replace the repoURL
with the URL for your app-of-apps
repository:
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
name: app-of-apps-development
finalizers:
- resources-finalizer.argocd.argoproj.io
spec:
destination:
name: ''
namespace: ''
server: https://kubernetes.default.svc
source:
path: ./development
repoURL: https://github.com/REPLACE_ME/app-of-apps
targetRevision: HEAD
directory:
recurse: true
project: default
syncPolicy:
automated:
prune: true
selfHeal: true
This Argo CD application recursively searches for applications to deploy in the development
directory. By default, it will show just the app-of-apps-development
application, as shown in Figure 6.
You can create a second application to deploy Applications in a production environment, or change the source
key to sources
and manage both development and production using multiple sources in a single application.

As outlined earlier, developers will use a Software Template in Red Hat Developer Hub to open pull requests to this protected repository. Merging a pull request results in their application being continuously delivered by Argo CD post-merge.
Test the self-service experience
Time to adopt a developer persona to test the self-service experience! The following actions will be performed by developers in your organization to get up and running with new applications.
Generate an application source and manifests
Return to the Create screen in Red Hat Developer Hub locate the Next.js on OpenShift template. Click the Choose button and fill in the template, taking care to populate the name of your GitHub organization correctly (Figure 7). Click Next, complete the review process, and run the template.

Upon successful completion, two new repositories will be visible in your GitHub organization, as shown in Figure 8.

Visit the source code repository and visit the Actions page to confirm a GitHub Actions workflow is running. Once the workflow run is complete, a new package containing builds of the Next.js application container image will be listed in the Packages section of the repository. See Figure 9.

Those platform engineers crafted a nice experience, right? By default, a new container image is built whenever code is pushed to the main branch. Developers can focus on coding because the tedious continuous integration aspects have been taken care of for them.
Remember that this is a sample application. If you prefer to use GitLab and Quay to store source code and container images, you can absolutely do so.
Review application manifests
Visit the manifest repository for your new application, and open the development
folder. You might be shocked to find that it contains just two files; a Chart.yaml
and values.yaml
, as shown in Figure 10.

The platform engineering team thoughtfully crafted a Helm chart that generates Kubernetes manifests that are suitable for most deployment scenarios. The chart is referenced in the Chart.yaml
file.
apiVersion: v2
name: my-nextjs-app
description: Deploys an application using the standard OpenShift Deployment
version: 0.1.0
dependencies:
- name: openshift-deployment
version: 0.1.0
repository: https://rhdh-demo-gh.github.io/helm-charts/
The included values.yaml
in each folder can be modified to configure environment specific parameters and pass them to the Helm chart. For example, production might scale to 10 replicas, whereas development runs just 2 application replicas. You’ll also notice that the image to deploy is referenced in the values.yaml
and corresponds to the image built by the source code repository.
openshift-deployment:
image:
repository: ghcr.io/rhdh-demo-gh/approvals-example
pullPolicy: IfNotPresent
tag: "main"
service:
port: 3000
Request a deployment to the development environment
Once you’ve reviewed the repositories and made changes to the source code, you’ll probably be eager to deploy it. Return to Red Hat Developer Hub and select the Deploy Application to Environment template from the Create screen.
This template requires just three parameters:
- The software component you’d like to deploy.
- The environment you’d like to deploy the component to.
- The target GitHub organization that contains the
app-of-apps
repository (this could be hardcoded behind the scenes for a more seamless deployment experience)
The first two parameters are presented using pre-populated drop-down elements in the form, so there’s no chance of a developer providing invalid values. Figure 11 shows the drop-downs with values selected by the developer.

Select the Component that corresponds to the Next.js application you created earlier and choose the Development environment, then run the template. The template outputs a link to the deployment pull request in the app-of-apps
repository—click that link. The pull request should resemble Figure 11.

Approve the deployment
Merge the pull request, bearing in mind that you might need to log in as a different user, depending on the configuration of your GitHub organization and who has approve and merge rights in the app-of-apps
repository.
Next, check Argo CD and you’ll see your new application. If it doesn’t appear initially, click the Refresh button and it will force Argo CD to check the app-of-apps
repository for changes. You can see my new approvals-example
application alongside another application I deployed previously in Figure 13.

If you’ve enabled the Argo CD plug-in for Red Hat Developer Hub, then your developers will be able to view the deployment status of their application directly from the internal developer portal, as shown in Figure 14.

Conclusion
Creating a successful application platform involves more than just assembling a suite of tools; it requires anticipating and understanding the needs of your developers. By abstracting the underlying implementation details, developers can focus on what truly matters to them and the business: shipping code and features to production. An approach similar to the one demonstrated in this article eliminates distractions, empowers developers to be more productive, and ultimately drives business success through efficient software delivery.
Try Red Hat Developer Hub for free on the Developer Sandbox.