As an architect involved in platform engineering and DevEx transformation within a large-scale organization for the past few years, I’ve seen firsthand how developer experience directly shapes not just the speed and quality of software delivery, but also how effectively teams can adopt governance, security, and compliance practices as enablers rather than blockers. I can truly say this was made possible by establishing proven golden paths and enabling true developer self-service.

In this first post, I will try to explain how we can use Backstage to create these golden paths. Predefined, opinionated software templates that help developers spin up new services quickly and stay compliant without added friction.

Before diving deeper, it’s worth clarifying first what we mean by platform engineering and DevEx.

What Do We Mean by Platform Engineering, DevEx and IDPs?

Platform Engineering

I can say, it is the discipline of building and maintaining the internal infrastructure, tooling, and workflows that empower development teams and enable self-service capabilities. It’s like providing a paved road for developers to drive on. It creates kind an abstraction layer between developers and operations that not only shields developers from unnecessary complexity but also ensures that operational, security, and compliance concerns are handled by design.

Why Did Platform Engineering Emerge?

In my experience, as organizations scale their engineering teams and adopt cloud-native architectures, development teams face growing friction. They spend increasing amounts of time setting up infrastructure, understanding CI/CD pipelines, managing permissions, complying with security policies and often reinventing the wheel in slightly different ways.

While DevOps also is meant to bridge the gap between development and operations, in practice it often shifts more operational responsibilities onto developers without providing the right tools or abstractions. Today, with new tools popping up constantly, things have become even more complex. The usual result is cognitive overload, inconsistent practices, and slower delivery.

In contrast, platform engineering brings a product mindset to internal infrastructure. It focuses on building reusable, self-service platforms that abstract away complexity while enforcing standards.

These platforms are often referred to as Internal Developer Platforms (IDPs), and are designed to give developers everything they need to build, deploy, and operate software efficiently and securely. You can think of an IDP as something like ServiceNow, but built specifically for developers. Just as ServiceNow provides a centralized place for business users to request IT services, an IDP provides a unified interface where developers can access templates, provision infrastructure, set up CI/CD, or request resources all in a consistent and compliant way.

While it is possible to build your own centralized platform automation control plane, for example, you might use tools like Crossplane, Tofu Controller, Argo CD and OPA on top of k8s to make that happen, of course depending on your IaC and GitOps strategy, there are also mature tools and reference architectures available that are worth exploring. You can take a look at some of them here.

Developer Experience (DevEx)

DevEx refers to the overall experience developers have throughout the software development lifecycle. It includes everything from how quickly developers can start a new project to how easily they can locate documentation, access infrastructure and tooling, and troubleshoot problems. It’s about removing friction at every step, giving clear paths, fast feedback loops, and removing unnecessary toil.

Good DevEx means developers spend less time on repetitive, low value tasks and more time solving real business problems and driving innovation. It reduces frustration and boosts productivity, all while improving consistency and compliance across environments.

When we invest in DevEx, we are not just improving developer happiness. We are increasing productivity, quality, and engagement. That in turn, directly impacts an organization’s ability to move faster, respond to market demands, and create more room for innovation.

In short, while DevEx is about the overall experience, IDPs and Developer Portals (DevEx Portals) are how we can bring that experience to life. The platform provides the underlying capabilities, the engine, enabling things like self-service infrastructure provisioning, CI/CD pipelines and policy enforcement in standardized and secure way. The portal is the UI for these platform capabilities, a single pane of glass where developers can access everything they need from templates and docs to services, APIs and observability tools.

In my experience, platform engineering plays an important role in shaping DevEx by providing the paved paths, guardrails and tools developers need to move fast and safely. When done right, it enables teams to ship confidently without sacrificing standards or autonomy.

Also, one thing I have observed is that when some people talk about improving DevEx, the conversation often jumps straight to infrastructure layers, IDPs, or complex automation frameworks. While those are undoubtedly powerful and lay the foundation, in my view and based on my experience, they are not always the most accessible or practical starting point, especially for teams that aren’t yet ready for full platform engineering efforts.

In my view, I might be also wrong, you can begin your DevEx journey by bringing standardization, documentation, and discoverability to your existing software assets. This is where tools like Backstage (a DevEx Portal) come in.

Backstage helps teams create golden paths that are well-defined, reusable templates and documentation that guide developers through consistent ways of building software. It offers a central DevEx Portal, or single pane of glass, where developers can find everything they need, from APIs and services to documentation and CI/CD status, without jumping between tools. As the organization matures, it also allows seamless integration with broader platform capabilities, including the IDP.

