Unlocking Developer Bliss: A First Look At Backstage.io


In an increasingly complex development landscape, a seamless experience for developers is not a luxury; it’s a necessity. This article explores how Backstage.io provides a unified platform for building developer portals, enhancing developer experience, and the emerging role of Platform Engineering in this ecosystem. I’ve personally started to dig into the platform engineering space after spending a considerable amount of time working in DevOps. I believe that we have put too much on developer’s plates, and it’s time to ease their pain. In this article, I’ll focus on Backstage.io as a key player in the open-source infrastructure landscape. Join me on this learning path.


Below is a video explanation and demo.

Video Chapters

You can skip to the relevant chapters below:

  • 00:00 – Introduction
  • 00:51 – Install Backstage
  • 04:31 – The Backstage UI
  • 07:58 – Create an App via Backstage
  • 10:52 – Update the Component
  • 12:42 – Backstage Software Template
  • 13:14 – Final Thoughts


Join the Newsletter and get FREE access to the Source Code

Why Developer Portals Are Essential

In a development environment where dozens of tools and services are in play, a developer portal serves as the single source of truth. It helps developers find all the services they need without the hassle of navigating through multiple platforms.

Building a developer portal has become a top priority for platform engineering teams aiming to centralize resources, streamline workflow, and ultimately enhance the workflow for coders. A well-designed portal isn’t just another internal tool; it’s an integrated playground for all your infrastructure tooling.

The Role of Backstage in Developer Portals

Backstage.io isn’t just a place to find applications or libraries; it’s a platform that enables developers to integrate seamlessly with your existing tools and services.

It offers a level of customization that allows you to shape the portal according to your specific needs.

Utilizing Backstage.io as an open platform for constructing these portals empowers development teams. A homegrown developer portal built on Backstage offers the efficiency needed to manage services, tackle pull requests, and even orchestrate data pipelines seamlessly. I’m quite happy to work with an open-source product that is a CNCF incubation-level project at the time of writing this article.

Building Developer Portals: The Intersection of Services and Software Catalog

The Evolution of the Developer Portal

Developer portals have evolved far beyond being mere repositories of technical documentation. Today, they serve as robust service catalogs, a centralized hub where developers can discover all the tools and services they need.

Software Catalog as the Nucleus

The software catalog or service catalog in Backstage serves as more than just an inventory. It allows for rich metadata that can be tailored to fit the nuances of your internal software, thereby enhancing discoverability and utilization.

In Backstage, the centralized software catalog acts as the core, offering a uniform overview of all the software and services. By cataloging new projects and existing services along with ownership information, Backstage simplifies the developer’s journey, boosting overall developer productivity.

Backstage Software Catalog: More Than Just a List

A Dynamic Platform

The Backstage service catalog offers more than just a static list. Designed to manage thousands of software components efficiently, it serves as a dynamic platform enabling developers to create, manage, and explore software all in one unified space.

Documentation and Code: Two Sides of the Same Coin

In Backstage, technical documentation isn’t an afterthought but an integrated feature. With Backstage TechDocs, developers can write and store documentation in markdown files, right alongside their code, maintaining high-quality software and documentation concurrently.

Personalizing Developer Experience

Backstage.io offers features like personalized dashboards, making it easier for developers to find the tools and resources that are most relevant to them.

Backstage goes a step further with its software templates and plugins, enabling developers to personalize their workspace according to their needs. From creating new services and projects to managing existing services, Backstage offers flexibility and adaptability, making it an ideal choice for DevOps engineers and other stakeholders.

Backstage Software Templates

A Software Template in Backstage provide a standardized way to scaffold a new project. They allow organizations to define templates for different kinds of software projects, thus ensuring that new projects are set up with best practices, correct dependencies, and optimal configurations right from the start. Here are some key points:

  1. Standardization: Templates help maintain consistency across multiple projects, making it easier for teams to onboard new members and transition between different projects.
  2. Automation: With templates, repetitive initial setup tasks are automated, saving time and reducing the scope for errors.
  3. Customization: Organizations can create their own custom templates tailored to meet specific requirements, whether it’s a microservices architecture, a web application, or a data science project.

