creating-backstage-extension-blueprint

Creating a Frontend Extension Blueprint

When to use this skill

You're authoring a frontend plugin and want to give other plugins or modules a typed, structured way to contribute UI to it. Think:

• A dashboards plugin that wants modules to register custom dashboard panels
• A code-quality plugin that wants modules to register additional checks shown on a results page
• A reusable "feature flag" plugin where modules contribute UI controls per flag

This is the same pattern Backstage itself uses for PageBlueprint, EntityCardBlueprint, EntityContentBlueprint, FormFieldBlueprint, ApiBlueprint. You're creating a new one of those for your plugin.

Don't create a blueprint when:

• A built-in blueprint already covers the case (use EntityCardBlueprint for catalog-page cards, FormFieldBlueprint for scaffolder fields, etc.)
• Your extension point only fires once and only your plugin will ever populate it — just write a regular extension and skip the blueprint indirection
• You're in a backend plugin — backend uses extension points (createExtensionPoint), not blueprints. See using-backstage-backend-system/references/extension-points.md

What you build

A blueprint comes in two coupled pieces:

1. The blueprint itself (createExtensionBlueprint) — the typed factory other plugins call as MyBlueprint.make({ name, params }) to contribute a single instance.
2. A parent extension that declares an input and renders or uses everything attached to it. This is usually a PageBlueprint extension you define in your plugin's extensions.tsx.

Both pieces are required and must agree on the input name and the data refs the contributions emit. Most plugins author both in the same extensions.tsx (or a colocated module).

Choose the right pattern

Building...	Reference
The blueprint itself (createExtensionBlueprint definition)	references/defining-the-blueprint.md
The parent extension that collects contributions via inputs	references/parent-collecting-extensions.md