So, with that being said, let’s dive into Backstage and see how it can help us create golden paths and improve DevEx from day one.

Backstage: The DevEx Portal

Backstage is an open-source DevEx Portal originally created by Spotify. It enables organizations to centralize and standardize how software assets, developer workflows, infrastructure components, and tools are managed. By bringing everything into a single, self-service interface, Backstage helps reduce context switching, promote consistency, and improve developer productivity at scale.

And that really matters

Because if you think about the typical developer’s day, it’s filled with small but constant interruptions such as:

• Where was the documentation for service X again?
• Do we already have a service/library for this?
• Which environments is this deployed to?
• How do I deploy this to k8s. Is there a guideline or template?

These may seem like minor hurdles, but when they accumulate across teams and over time, they hinder delivery and frustrate developers. Backstage addresses this by making software assets of the organization discoverable and making standards visible and reusable. Whether you are looking for an API’s spec, checking the CI/CD status of your app or spinning up a new service using a golden path template, it’s all accessible from a single unified platform.

Let’s Get Our Hands Dirty

Let’s see how we can create a golden path using Backstage templates, starting with a simple API project that gets published to GitHub and appears in the portal.

Installing Backstage Locally

To run Backstage locally, there are a few things we need to install like “nvm“, “Node.js” and “Yarn“. The following commands will help us to set up a standalone Backstage app quickly.

➜ curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.40.3/install.sh | bash
➜ nvm install lts/iron
➜ corepack enable
➜ yarn set version 4.4.1

NOTE: For other setup options, including Docker based approaches, you can check the official Backstage documentation.

Once our env is ready, we can create the Backstage app.

npx @backstage/create-app

Then start the app!

cd my-backstage-app # your app name
yarn start

Getting Familiar with Backstage

Before jumping into golden paths, let’s quickly explore some of the key features of Backstage.

Software Catalog

At its core, Backstage is powered by the Catalog, which is also the first thing we see when we open the portal. The catalog keeps track of all our software components like services, websites, APIs, libraries, and more. Each component is defined using a simple “catalog-info.yaml” manifest that typically lives alongside the source code in its repository. Once registered, these components become visible, searchable, and manageable through the portal.

As i mentioned earlier, this is one of the easiest and most impactful ways to start your DevEx journey. By leveraging the catalog feature, you can bring instant structure and discoverability to your existing software assets right from day one.

When you click on one of the catalog items, let’s say the “example-website” item, you will see a detailed view of that component.

This page gives us everything we need to know about the item like its metadata (which is fully customizable), ownership details (which becomes especially important in large organizations), source code location, technical documentation, linked APIs, CI/CD status, and more. If the component exposes APIs, they can also be listed and documented right here, making it easier for other teams to discover, understand, and reuse them. This view can be also enriched with additional plugins like ArgoCD, Kubernetes and many others. We can even develop our own custom plugins to surface organization specific data or actions. You can explore all available plugins here.

TechDocs

Another useful feature of Backstage is TechDocs, which brings documentation closer to the code and into the portal. It’s based on MkDocs, so teams can write docs in Markdown and store them alongside the source code in the repository. Once integrated, the documentation becomes searchable and accessible right inside Backstage. This means developers no longer need to jump between tools to find or read internal docs.

Software Templates

In addition to docs, Backstage also supports Software Templates, which allow teams to scaffold new projects quickly and consistently. These templates can be anything and be tailored to include organization’s preferred tech stacks, standards, CI/CD templates, repository structures and even security and compliance integrations.

And i like to call these golden paths, predefined paths that give teams a solid foundation and help them start on the right foot from day one.

Creating Golden Paths/Software Templates

When we talk about golden paths, we are referring to opinionated, predefined ways of building software that align with organizational standards and best practices.

As i mentioned earlier in the article, golden paths are not restrictions. They are about enabling teams to reach their goals faster, in a consistent and compliant way. They are also a great mechanism for driving governance, security and compliance as enablers rather than blockers. When things baked into golden paths, adoption becomes natural by design.

Golden paths can be anything that is repeatable, useful, and aligned with best practices:

• A microservice or frontend app scaffolded with standards like CI/CD, IAM, and observability setups.
• A hardened infrastructure as code module with built-in security and compliance policies.
• Or even a sandbox environment template that lets teams experiment safely.

In short, a golden path can be anything that helps your organization move faster, stay consistent, and build with confidence through enablement and developer self-service.

