Summary and recommendation
Backstage user management can be run manually, but complexity usually increases with role models, licensing gates, and offboarding dependencies. This guide gives the exact mechanics and where automation has the biggest impact.
Backstage is an open-source developer portal with no native SCIM support and no built-in admin UI for user management.
Users exist as catalog entities, not as accounts managed through a traditional identity screen.
Every app that connects to Backstage inherits whatever access posture the deployed permission policy enforces - and by default, that policy enforces nothing.
Commercial managed options (Spotify Portal, Roadie) exist but carry undisclosed pricing;
all seat and billing terms must be obtained directly from those vendors.
The open-source self-hosted path is $0 in licensing but carries real engineering overhead.
Quick facts
| Admin console path | Settings / Administration > Users and Roles (exact labels vary by tenant) |
| SCIM available | No |
| SCIM tier required | Open Source |
| SSO prerequisite | No |
User types and roles
| Role | Permissions | Cannot do | Plan required | Seat cost | Watch out for |
|---|---|---|---|---|---|
| User (catalog entity) | Can sign in and access Backstage features as permitted by the deployed permission policy. Can own catalog entities, appear in team/group membership. | Cannot modify permission policies or catalog ingestion configuration without code-level access to the Backstage deployment. | N/A – open source, self-hosted | $0 (self-hosted); varies for managed offerings (Spotify Portal, Roadie) | Users are not created via an admin UI. They are ingested as catalog entities from external sources (e.g., GitHub org, LDAP, custom YAML) or auto-provisioned on first sign-in via sign-in resolvers. There is no built-in user management screen in the default Backstage installation. |
| Admin / Operator | Defined entirely by the custom permission policy implemented in code. By default, Backstage ships with no permission enforcement; all authenticated users have full access until a policy is written and deployed. | There is no built-in 'admin' role with a fixed permission set. Admin-level access must be explicitly coded into the permission policy. | N/A – open source, self-hosted | $0 (self-hosted) | Without a custom permission policy, every authenticated user effectively has admin-level read/write access to the catalog and plugins. |
Permission model
- Model type: custom-roles
- Description: Backstage uses a code-defined permission framework. Adopters write a permission policy (a TypeScript class implementing the PermissionPolicy interface) that evaluates each request and returns ALLOW or DENY. There are no built-in roles or role assignments in the UI. Role membership is typically derived from catalog Group entities or claims from the identity provider. The framework supports both role-based and attribute-based patterns depending on how the policy is authored.
- Custom roles: Yes
- Custom roles plan: N/A – available in open source; requires engineering effort to implement
- Granularity: Per-permission resource type and action (e.g., catalog.entity.read, catalog.entity.delete, scaffolder.task.create). Granularity depends on what each plugin exposes as permission resources.
How to add users
- Users are not added through an admin UI. Choose an ingestion method: (1) define User entities in YAML files registered with the catalog, (2) configure an organizational data provider such as the GitHub Org processor, Microsoft Graph processor, or LDAP processor to sync users automatically, or (3) rely on the sign-in resolver to auto-create a User entity on first login.
- If using YAML: create a file with 'kind: User' entities and register the location in app-config.yaml under catalog.locations.
- If using an org provider (e.g., GitHub): configure the GitHubOrgEntityProvider in app-config.yaml with the org name and credentials; users sync on schedule.
- If using sign-in resolvers: configure the resolver in the auth backend to map the IdP identity to an existing catalog User entity or create one dynamically.
- Deploy or restart the Backstage backend for configuration changes to take effect.
Required fields: metadata.name (unique identifier for the User entity), spec.profile.email (recommended for sign-in resolver matching), apiVersion: backstage.io/v1alpha1, kind: User
Watch out for:
- There is no 'invite user' flow or email invitation system in default Backstage.
- Users must exist as catalog User entities for ownership and team membership features to work correctly; sign-in alone does not guarantee a catalog entity exists.
- Auto-provisioned users created by sign-in resolvers may not have full profile data unless the resolver populates it from the IdP token.
- Org provider sync is scheduled (not real-time); newly added org members may not appear until the next sync cycle.
| Bulk option | Availability | Notes |
|---|---|---|
| CSV import | No | Not documented |
| Domain whitelisting | No | Automatic domain-based user add |
| IdP provisioning | Yes | N/A – available in open source via org entity providers and sign-in resolvers |
How to remove or deactivate users
- Can delete users: Yes
- Delete/deactivate behavior: User entities in the Backstage catalog can be deleted by removing them from their source (e.g., removing the YAML definition, removing the user from the synced GitHub org). The catalog will mark orphaned entities and eventually remove them based on the orphan strategy configured (default: keep, but can be set to delete). There is no separate 'deactivate' concept in the default Backstage catalog; access is controlled by whether the user can authenticate via the configured auth provider, not by a catalog entity status flag.
- To revoke access: remove or disable the user's account in the upstream identity provider (e.g., Okta, GitHub, Google Workspace) so they can no longer authenticate.
- To remove the User entity from the catalog: delete the entity's YAML definition from the registered location, or remove the user from the synced org/directory source.
- If using the catalog orphan deletion strategy set to 'delete', the entity will be removed automatically on the next processing cycle after the source record is gone.
- If the orphan strategy is 'keep' (default), manually delete the entity via the Backstage catalog API (DELETE /api/catalog/entities/by-uid/{uid}) or via the catalog UI's entity page if the plugin exposes a delete action.
| Data impact | Behavior |
|---|---|
| Owned records | Catalog entities owned by the deleted User entity will have a dangling ownership reference. Ownership is stored as a string reference; existing entities are not automatically re-assigned. |
| Shared content | No built-in shared content model in default Backstage; impact depends on plugins installed. |
| Integrations | No automatic revocation of plugin-level tokens or integrations tied to the user; these must be managed in the upstream systems. |
| License freed | N/A for open source self-hosted. For managed offerings (Spotify Portal, Roadie), consult the vendor's billing documentation. |
Watch out for:
- Revoking catalog entity access does not revoke IdP authentication; the IdP account must be disabled separately.
- Orphaned ownership references on catalog entities are not cleaned up automatically unless a custom processor or policy handles re-assignment.
- The default orphan strategy is 'keep', meaning deleted source records leave ghost User entities in the catalog until manually removed.
License and seat management
| Seat type | Includes | Cost |
|---|---|---|
| Open source self-hosted | All Backstage features available in the open source repository; no seat limits. | $0 (infrastructure costs borne by the adopter) |
| Spotify Portal (managed) | Managed Backstage hosted by Spotify; pricing and seat model not publicly documented. | Custom – contact Spotify |
| Roadie (hosted Backstage) | Managed Backstage hosted by Roadie; pricing and seat model not publicly documented. | Custom – contact Roadie |
- Where to check usage: Settings / Administration > Users and Roles
- How to identify unused seats: No built-in usage analytics or last-login tracking in default Backstage. Adopters must instrument their own analytics plugin or query auth provider logs to identify inactive users.
- Billing notes: Backstage itself is open source with no licensing fees. Seat-based billing applies only to commercial managed offerings (Spotify Portal, Roadie) and is not publicly documented; terms must be obtained directly from those vendors.
The cost of manual management
Because Backstage has no invite flow, no deactivation toggle, and no last-login tracking out of the box, every provisioning and deprovisioning action requires either a code change, a config change, or a manual catalog API call.
Org provider syncs run on a schedule - not in real time - so newly onboarded or offboarded employees may remain out of sync until the next cycle runs.
The default orphan strategy retains deleted source records as ghost User entities in the catalog. Without a custom processor or a deliberate orphan-deletion policy, offboarding leaves stale entries that accumulate over time. Identifying inactive users requires instrumenting a separate analytics plugin or querying auth provider logs directly - neither is provided out of the box.
The decision
Backstage is the right choice for engineering organizations that want a self-hosted, fully extensible developer portal and have the platform engineering capacity to own the permission policy, catalog ingestion pipeline, and identity wiring. Every app and service in the catalog will reflect whatever ownership and access model the team builds and maintains.
It is a poor fit for teams expecting a turnkey identity management experience. If the requirement is a managed, low-maintenance portal with documented seat-based billing, evaluate Spotify Portal or Roadie - but request pricing directly, as neither publishes terms publicly.
Bottom line
Backstage gives platform teams complete control over how users are provisioned, permissioned, and removed, but that control comes entirely through code and configuration rather than through any UI.
Every app in the catalog is only as well-governed as the permission policy and ingestion pipeline the team has built and maintains. Teams without dedicated platform engineering capacity should weigh that operational cost carefully before committing to the self-hosted path.
Automate Backstage workflows without one-off scripts
Stitchflow builds and maintains end-to-end IT automation across your SaaS stack, including apps without APIs. Built for exactly how your company works, with human approvals where they matter.
