Skip to main content
Redhat Developers  Logo
  • Products

    Featured

    • Red Hat Enterprise Linux
      Red Hat Enterprise Linux Icon
    • Red Hat OpenShift AI
      Red Hat OpenShift AI
    • Red Hat Enterprise Linux AI
      Linux icon inside of a brain
    • Image mode for Red Hat Enterprise Linux
      RHEL image mode
    • Red Hat OpenShift
      Openshift icon
    • Red Hat Ansible Automation Platform
      Ansible icon
    • Red Hat Developer Hub
      Developer Hub
    • View All Red Hat Products
    • Linux

      • Red Hat Enterprise Linux
      • Image mode for Red Hat Enterprise Linux
      • Red Hat Universal Base Images (UBI)
    • Java runtimes & frameworks

      • JBoss Enterprise Application Platform
      • Red Hat build of OpenJDK
    • Kubernetes

      • Red Hat OpenShift
      • Microsoft Azure Red Hat OpenShift
      • Red Hat OpenShift Virtualization
      • Red Hat OpenShift Lightspeed
    • Integration & App Connectivity

      • Red Hat Build of Apache Camel
      • Red Hat Service Interconnect
      • Red Hat Connectivity Link
    • AI/ML

      • Red Hat OpenShift AI
      • Red Hat Enterprise Linux AI
    • Automation

      • Red Hat Ansible Automation Platform
      • Red Hat Ansible Lightspeed
    • Developer tools

      • Red Hat Trusted Software Supply Chain
      • Podman Desktop
      • Red Hat OpenShift Dev Spaces
    • Developer Sandbox

      Developer Sandbox
      Try Red Hat products and technologies without setup or configuration fees for 30 days with this shared Openshift and Kubernetes cluster.
    • Try at no cost
  • Technologies

    Featured

    • AI/ML
      AI/ML Icon
    • Linux
      Linux Icon
    • Kubernetes
      Cloud icon
    • Automation
      Automation Icon showing arrows moving in a circle around a gear
    • View All Technologies
    • Programming Languages & Frameworks

      • Java
      • Python
      • JavaScript
    • System Design & Architecture

      • Red Hat architecture and design patterns
      • Microservices
      • Event-Driven Architecture
      • Databases
    • Developer Productivity

      • Developer productivity
      • Developer Tools
      • GitOps
    • Secure Development & Architectures

      • Security
      • Secure coding
    • Platform Engineering

      • DevOps
      • DevSecOps
      • Ansible automation for applications and services
    • Automated Data Processing

      • AI/ML
      • Data Science
      • Apache Kafka on Kubernetes
      • View All Technologies
    • Start exploring in the Developer Sandbox for free

      sandbox graphic
      Try Red Hat's products and technologies without setup or configuration.
    • Try at no cost
  • Learn

    Featured

    • Kubernetes & Cloud Native
      Openshift icon
    • Linux
      Rhel icon
    • Automation
      Ansible cloud icon
    • Java
      Java icon
    • AI/ML
      AI/ML Icon
    • View All Learning Resources

    E-Books

    • GitOps Cookbook
    • Podman in Action
    • Kubernetes Operators
    • The Path to GitOps
    • View All E-books

    Cheat Sheets

    • Linux Commands
    • Bash Commands
    • Git
    • systemd Commands
    • View All Cheat Sheets

    Documentation

    • API Catalog
    • Product Documentation
    • Legacy Documentation
    • Red Hat Learning

      Learning image
      Boost your technical skills to expert-level with the help of interactive lessons offered by various Red Hat Learning programs.
    • Explore Red Hat Learning
  • Developer Sandbox

    Developer Sandbox

    • Access Red Hat’s products and technologies without setup or configuration, and start developing quicker than ever before with our new, no-cost sandbox environments.
    • Explore Developer Sandbox

    Featured Developer Sandbox activities

    • Get started with your Developer Sandbox
    • OpenShift virtualization and application modernization using the Developer Sandbox
    • Explore all Developer Sandbox activities

    Ready to start developing apps?

    • Try at no cost
  • Blog
  • Events
  • Videos

How to implement developer self-service with Backstage

More deployments, less YAML

June 25, 2025
Evan Shortiss
Related topics:
GitOpsPlatform engineering
Related products:
Red Hat Developer HubRed Hat OpenShift