In Backstage, software templates are the foundation for implementing these golden paths. They let us package everything from folder structure and config files to integrations and documentation into a reusable, self-service experience.

Under the hood, Backstage uses a scaffolder engine that reads a simple manifest file to define each software template. This manifest controls what input variables are required from the user, what actions to run, and how the resulting template should be created and published to locations like GitHub or Azure DevOps.

For example this “Example Node.js Template” form asks the user for basic input like the name of the component. Once submitted, Backstage scaffolds the project based on predefined instructions behind the scenes and publishes it to the selected Git location.

Template Manifest

Each Backstage software template is powered by a simple “template.yaml” manifest file. This yaml file acts as a blueprint that defines how the scaffolding process works. These templates are also stored in the “Software Catalog” under “Templates” kind.

A typical template manifest includes these key sections:

• “metadata”
  • Defines the name, description, tags and ownership of the template.
• “spec.type”
  • Defines what kind of software component the template will generate. Common values are “service”, “website”, “library” or custom types that reflect how an organization classifies software. This helps organize components consistently in the catalog and enables better filtering and discoverability.
• “spec.lifecycle”
  • Indicates the stage of the component such as “experimental”, “production” or “deprecated”. This helps teams understand the maturity of the generated component.
• “spec.parameters”
  • Declares the form inputs that users will fill out in the UI.
• “spec.steps”
  • The list of actions to perform such as fetching source files, templating them, publishing to GitHub and so on. We will take a closer look at this shortly.
• “spec.output”
  • Defines what should be shown to the user once the scaffolding is complete. Think of it like shortcuts, links to the Git repo of the generated project, and similar helpful outputs.

Here is a minimal example manifest:

apiVersion: scaffolder.backstage.io/v1beta3
kind: Template
metadata:
  name: my-template
  title: Title of the Template
  description: Some details about what this template scaffolds
spec:
  owner: owning-team
  type: service
  parameters:
    - title: Service Info
      required:
        - name
      properties:
        name:
          type: string
          title: Name of the service
          description: Some information about this parameter
  steps:
    - id: fetch-base
      name: Fetch base template
      action: fetch:template
      input:
        url: ./skeleton
    - id: publish
      name: Publish to GitHub
      action: publish:github
      input:
        repoUrl: github.com/my-org/{{ parameters.name }}
  output:
    links:
      - title: Source Code
        url: '{{ steps.publish.output.repoUrl }}'

So far, we have discussed the importance of golden paths and briefly explored how a Backstage template is structured. Now, it’s time to create one ourselves and register it as a template in Backstage.

But before we jump into building our first template, let’s take a quick step to enable GitHub integration. This will allow Backstage’s scaffolder engine to create and publish the generated project directly to a GitHub repository as part of the templating process. Of course GitHub is just one example. Backstage supports other source control providers as well, so it’s up to each organization to choose what fits their environment best.

To enable the integration, first we need to create a PAT with the following scopes “repo”, “workflow”, and “admin:repo_hook”. Since GitHub integration is already configured in the “app-config.yaml” file under “integrations: GitHub” section using the “${GITHUB_TOKEN}” variable, all we need to do is to set this environment variable before running Backstage. In addition, if we you using Node.js 20+, set “NODE_OPTIONS” environment variable to avoid issues with Backstage’s scaffolder.

export GITHUB_TOKEN="YOUR_PAT_TOKEN"
export NODE_OPTIONS="${NODE_OPTIONS:-} --no-node-snapshot"

NOTE: If you would like to avoid setting these variables manually, consider using the “dotenv” package to manage them in a “.env” file.

Let’s Build a Golden Template

Imagine that we want to prepare a battle tested microservice API boilerplate that developers can use to spin up new services quickly without worrying about setting up the API structure, creating a repository, writing a Dockerfile, configuring CI/CD pipelines, or integrating with IAM and observability stacks. In short, everything that our organization typically uses, packaged in a way that saves developers time and effort.

For sake of the simplicity, I will keep things straightforward in this example. Let’s start by creating a local repository, which we will later push to GitHub. I will call it “sample-backstage-template“. In the root of this repository, create a folder named “skeleton“. This is where we will place our boilerplate code that gets scaffolded into new projects.

Now, let’s create a .NET 9 API project inside the “skeleton” folder using the following command. Alternatively, you can use any existing boilerplate code you already have. For this example, I will call the API “MyOrg.XToken“.

