Backstage & IDP Vocabulary

Registration in Backstage means adding a catalog-info.yaml file to a repository and letting Backstage's catalog ingestion discover it. Once indexed, the component appears in the software catalog with its owner, lifecycle stage, dependencies, and documentation link. It has nothing to do with deployment or permissions.

kind: Component is the correct entity type for a deployable unit like a microservice, frontend app, or library. kind: API describes the API contract itself (OpenAPI, gRPC). kind: System groups multiple components into a logical system. kind: Resource describes infrastructure (databases, S3 buckets). Getting these kinds right is essential for accurate catalog modelling.

Software templates (previously called the Scaffolder) are a core Backstage feature. They encode platform team best practices into self-service forms. A developer picks a template (e.g., "New Node.js microservice"), fills in name/owner/team, and Backstage automates everything downstream. This is how IDPs reduce "day zero" friction.

TechDocs implements the docs-as-code philosophy: Markdown files (using MkDocs) live next to the service code in the same repository. Backstage builds and serves them as a unified documentation site. When you open a catalog component, you see its docs tab alongside the API, dependencies, and CI status — everything in one place.

spec.owner defines the team or individual responsible for the component — typically a reference to a kind: Group entity (e.g., team-payments). This is the field that answers "who do I contact if this service is down?" and drives accountability. spec.lifecycle describes the stage (production, experimental, deprecated). spec.type describes what kind of component it is (service, library, website).