---
title: "Backstage | Skills We Assign For | Azendo"
description: "Backstage as a developer portal — service catalogue, ownership, scaffolding, and the Azendo roles assigned for it."
url: "https://azendo.co/skills/backstage/"
---

[Skills](https://azendo.co/skills/) Cloud and infrastructure 

# Backstage.

Backstage is an open-source developer portal framework. It provides a software catalogue, service ownership metadata, technical documentation and scaffolding templates behind one interface, extended through plugins.

## Where Backstage fits on a long engagement.

The problem Backstage addresses is real in any organisation past a certain size: nobody can answer who owns a service, where its documentation is, or what it depends on. A catalogue with enforced ownership metadata makes those answerable, which matters most during an incident.

It is a framework rather than a product, and that distinction is where adoptions fail. Running Backstage means running an application — deploying it, upgrading it, writing plugins, and keeping the catalogue accurate. A portal whose data is six months stale is worse than no portal, because people trust it briefly and then stop.

## What an assigned team does with Backstage.

Catalogue accuracy is the entire value, and it decays by default. Services get created, ownership changes, teams reorganise, and unless registration is part of how a service is created, the catalogue drifts immediately.

Making it self-maintaining through scaffolding rather than policing it manually is the design decision that determines whether it survives. That kind of long-horizon platform work is assigned as a [committed monthly capacity](https://azendo.co/pricing/).

## What we use Backstage for.

* Ownership answerable during an incident Who owns a service, available without asking three people at 3am.
* New services correct from creation Scaffolding templates that register the service and set up its baseline automatically.
* Documentation beside the code Docs-as-code surfaced in the portal, so they are updated in the same pull request.

## How Backstage capacity is assigned.

Developer portal work is assigned under [devops managed services](https://azendo.co/services/cloud-and-devops/), with catalogue accuracy designed in rather than maintained by reminder.

## Roles we assign Backstage for

* [Platform Engineer Cloud and DevOps](https://azendo.co/services/cloud-and-devops/platform-engineer/)

## Service lines it sits in

* [Cloud and DevOps](https://azendo.co/services/cloud-and-devops/)

Capacity is agreed as a committed monthly capacity across a discipline, not per skill.

## Related in cloud and infrastructure

* [Kubernetes — skill we assign for](https://azendo.co/skills/kubernetes/)
* [Docker — skill we assign for](https://azendo.co/skills/docker/)
* [Terraform — skill we assign for](https://azendo.co/skills/terraform/)
* [AWS — skill we assign for](https://azendo.co/skills/aws/)
* [Azure — skill we assign for](https://azendo.co/skills/azure/)
* [GCP — skill we assign for](https://azendo.co/skills/gcp/)
* [Terraform modules — skill we assign for](https://azendo.co/skills/terraform-modules/)
* [Pulumi — skill we assign for](https://azendo.co/skills/pulumi/)

## Tell us what your roadmap needs Backstage for.

A service delivery manager replies with the disciplines we would assign, the monthly capacity and what the first month looks like.

[All skills we assign for](https://azendo.co/skills/)