dotnet new webapi -n MyOrg.XToken

Inside the generated project folder, let’s also define a Dockerfile. You can use Visual Studio to generate one, or create it manually. After that, go back to the root of the “skeleton” folder and create a “ci.yml” file under the “.github/workflows” directory. This will allow us to demonstrate that our golden API template includes a hardened CI/CD pipeline out of the box.

Last but not least, create an empty “README.md” file under a “docs” folder.

Our folder structure should now look like this:

sample-backstage-template
└── skeleton
    ├── .github/workflows/ci.yml
    ├── docs/README.md
    ├── MyOrg.XToken/
    └── MyOrg.XToken.sln

Now it’s time to start tokenizing our .NET boilerplate code so that it can be reused across projects with different names, owners, and configurations. We will use a templating syntax like ${{ values.parameterName }}  to inject dynamic values into the generated project files.

With that in mind, let’s identify and tokenize the parts of our boilerplate code that should vary per project such as the project name, port number, folder and file names, README content, and so on. In this example, I’m going to replace all occurrences of “XToken” in the .NET boilerplate and also parameterize the exposed port in the Dockerfile as shown below.

FROM mcr.microsoft.com/dotnet/aspnet:9.0 AS base
WORKDIR /app
EXPOSE ${{ values.port }}

ENV ASPNETCORE_URLS=http://+:${{ values.port }}

USER app
FROM --platform=$BUILDPLATFORM mcr.microsoft.com/dotnet/sdk:9.0 AS build
ARG configuration=Release
WORKDIR /src
COPY ["MyOrg.${{ values.projectName }}/MyOrg.${{ values.projectName }}.csproj", "MyOrg.${{ values.projectName }}/"]
RUN dotnet restore "MyOrg.${{ values.projectName }}/MyOrg.${{ values.projectName }}.csproj"
COPY . .
WORKDIR "/src/MyOrg.${{ values.projectName }}"
RUN dotnet build "MyOrg.${{ values.projectName }}.csproj" -c $configuration -o /app/build

FROM build AS publish
ARG configuration=Release
RUN dotnet publish "MyOrg.${{ values.projectName }}.csproj" -c $configuration -o /app/publish /p:UseAppHost=false

FROM base AS final
WORKDIR /app
COPY --from=publish /app/publish .
ENTRYPOINT ["dotnet", "MyOrg.${{ values.projectName }}.dll"]

README.md

# MyOrg.${{ values.projectName }}
This service was generated using the golden path template.

ci.yaml

name: ci

on:
  push:
    branches:
      - main
  pull_request:

jobs:
  docker-build:
    runs-on: ubuntu-latest

    steps:
      - name: Checkout source
        uses: actions/checkout@v3

      - name: Set up Docker Buildx
        uses: docker/setup-buildx-action@v2

      - name: Build Docker image
        run: |
          docker build -t myorg/MyOrg.${{ values.projectName }}:${{ '${{ github.sha }}' }} .

As you can see, for the project name I used “${{ values.projectName }}” and for the port “${{ values.port }}“. Later on, we will define these values in our Backstage template manifest and pass them to the scaffolder engine.

In addition to tokenizing the boilerplate code itself, we also want our generated project to include a dynamic “catalog-info.yaml” file. As mentioned earlier, this file defines the metadata that Backstage uses to register and display the component in the software catalog. And just like we did in the codebase, we can inject template values here as well to make the metadata dynamic and reusable.

catalog-info.yaml

apiVersion: backstage.io/v1alpha1
kind: Component
metadata:
  name: MyOrg.${{ values.projectName }}
  description: MyOrg.${{ values.projectName }} project.
  tags:
    - dotnet
    - api
    - microservice
    - ${{ values.owner }}
  annotations:
    backstage.io/techdocs-ref: dir:.
spec:
  type: service
  lifecycle: experimental
  owner: ${{ values.owner }}

Here,

• Inside the “metadata” section, we have defined the “name” and the “description” of the component, along with a few meaningful tags. Tags play an important role in improving the discoverability and organization of catalog entities within Backstage.
• The “type” is set to “service” which indicates that this component is a backend service.
• The “lifecycle” is set to “experimental” which helps teams understand the maturity of the project. You can change this later to values like “production” based on your lifecycle policies.
• The “owner” field is important for access control, visibility and routing issues to the right team. We will pass this dynamically during scaffolding.
• Last but not least, with the “backstage.io/techdocs-ref: dir:.” annotation, we tell Backstage where to find the docs like README.md, mkdocs.yml and others for generating and displaying TechDocs for this component.