Backstage Plugins

Backstage Plugins extend the functionality of Backstage to serve specific needs. Plugins can range from providing database insights, CI/CD build statuses, or even integrating with cloud services. Here are some noteworthy aspects:

  1. Modularity: Plugins can be added or removed without affecting the core functionality of Backstage, making it modular and scalable.
  2. Community Contributions: The Backstage community is active, and there are a plethora of open-source plugins available that can be readily integrated.
  3. Custom Plugins: If your organization has specific requirements not met by existing plugins, you can develop custom plugins and integrate them into Backstage. They are typically written in Typescript. So your team needs to be proficient in Typescript.

Developer Experience (DevEx): It’s All About the Journey

Despite its significance, the DevEx often gets overlooked during the early stages of software development. Backstage aims to restore order to this chaos by offering a single, unified portal where all developer tools and services can be found.

Platform Engineering: The Evolution of DevOps and the Craft of Internal Developer Platforms

The Birth of a New Discipline

As software development evolves, so do its surrounding disciplines. Platform Engineering has emerged as a field focusing on crafting robust internal developer platforms that serve developers efficiently. I’m quite excited to follow this trend and believe it’s not a passing fad. However, to be realistic, I don’t believe it will replace DevOps as DevOps is a culture and not a role. Moreover, it might be an overkill to implement platform engineering at small organizations and startups. Larger organizations stand to benefit the most from platform engineering.

The Role of Platform Engineers

Platform engineers are responsible for maintaining the health of the internal developer portal. They ensure that the tools and services are up-to-date, secure, and performant.

Platform Engineers are the key architects behind these platforms. Their work goes beyond just maintaining developer tools and internal infrastructure; they aim to streamline the entire development process. In Backstage, they can find a platform conducive to these ideals, offering features that make it easier to go from a pull request to a fully deployed service.

Advancements in DevEx

Platform Engineering streamlines the workflow for software engineers by focusing on creating a seamless, user-friendly environment. Backstage, with its range of features like software templates and TechDocs, offers the tools required for such an undertaking.

The Journey So Far

As you probably already know, Backstage was developed by Spotify and later donated to the CNCF. Its flexibility, community-driven enhancements, and adaptability make it a great solution for evolving developer needs. I know quite a few colleagues who have adopted backstage at their organizations and I wanted to give it a try myself. I wanted to see how easy it is to get started and if it really can help build a golden path for developers. Let’s get started with the example below.

Getting Started with a Backstage Example

Now I’m going to start with Backstage from scratch. I’d like to get a feel for the product and the UI, so we’ll start with a very simple example out of the box. Note that I couldn’t get it to work in codespaces, I suspect something to do with port forwarding so I’ve installed it on my local machine. Below are the instructions.

Step 1: Install the App

As per the official documentation, you will need to have Nodejs, Yarn, npx, and git installed on your local machine. I found that at the time of this writing, node 16 or node 18 worked the best.

Start by running the following command:

npx @backstage/create-app@latest

and here is the expected output:

> npx @backstage/create-app@latest
Need to install the following packages:
@backstage/[email protected]
Ok to proceed? (y) y
? Enter a name for the app [required] my-backstage-app
Creating the app...
 Checking if the directory is available:
  checking      my-backstage-app ✔ 
 Creating a temporary app directory:
  creating      temporary directory ✔ 
 Preparing files:
  copying       .dockerignore ✔ 
  templating    .eslintrc.js.hbs ✔ 
  templating    .gitignore.hbs ✔ 
  copying       .prettierignore ✔ 
  copying       README.md ✔ 
  copying       app-config.local.yaml ✔ 
  copying       app-config.production.yaml ✔ 
  templating    app-config.yaml.hbs ✔ 
  templating    backstage.json.hbs ✔ 
  templating    catalog-info.yaml.hbs ✔ 
  copying       lerna.json ✔ 
  templating    package.json.hbs ✔ 
  copying       tsconfig.json ✔ 
  copying       yarn.lock ✔ 
  copying       README.md ✔ 
  copying       entities.yaml ✔ 
  copying       org.yaml ✔ 
  copying       template.yaml ✔ 
  copying       catalog-info.yaml ✔ 
  copying       index.js ✔ 
  copying       package.json ✔ 
  copying       README.md ✔ 
  templating    .eslintrc.js.hbs ✔ 
  copying       Dockerfile ✔ 
  copying       README.md ✔ 
  templating    package.json.hbs ✔ 
  copying       index.test.ts ✔ 
  copying       index.ts ✔ 
  copying       types.ts ✔ 
  copying       app.ts ✔ 
  copying       auth.ts ✔ 
  copying       catalog.ts ✔ 
  copying       proxy.ts ✔ 
  copying       scaffolder.ts ✔ 
  templating    search.ts.hbs ✔ 
  copying       techdocs.ts ✔ 
  copying       .eslintignore ✔ 
  templating    .eslintrc.js.hbs ✔ 
  copying       cypress.json ✔ 
  templating    package.json.hbs ✔ 
  copying       android-chrome-192x192.png ✔ 
  copying       apple-touch-icon.png ✔ 
  copying       favicon-16x16.png ✔ 
  copying       favicon-32x32.png ✔ 
  copying       favicon.ico ✔ 
  copying       index.html ✔ 
  copying       manifest.json ✔ 
  copying       robots.txt ✔ 
  copying       safari-pinned-tab.svg ✔ 
  copying       .eslintrc.json ✔ 
  copying       app.js ✔ 
  copying       App.test.tsx ✔ 
  copying       App.tsx ✔ 
  copying       apis.ts ✔ 
  copying       index.tsx ✔ 
  copying       setupTests.ts ✔ 
  copying       LogoFull.tsx ✔ 
  copying       LogoIcon.tsx ✔ 
  copying       Root.tsx ✔ 
  copying       index.ts ✔ 
  copying       EntityPage.tsx ✔ 
  copying       SearchPage.tsx ✔ 
 Moving to final location:
  moving        my-backstage-app ✔ 
 Installing dependencies:
  determining   yarn version ✔ 
  executing     yarn install ✔ 
  executing     yarn tsc ✔ 
🥇  Successfully created my-backstage-app

 All set! Now you might want to:
  Install the dependencies: cd my-backstage-app && yarn install
  Run the app: cd my-backstage-app && yarn dev
  Set up the software catalog: https://backstage.io/docs/features/software-catalog/configuration
  Add authentication: https://backstage.io/docs/auth/

Step 2: Navigate to the Project Directory

Now navigate to the project directory using:

cd my-backstage-app

Step 3: Start the Backstage App

Start the Backstage app using the following command:

yarn dev

This will launch the app and make it accessible via a web browser at `http://localhost:3000`. Here is a screenshot of the UI.

Backstage UI Home Page

Step 4: Integrate GitHub

My first goal was to see if I could create a template for developers to use when creating a new application. Fortunately, Backstage comes with a default template out of the box, but first, we need to integrate GitHub.

If you open the app-config.yaml file inside the my-backstage-app folder, you will see an integration section as shown below:

    - host: github.com
      # This is a Personal Access Token or PAT from GitHub. You can find out how to generate this token, and more information
      # about setting up the GitHub integration here: https://backstage.io/docs/getting-started/configuration#setting-up-a-github-integration
      token: ${GITHUB_TOKEN}
    ### Example for how to add your GitHub Enterprise instance using the API:
    # - host: ghe.example.net
    #   apiBaseUrl: https://ghe.example.net/api/v3
    #   token: ${GHE_TOKEN}

Since it’s not a good idea to put any kind of secrets into a file that gets pushed into git, I opted to use an environment variable to pass my GitHub personal token into Backstage. You can do the same by running this command:

export GITHUB_TOKEN=your/personal/github/token

Now restart the app by hitting ctrl+c and re-running yarn dev

If you don’t know how to create a GitHub personal token, check out the steps below:

Steps to Create a GitHub Personal Access Token

  1. Log in to GitHub: Open GitHub and log in to your account.
  2. Access Settings: Click on your profile picture in the top-right corner and select “Settings.”
  3. Developer settings: Scroll down the settings page and click on “Developer settings” at the bottom.
  4. Personal access tokens: On the left sidebar, click on “Personal access tokens.”
  5. Generate Token: Click on the “Generate new token” button at the top right of the page.
  6. Token Settings:
    • Note: Enter a note to remind you what the token is for, such as “Backstage token.”
    • Select Scopes: Check the boxes for the permissions your token needs. For our use case you will need repo and read:org scopes. Read the description for each scope to know what permissions you’re granting.
  7. Generate Token: Scroll down and click the “Generate token” button.
  8. Copy Your New Token: Your new personal access token will be displayed. Make sure to copy it now. You won’t be able to see it again!

Warning: Keep it Secret, Keep it Safe

  • A personal access token is like a password: never share it with anyone.
  • Store it securely, and make sure you don’t accidentally commit it in your code.

Step 5: Create a Sample App using a Backstage Template

Now it’s time to finally see how a developer can create the scaffolding for an app from within Backstage using a pre-defined template created by the platform engineering team. As mentioned before this template comes out of the box for creating Node.js apps. You can find it under the examples folder in the my-backstage-app folder.

├── examples
│   ├── entities.yaml
│   ├── org.yaml
│   └── template
│       ├── content
│       │   ├── catalog-info.yaml
│       │   ├── index.js
│       │   └── package.json
│       └── template.yaml

Navigate to the ‘Create’ section and follow the on-screen instructions.

Create a Node.js App from a Template

Now give your new app a name and a repo with a repo owner. The repo owner is your GitHub username. In Backstage terms, this app is called a Component. I found that you should call the component the same name as the repo in this case or else you run into an error when registering the component in the software registry.

Review the New App Component

and you should have successfully added your new app/component.

Successfully Added Component

Step 6: Explore the Newly Created Component

This is what the new GitHub repo created by Backstage looks like:

GitHub Repo Created

Now we can check out our new service or app or component however you want to call it in our service catalog. Below is a screenshot of it:

Our New Component in the Catalog

Notice a few things about our new component. There are multiple tabs at the top which are:

  • Overview
  • CI/CD
  • API
  • Dependencies
  • Docs

We will just take a look at the Overview in this post and explore the rest in subsequent posts.

In the Overview tab, notice the following:

  • View Source: which takes us back to the GitHub repo
  • View Techdocs: which takes us to the docs, but it’s currently disabled.
  • Relations: A neat graph that provides a visual representation of the relationships between our component and other entities in our system. This could include services, APIs, packages, libraries, teams, or users. The graph helps in understanding how different parts of your system are connected to each other and how changes to one component might affect others.
  • Links: A list of external hyperlinks related to our component. Links can provide additional contextual information that may be located outside of Backstage itself. For example, an admin dashboard or external CMS page. We will make a change here to see what happens.
  • Has subcomponents: This is used to indicate that a component is made up of one or more smaller components, essentially forming a parent-child relationship between them. This is useful for representing complex systems or services that are composed of smaller, independently managed pieces. For example, you might have a web application component that “Has subcomponents” like a frontend UI component and multiple backend service components for handling business logic, database operations, and so on.

Step 7: Understand the catalog-info.yaml File

The catalog-info.yaml file serves as a metadata descriptor for components and resources in the Backstage catalog. It provides details about the component, such as its name, owner, type, and more. By registering this YAML file in the Backstage catalog, you make it possible to manage and visualize your component in the Backstage interface. It looks incredibly familiar to Kubernetes manifests.

