Skip to main content
In this lesson we’ll explore the additional Backstage entity kinds you can model beyond Components and Templates: Users, Groups, APIs, Systems, Domains, and Resources. Each of these entity kinds follows the same top-level YAML shape — apiVersion, kind, metadata, and spec — which makes them simple to author, relate, and automate. After reading this guide you’ll understand when to create each entity type and how they commonly reference one another.
A presentation slide titled "Exploring Other Entity Kinds" showing a central orange "Entity" hexagon surrounded by six blue hexagons labeled Users, Groups, Systems, Domains, Templates, and Resources, each with small icons. The layout uses a hexagonal radial design with gradient colors.
Summary table — What each entity type models Users A User entity models a person in the organization and typically holds display and contact information. Users can belong to zero or more Group entities via the memberOf list, and are often automatically synchronized from your identity provider instead of being created manually. Example User YAML:
Key points:
  • metadata.name is the unique entity identifier used in cross-references (e.g. group members).
  • spec.profile stores what is shown in UI cards (display name, email, picture).
  • Prefer syncing from your canonical identity source to reduce duplication and drift.
A schematic diagram titled "Entity – Users" showing a central user/stack icon fed by LDAP, Single Sign‑On, and an internal HR database. Below, a "Sync" step exports user records into YAML files (user1.yaml, user2.yaml).
If you use LDAP, SSO, GitHub organizations, or an HR system, configure a catalog processor or a sync integration so User and Group entities are imported automatically rather than edited by hand.
Groups A Group models an organizational unit such as a team, business unit, or cross-functional group. Use spec.members to list user entity names and use parent / children to represent hierarchical structure. Example Group YAML:
Best practices:
  • Keep spec.type small and consistent across the org (for example: team, business-unit, guild).
  • Prefer references to user metadata.name values instead of repeating personal info.
A slide titled "Entity – Groups" showing three colored team boxes (Auth Team, Content Team, Data Processing Team) each with a group icon, and nine individual user icons below grouped and labeled User 1 through User 9. The layout illustrates users assigned to the three teams.
APIs and Component relationships APIs are first-class entities in Backstage. Model APIs to represent formal interfaces and link them to Component entities to show which component provides or consumes an API. Typical relationship fields:
  • On a Component: spec.providesApis (list of API names)
  • On an API: spec.apiProvidedBy (the providing component)
Example Component and API YAML pair:
Notes:
  • spec.type on an API can be openapi, grpc, graphql, avro, etc.
  • The definition field points to the API specification (URL or embedded document).
A diagram titled "Entity – API" with a central API block on the left and dashed arrows branching to four boxes on the right labeled REST API, GRPC, GraphQL, and Avro. The graphic shows the API exposing multiple interface types.
Systems Use System entities to group components, resources, and internal APIs that together implement a logical product or service area. Systems help surface which public APIs belong to a logical unit while encapsulating internal components. Example System and Component association:
Key relationships:
  • Use spec.system on a Component to associate it with a System.
  • Use spec.system on a Resource as well to associate infra with the same system.
A slide showing a banking app mockup on the left linked to two backend components on the right labeled "Payment System" and "Account Management System." The title reads "Entity – Systems" with a simple real-world analogy diagram.
Domains Domain entities capture broader business or product areas that group multiple System entities. Domains reflect organizational ownership and help align systems to strategic responsibilities. Example Domain and System association:
Tips:
  • Use spec.subdomainOf for nested domains.
  • Domain ownership helps map support and governance responsibilities.
Resources Resource entities model infrastructure dependencies (databases, message topics, storage buckets, CDNs). Explicit resource modeling clarifies operational boundaries and supports impact analysis. Example Resource YAML:
Common uses:
  • Reference the Resource from components and systems to mark dependencies.
  • Use resource spec.type to categorize infra (e.g., database, s3-bucket, kafka-topic).
A slide titled "Entity – Resources" showing a diagram where a "Component" depends on a central "Resource" icon that branches to three resources labeled Database, Server, and S3 Bucket.
Quick cross-reference — common entity fields Wrapping up All Backstage entities use the same foundational YAML structure and connect through simple reference fields (memberOf, members, providesApis, apiProvidedBy, system, domain, spec.subdomainOf, etc.). Model entities to reflect your organizational structure and automate their creation and updates with catalog processors and sync integrations from your identity and infrastructure sources. Doing so reduces manual drift and keeps the catalog accurate and useful. That’s all for this lesson.

Watch Video