Now that we have completed our sample skeleton and it’s time to define the template manifest. This manifest tells Backstage how to scaffold the project, what parameters to ask from the user, what files to generate and what steps to run during the scaffolding process.

So let’s create a template.yaml file in the root directory of the “sample-backstage-template” repository.

apiVersion: scaffolder.backstage.io/v1beta3
kind: Template
metadata:
  name: dotnet-api-template
  title: .NET 9 API Template
  description: Scaffolds a .NET 9 Web API project with Dockerfile and CI
  tags:
    - dotnet
    - api
    - microservice
    - starter-api-app
  annotations:
    backstage.io/techdocs-ref: dir:.
spec:
  type: service
  lifecycle: experimental
  owner: user:guest
  parameters:
    - title: .NET API project information
      required:
        - projectName
        - port
        - owner
      properties:
        projectName:
          title: Project Name
          type: string
          description: Unique name of the .NET API project.
        port:
          title: Port
          type: number
          description: Port the API will run on (e.g. 5000)
        owner:
          title: Team Name
          type: string
          description: Name of the team that will own this service.
  steps:
    - id: fetch-base
      name: Fetch Base
      action: fetch:template
      input:
        url: ./skeleton
        values:
          projectName: ${{ parameters.projectName }}
          port: ${{ parameters.port }}
          owner: ${{ parameters.owner }}

    - id: publish
      name: Publish to GitHub
      action: publish:github
      input:
        repoUrl: github.com?owner=YOUR_GITHUB_USERNAME&repo=${{ parameters.projectName }}
        defaultBranch: 'main'

    - id: register
      name: Register to Catalog
      action: catalog:register
      input:
        repoContentsUrl: ${{ steps['publish'].output.repoContentsUrl }}
        catalogInfoPath: '/catalog-info.yaml'

  output:
    links:
      - title: Go to generated project
        url: https://github.com/YOUR_GITHUB_USERNAME/${{ parameters.projectName }}

At a high level, in this manifest,

• Inside the “metadata” section, we have defined the meaningful name, description and tags for this template to make it easily discoverable in Backstage.
• Also set the “lifecycle” to “experimental” as an example for this template, and assigned the “ownership” to “user:guest“, which is the default guest user in Backstage. If we had defined a team like the Platform Team, we could have used that instead.
• “parameters“: these are the dynamic inputs we expect from the user like project name, port and owning team. These will be used to tokenize the boilerplate during generation. Backstage provides a rich set of built-in field types like text, number, select, multiselect with validation capabilities. In addition to the build-in types, we can extend the form with custom input fields. For example you might want to fetch team names or repository names dynamically from internal APIs, offer different autocomplete suggestions. For more details about available input types and validation options, you can check the official documentation here.
• “steps“: this is the sequence of actions Backstage performs to scaffold the new project. Backstage scaffolder comes with a rich set of built-in actions that cover common automation needs. So in our case:
  • “fetch-base“: pulls in the boilerplate code from the skeleton folder and applies the input parameters to replace the tokenized placeholders in the code. This is how the code gets customized per user input.
  • “publish:github“: pushes the generated code to GitHub using the given repo name.
  • “catalog:register“: registers the newly scaffolded project in Backstage’s software catalog so it becomes immediately discoverable.
  • You can explore these built-in actions directly from the Backstage UI by going to: “Create > three dots menu in the top right corner > Installed Actions“. This panel lists all the available registered actions and it’s great way to explore what’s possible without writing any code. Backstage also allows you to write custom actions to extend scaffolder’s capabilities like integrating with internal APIs and etc. By combining built-in and custom actions the scaffolder becomes a powerful automation engine tailored to your organization’s specific workflows. You can refer to the action docs for a detailed guide.
• “output“: once the project is generated, we show useful links like the link to the newly created GitHub repository so that users can quickly access their new service.

Now, let’s also define a README.md file under a “docs” folder in the root directory of the template repository. This will serve as documentation for the template itself and can also be used by TechDocs to generate documentation in Backstage.

README.md

# dotnet-api-template
Scaffolds a .NET 9 Web API project with Dockerfile and CI

With the template definition in place, we have completed the development of the golden template. Now before going to register this template in the software catalog, we can also validate and preview how it behaves within Backstage.

To do that, you can use the build-in template editor feature in the scaffolder UI by navigating to “Create > three dots menu in the top right corner > Manage Templates > Load Template Directory“.

