Backstage

Overview

Backstage is an open-source framework for building developer portals. A Backstage deployment can combine a software catalog, technical documentation, templates, search, and plugins in one web interface. In this pattern, Backstage is a protected HTTP upstream.

A developer portal can expose internal service metadata and links to operational tools. It can also connect to systems that create or change software. Teams should control who can reach the portal and keep detailed action permissions inside Backstage.

Pomerium can control access to the Backstage web application and pass verified identity context. It does not synchronize the Backstage Software Catalog, install plugins, or replace Backstage permissions.

How it works

Run Backstage on a private upstream address. Create a Pomerium HTTPS route whose to value points to that Backstage service. Attach an identity-aware policy to the route.

Pomerium authenticates the user and evaluates the route policy before it forwards the HTTP request. Backstage still owns its internal permission model for catalog changes, templates, and plugin operations.

If Backstage consumes identity from Pomerium, make the upstream verify the signed Pomerium JWT before it trusts the claims.

Example

A platform team runs Backstage inside a Kubernetes cluster. The public route points to a private Backstage Service. A Pomerium policy permits the engineering group to reach the route. Backstage then applies its own permission rules when a user edits catalog data or runs a software template.

Considerations

• There is no named Pomerium Backstage connector or plugin.
• A Pomerium route does not replace Backstage authentication or granular permission rules.
• The upstream must not trust unsigned claim headers.
• Backstage plugins can add their own route and network requirements.