Share:

    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:

    1. Generate source code and Kubernetes manifests.
    2. 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. 

    A developer using a Software Tempalte to generate a new project that consists of two repositories; source code and deployment manifests
    Figure 1: A developer using a Software Tempalte to generate a new project that consists of two repositories; source code and deployment manifests

    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.

    A developer using a Software Template to request an application deployment. Once approved and merged, the deployment is handled using OpenShift GitOps.
    Figure 2: A developer using a Software Template to request an application deployment. Once approved and merged, the deployment is handled using OpenShift GitOps.

    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:

    1. Install OpenShift GitOps.
    2. Load a set of sample Software Templates.
    3. 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. 

    The Argo CD Dashboard after the initial install and login
    Figure 3: The Argo CD Dashboard after the initial install and login

    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.

    The Register Existing Component button as seen on the Software Templates screen in Red Hat Developer Hub
    Figure 4: The Register Existing Component button as seen on the Software Templates screen in Red Hat Developer Hub

    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.

    The two sample software templates as seen after being loaded into Red Hat Developer Hub
    Figure 5: The two sample software templates as seen after being loaded into Red Hat Developer Hub

    Set up the app-of-apps pattern

    This is a two-step process:

    1. Create a repository named app-of-apps in your GitHub organization.
    2. 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.

    The app-of-apps Application as seen post-creation in Argo CD.
    Figure 6: The app-of-apps Application as seen post-creation in Argo CD.

    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. 

    A developer fills out the parameters for the Next,js on OpenShift Software Tempate.
    Figure 7: A developer fills out the parameters for the Next,js on OpenShift Software Template.

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

    Repositories created by the Next.js on OpenShift Software Template.
    Figure 8: Repositories created by the Next.js on OpenShift Software Template.

    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.

    Container images are built and pushed to a container registry automatically.
    Figure 9: Container images are built and pushed to a container registry automatically.

    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.

    Generated deployment manifest files. These target a standardized Helm Chart for deployment.
    Figure 10: Generated deployment manifest files. These target a standardized Helm chart for deployment.

    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: 

    1. The software component you’d like to deploy.
    2. The environment you’d like to deploy the component to.
    3. 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.

    Deploy Application to Environment Software Template with parameters filled.
    Figure 11: Deploy Application to Environment Software Template with parameters filled.

    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.

    Pull request that was opened by the Deploy Application to environment Software Template.
    Figure 12: Pull request that was opened by the Deploy Application to environment Software Template.

    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.

    Applications being managed by the the app-of-apps.
    Figure 13: Applications being managed by the the app-of-apps.

    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.

    Application deployment status shown in Red Hat Developer Hub using the Argo CD plugins.
    Figure 14: Application deployment status shown in Red Hat Developer Hub using the Argo CD plug-ins.

    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.

    Related Posts

    • Red Hat Developer Hub: The fastest path to Backstage on Kubernetes

    • Backstage authentication and catalog providers: A practical guide

    • A self-service approach to building virtual machines at scale

    • Driving Developer Portal Adoption with Red Hat Developer Hub Adoption Insights

    • Getting Started with OpenShift GitOps

    • Unveiling Backstage: A developer's guide to the CNCF project

    Recent Posts

    • Create and enrich ServiceNow ITSM tickets with Ansible Automation Platform

    • Expand Model-as-a-Service for secure enterprise AI

    • OpenShift LACP bonding performance expectations

    • Build container images in CI/CD with Tekton and Buildpacks

    • How to deploy OpenShift AI & Service Mesh 3 on one cluster

    What’s up next?

    Writing “Hello, World” hasn’t gotten any harder—but running it has. Download our developer’s guide to developer portals to learn how engineering teams can reduce friction and boost productivity using internal developer portals (IDPs).

    Get the e-book
    Red Hat Developers logo LinkedIn YouTube Twitter Facebook

    Products

    • Red Hat Enterprise Linux
    • Red Hat OpenShift
    • Red Hat Ansible Automation Platform

    Build

    • Developer Sandbox
    • Developer Tools
    • Interactive Tutorials
    • API Catalog

    Quicklinks

    • Learning Resources
    • E-books
    • Cheat Sheets
    • Blog
    • Events
    • Newsletter

    Communicate

    • About us
    • Contact sales
    • Find a partner
    • Report a website issue
    • Site Status Dashboard
    • Report a security problem

    RED HAT DEVELOPER

    Build here. Go anywhere.

    We serve the builders. The problem solvers who create careers with code.

    Join us if you’re a developer, software engineer, web designer, front-end designer, UX designer, computer scientist, architect, tester, product manager, project manager or team lead.

    Sign me up

    Red Hat legal and privacy links

    • About Red Hat
    • Jobs
    • Events
    • Locations
    • Contact Red Hat
    • Red Hat Blog
    • Inclusion at Red Hat
    • Cool Stuff Store
    • Red Hat Summit
    © 2025 Red Hat

    Red Hat legal and privacy links

    • Privacy statement
    • Terms of use
    • All policies and guidelines
    • Digital accessibility

    Report a website issue