This feature allows us to load a template directly from our local file system and interactively fill out the form and validate input behavior. This is very handy when we are actively developing and iterating on the template, as it provides quick feedback without modifying the actual catalog.

The final step is now to make our template discoverable within Backstage so that we can start using it.

Registering the Template in Backstage

Backstage provides a few different ways to register templates in the software catalog. The most straightforward method is through the scaffolder UI by navigating to the “Create > Register Existing Component” page. Then, paste the URL of the template.yaml file (for example a GitHub URL). Backstage will fetch the file, validate the manifest and guide us through registration process.

NOTE: In order to register a template through the UI, “Template” must be allowed in the catalog rules defined in “app-config.yaml“.

The other option is to add the template to the static catalog configuration file or directly in the “app-config.yaml” file as shown below.

catalog:
  rules:
    - allow: [Component, System, API, Resource, Location, Template, User, Group]
  locations:
    - type: url 
      target: https://YOUR_TEMPLATE_REPOSITORY_URL/template.yaml

This is especially useful for organization wide templates maintained by platform teams. Additionally, you can maintain a separate catalog configuration file in a shared repository allowing others in the organization to contribute by creating pull requests to add the templates they develop.

So, for simplicity, I’m going to add the template directly in the “app-config.yaml” file as shown above, and then restart Backstage. After restarting, navigate to the catalog homepage at “http://localhost:3000/catalog” and filter by “Kind=Template“. We should now see our “.NET 9 API Template” listed. Click on it to view its details.

Here, we can see some basic details about our golden template, such as its description, intended purpose, owner, maturity level, and more.

Now that our template is registered, let’s walk through how to scaffold a new project by using it.

Scaffolding a Project

If we click the “Launch Template” button, we will be taken to the “Create New Component” page, where we can use this template to scaffold a new .NET 9 API. Alternatively, we can simply click the “Create” button from the left menu and select the template from the list.

As you can see, these are the parameters we defined in the template. Let’s fill them in and click the “REVIEW” button. I will be using the following values:

• Project Name: Search.API
• Port: 5000
• Team Name: guests

On the review page, you will see the values that the scaffolder engine is going to use. If everything looks good, click the “CREATE” button.

On this template run page, we can see couple of useful information. The task ID of the run is shown for reference and for future debugging in case something goes wrong. Logs display the step by step progress of the scaffolding process. Shortcuts allow users to easily navigate to resources such as the generated Git repository in our case. There is also a set of tabs that show which actions were executed and their statuses during the run.

Now, if we click the “GO TO GENERATED PROJECT” shortcut, we will be redirected to the GitHub repository where the project has been created.

So, in my case, the project has been successfully scaffolded and all the placeholder tokens have been replaced. From a developer’s perspective, this means I’m now ready to focus on implementing the actual business logic, rather than spending time on setting up the project structure, CI/CD pipeline or other boilerplate tasks.

Now, if we go back to the catalog homepage in Backstage, we can see that our newly generated project has also been registered in Backstage’s software catalog. If we click on it, we can also view its metadata, including information such as the description, owner, lifecycle and any tags defined in the template. If the catalog page has integrations configured like CI/CD tools or APIs linked with OpenAPI specs, the component page will show extra information in tabs such as CI/CD and API. This helps developers better understand and access different information in one place.

Before wrapping up, let’s also go back to the “Create” page, click on the three dots in the upper right corner and select the “Task List“. This will take us to a page that displays all template runs. This page is especially useful for platform teams or those responsible for maintaining Backstage, as it provides visibility into all scaffolding executions and helps in troubleshooting issues when other teams encounter problems during template runs.

Wrapping Up

In this article, we have walked through how to use the Backstage scaffolder to bootstrap new projects efficiently by using pre-defined templates that enforce standards and reduce repetitive setup work. With the ability to automatically generate code, pipelines, metadata, and more, Backstage empowers development teams to focus on what matters most. As a result, organizations can achieve faster onboarding, better consistency, and improved developer experience across the board.

Whether you are part of a platform team or a developer just getting started, understanding the scaffolder and catalog workflows is key to unlocking Backstage’s potential. And as we have seen, even without a full internal developer platform in place, Backstage can deliver immediate value through standardization, discoverability and a well-structured scaffolder setup that lays the groundwork for golden paths.

References

https://github.com/GokGokalp/sample-backstage-template
https://backstage.io/docs/overview/what-is-backstage
https://platformengineering.org/blog/what-is-platform-engineering