Here’s a brief rundown of some common fields:

  • apiVersion: Specifies the version of the schema for this particular YAML file. Typically, it’s something like backstage.io/v1alpha1.
  • kind: The kind of component this is, like Component, API, Resource, System, etc.
  • metadata: Metadata about the component.
    • name: The name of the component.
    • description: A brief description of the component.
    • annotations: Key-value pairs for additional, optional metadata. For example, the location of the component’s source code.
  • spec: The specification of the component.
    • type: The type of the component, like service, library, or website.
    • lifecycle: Lifecycle state, like experimental, production, or deprecated.
    • owner: The team or entity that owns this component.
    • relations: Describes relationships between this component and other entities in the catalog.

Here is the catalog-info.yaml file in our GitHub repo that was created.

apiVersion: backstage.io/v1alpha1
kind: Component
  name: "my-node-app"
  type: service
  owner: user:guest
  lifecycle: experimental

Step 8: Update our Component

Let’s now make a small update to our component by putting an external link in our Links section. Backstage gives us a thing with a button to read more on their documentation site.

Links Section of Our Component

Okay, so we can now modify our catalog-info.yaml file by going to our repo, or by simply clicking the pencil icon at the top right corner of the About card. This will allow us to edit the file directly in GitHub. Add the links section to our file as shown below:

apiVersion: backstage.io/v1alpha1
kind: Component
  name: "my-node-app"
    - url: https://dashboard.example.com
      title: My Dashboard
      icon: dashboard
  type: service
  owner: user:guest
  lifecycle: experimental

Now commit this to GitHub and refresh the Component page on Backstage to see the link appear:

Links Updated

My First Impressions

I had a great time exploring Backstage, and I hope this blog post has piqued your interest as well. Here are my final thoughts on this introductory exploration of Backstage.

What I Liked:

  • Plugin Architecture: I appreciate the thorough thought process that Spotify has put into enhancing the developer experience. The modular design of Backstage, bolstered by its plugin architecture, is particularly compelling.
  • Open-Source and CNCF: The fact that Backstage is an open-source project and a part of the CNCF adds a level of credibility and community support.
  • Single Pane of Glass: One of the key advantages of Backstage is that it consolidates all your tools, services, and documentation into a single, coherent interface, thereby reducing the cognitive load on developers.
  • Built-in Best Practices: By providing templates and scaffolding capabilities, Backstage encourages best practices right from the project’s inception. This can improve code quality and speed up the development process. This is a really great aspect that creates guardrails and governance.
  • Integrated Technical Documentation: Backstage’s TechDocs feature allows developers to write technical documentation directly within the platform, making it easier to keep documentation and code in sync.

What I Disliked:

  • Complexity:
    • Initial Setup: Since I’m not primarily a Node.js developer, I found the initial setup to be a bit cumbersome. A ready-made Docker image for quick demos and tests would have been helpful.
    • Customization: While the ability to extend Backstage is one of its strengths, it also introduces complexity. Customizing it to fit specific organizational needs can require a significant amount of effort and expertise. This is just my initial impression from the documentation, and I might revise this view as I gain more experience.
  • Potential for Vendor Lock-in:
    • Spotify Ecosystem: Backstage was originally developed by Spotify, and it’s tailored to their specific use cases. While it’s highly customizable, some features seem closely tied to Spotify’s ecosystem, which could potentially lead to a form of vendor lock-in. This is purely speculative, and I welcome differing opinions in the comments below.

Key Takeaways

  • The Rise of Platform Engineering: This discipline is revolutionizing the way organizations approach software development, making it more efficient, collaborative, and enjoyable.
  • Backstage’s Capabilities: With its wide array of features and plugins, Backstage emerges as a robust tool designed for Platform Engineers.
  • Developer-Centric Design: The focus on streamlining workflows places Backstage at the forefront of this evolution, offering an integrated, flexible, and dynamic platform to cater to all your development needs.

Stay tuned for more in-depth posts on Backstage as I continue my exploration!

Suggested Reading

Scroll to Top