Think of Backstage as the backstage of a concert, but instead of musicians and sound engineers, it hosts the myriad tools developers need on a daily basis. Spotify built it to simplify managing services, documentation, infrastructure, and operational tools. Imagine walking into a backstage area where everything, costumes, soundboards, and lighting, is laid out logically and accessible. Similarly, Backstage surfaces everything developers need: the software catalog, scaffolding templates via Scaffolder, documentation, and a universe of plugins, all unified within a single UX.
Unlike traditional toolchains scattered across repositories, dashboards, wikis, and ticketing systems, Backstage consolidates those into one portal. It functions like a control center for everything developers interact with: service metadata, API docs, workflows, monitoring links, and IaC templates, sort of like a one-stop radio station dial to tune into every part of your operation.
Backstage also leans on a strong open-source foundation. Donated to the Cloud Native Computing Foundation (CNCF) after Spotify open-sourced it, it benefits from a thriving ecosystem and shared governance. This ensures plugins and integrations remain healthy and extensible beyond Spotify’s internal use. It’s not just a consumer product; it’s a developer platform for developers, offering deep customization and extensibility for platform engineering teams.
Teams adopt Backstage not just to document services but to cut down the flood of support tickets. Self-service templates allow developers to spin up infrastructure without waiting for approvals, like giving them a key to the tool shed instead of asking for permission each time.
This keeps developers in one portal while ensuring governance, as IaC templates enforce compliance and security. Standardized modules, Terraform, Helm, or others, act like recipe cards, ensuring consistent deployments across teams and clouds.
Modern needs go beyond generating templates. Teams expect orchestration, monitoring, drift detection, and remediation, all from within Backstage. With AI entering the picture, platforms like StackGen hint at what’s next. Gartner® projects 15% of infrastructure tasks will be semi-autonomously managed by AI by 2028, up from nearly zero in 2024 (PR Newswire), underscoring the move toward AI-driven infrastructure operations.
Infrastructure-as-Code (IaC) is the backbone of modern infrastructure management, but not every team approaches it the same way. Some teams want plugins that can generate Terraform configurations directly from Backstage service metadata, as StackGen does. This approach feels like having a chef prep the ingredients before the cook even steps into the kitchen, accelerating the start of the provisioning process.
Others focus more on orchestration, operating existing stacks, running deployments, or managing state in tools like Pulumi, Spacelift, or env0. This is closer to managing a production line where the recipe is already written; the priority becomes running, updating, and maintaining consistency across environments. A plugin’s value lies in whether it can bridge both worlds, generation for rapid service creation and orchestration for ongoing lifecycle operations.
Backstage’s Scaffolder is the secret ingredient that transforms static templates into developer-ready services. The best infra plugins don’t just run in isolation; they integrate tightly with Scaffolder actions to provision, update, or scale infrastructure directly from the portal. Think of it as turning a simple template generator into a launchpad that deploys resources in real time.
Pulumi, for instance, uses actions like pulumi:new to scaffold projects and pulumi:up to deploy infrastructure. Similarly, env0 provides ready-to-use templates that spin up resources while applying organizational policies. The difference is subtle but crucial; without native Scaffolder integration, Backstage becomes a catalog of shortcuts rather than a true self-service platform.
Modern teams rarely work in a single environment. One project might run workloads on AWS while another needs Azure AD for identity and GCP for data analytics. A Backstage infra plugin that only covers one cloud quickly becomes a bottleneck. The strongest plugins support multi-cloud environments natively, ensuring Terraform, Pulumi, or Crossplane artifacts can be provisioned seamlessly across providers.
Cloud-native support is equally critical. It’s not enough to deploy VM instances; teams need plugins capable of handling Kubernetes manifests, Crossplane-backed claims, Helm charts, and Terraform state visualization. This mirrors the complexity of managing a city; roads, power grids, and water systems must all connect, regardless of the district they serve.
If you’ve ever wished your Backstage portal could generate infrastructure automatically instead of merely cataloging it, StackGen delivers exactly that. It converts your Backstage service metadata into deployment-ready Terraform, not generic boilerplate but Terraform that’s aligned with your organization’s templates, policies, and naming conventions.
Think of StackGen as an AI-powered chef working in your developer kitchen. You tell it what dish you want (via Backstage catalog metadata), and it prepares a perfectly plated recipe, your infrastructure, while following your kitchen’s rules, ingredient sourcing, and plating style.
StackGen supports multi-cloud mapping across AWS, Azure, and GCP, enabling teams to seamlessly define resources at an abstract level in Backstage while letting StackGen choose the appropriate equivalent in your preferred cloud provider.
Traditional IaC workflows start with writing Terraform from scratch, but StackGen flips the process: it uses Backstage metadata as the source of truth and generates infrastructure definitions automatically.
For example, when you catalog a PaymentService with a Postgres database in Backstage, StackGen ingests this metadata and outputs a ready-to-deploy appStack containing:
All generated Terraform follows your organization’s patterns, tagging rules, and compliance constraints.
StackGen abstracts your Backstage components into logical resource types and lets you map them to specific resources per cloud provider.
For example:
These mappings are configurable inside the StackGen Mappings UI. If your naming, tagging, or resource choices change, you can update mappings without refactoring Terraform manually.
3. Latest Momentum
In 2025, StackGen accelerated after being acquired by OpsVerse, which added two big capabilities:
Step 1: Prepare Backstage and private registry access
Start in a working Backstage app. You’ll add StackGen’s frontend and backend packages from a private registry scope, so wire your Yarn configuration first. In the repo root, update .yarnrc.yml so the stackgenhq scope resolves and authenticates against the vendor-hosted feed. Keep the token in your secret store, don’t commit it.
|
# .yarnrc.yml |
This scope enables you to yarn add the plugin packages the same way you would any internal/private module. If your security posture requires mirroring private packages into an internal registry, point npmRegistryServer at that mirror and keep ${REGISTRY_AUTH_TOKEN} limited to CI. The official StackGen plugin guide shows this exact setup and is a good reference if your environment has custom Yarn policies.
With the scope in place, install both halves of the plugin:
|
yarn --cwd packages/app add @stackgenhq/backstage-plugin-stackgen |
That brings a routable page into the Backstage UI and a backend module that talks to the StackGen adapter during “Sync.” The adapter handles auth, fetches mappings, and returns the appStack and Terraform artifacts.
Step 2: Configure the backend (secure API + plugin init)
Give your Backstage backend a way to reach the StackGen adapter. Add the following to your app-config.yaml (or app-config.local.yaml while testing), sourcing secrets from your vault or environment only, never from the repo. The keys and structure below match the StackGen docs.
|
# app-config.yaml |
Now register the backend plugin. If you’re on the new Backstage backend system, your entry point resembles this:
|
// packages/backend/src/index.ts |
Boot the backend locally and watch the logs; you should see the module come up cleanly. If you’re still on the legacy backend pattern.
Step 3: Add the StackGen page and navigation
Create a route so platform and service teams have a clear entry point. In
|
packages/app/src/App.tsx: |
Expose that route in your sidebar, e.g., Root.tsx:
|
import CloudIcon from '@mui/icons-material/Cloud'; |
You now have a first-class “StackGen” link in your Backstage UI (see the first and fourth screenshots above for typical catalog and homepage views). This is where teams will click Sync to turn catalog intent into Terraform.
Step 4: Model a tiny system in the catalog
Before you click Sync, describe something real in the Software Catalog, say an orders system with an API component and a database resource. Backstage’s catalog entities and relations are the “source of intent” that StackGen will read. You can register components using the “Register existing component” flow or by pushing catalog-info.yaml to source control. The catalog entity model and relation types are documented by the Backstage team and Roadie; copy their patterns and you’re set
|
# catalog-info.yaml (orders-api) |
Once registered, you’ll see the entities listed in the catalog. If you prefer templates, the Backstage Software Templates feature will also auto-register items as they’re created.
Open the StackGen page you added and go to Mappings → New. This is where you codify how abstract catalog types become concrete cloud resources. For example, map service to aws_ecs_service or google_cloud_run_service, and map database to aws_rds_instance or google_sql_database_instance.
Step 6: Click Sync to generate an appStack from catalog intent
Navigate back to the Systems view within the StackGen page, select your orders system, and click Sync. StackGen will read the catalog relationships, apply your mapping, and produce an appStack, a topology for VPC, subnets, security groups, compute, and database, assembled from your policies. The Backstage-side flow (Systems → Sync → Create appStack) is described in StackGen’s Backstage user guide.
At this point, you’re not writing Terraform from scratch; you’re authoring intent. Think of Backstage as your mise en place and StackGen as the chef who plates a full meal from those labeled bowls. The advantage is consistency: every stack carries the same tags, encryption defaults, and IAM posture without developers having to memorize them.
When the appStack renders, skim the summary in the UI. You’ll see the components it inferred and the resources each will become under your chosen cloud provider. If you need to switch to another provider for a specific region, change the cloud and re-sync; the topology is regenerated against that provider’s resources using the same abstract model.
From the same UI, export the generated Terraform bundle. A typical scaffold looks like this:
|
infra/ |
Commit it to your infra repo and let your pipeline run. A minimal GitHub Actions workflow is shown below as a reference; swap in Terraform Cloud, Spacelift, or env0 if that’s your standard. The point is that the input, not only the apply step, comes from a single source of truth: the catalog plus mappings.
|
name: apply-infra |
Backstage’s catalog docs and demos reflect exactly where developers spend time: browsing entities and clicking into plugin pages. By exporting Terraform from StackGen rather than hand-authoring it, you’re shifting repetitive authoring into a repeatable generation step.
Step 8: What success looks like after a week
By the end of your first sprint, teams will register services in the catalog, click Sync on the StackGen page, and open PRs with standardized Terraform. Platform engineers review mappings and policies centrally rather than line-by-line in code. Your catalog remains the single UX for discovering, generating, and operating infrastructure, exactly the role Backstage was designed to play.
StackGen operates as a vendor platform with enterprise licensing. Contact StackGen for pricing details.
Pulumi’s official Backstage plugin surfaces stack activity inside your portal and adds Scaffolder actions so teams can generate and update Pulumi projects directly from Backstage. You get an in-portal “Pulumi” view for entity activity, plus pulumi:new and pulumi:up actions usable in templates.
Pulumi tab renders stack details/activity for catalog entities, and the Scaffolder actions let you create a new Pulumi project and trigger deployments from a template-driven flow, great for self-service infra that stays within Backstage.
Step 1: Install the UI plugin and Scaffolder backend module
|
# Frontend (entity tab/card) |
|
// packages/backend/src/plugins/scaffolder.ts (or your scaffolder router file) |
Export a Pulumi access token for the backend (use your secret store in real setups):
|
export PULUMI_ACCESS_TOKEN="<org-scoped-token>" |
The actions require a Pulumi token; the official README documents pulumi:new and pulumi:up inputs and Pulumi Deployments support.
Step 3: Add the Pulumi tab/card to your Entity page
|
// packages/app/src/components/catalog/EntityPage.tsx |
This renders a Pulumi tab and cards on your entity pages.
Step 4: Annotate/catalog or ingest stacks
Add Pulumi annotations so the plugin can resolve org/project/stack for an entity:
|
# Example entity annotations |
If you prefer ingestion, you can configure the Pulumi catalog provider to pull stacks into Backstage on a schedule.
Step 5: Minimal Scaffolder template using pulumi:new + pulumi:up
|
apiVersion: scaffolder.backstage.io/v1beta3 |
This is the leanest working example: generate a project, then update the stack. Inputs/variants are listed in the plugin README.
Step 6: Run it from Create and inspect resul
Excellent Scaffolder integration; straightforward developer UX anchored in Backstage’s Create flow.
Purpose-built for Pulumi; not an orchestration layer for mixed Terraform/OpenTofu stacks.
Plugin is open source; advanced features live behind Pulumi Cloud tiers if you adopt managed deployments/enterprise capabilities.
Spacelift’s Backstage integration lets you list stacks and trigger runs from inside your portal, great when you already manage Terraform/OpenTofu/Pulumi with Spacelift and want in-portal orchestration. The official docs cover capabilities (stack list, rerun) and the exact install/config sequence we use below.
Stack list and status directly in Backstage, plus the ability to trigger or re-run eligible stacks without leaving your portal.
Step 0: Create a Spacelift Integration Key (one time)
In Spacelift, go to Integrations → Backstage → Set up integration, choose the Space scope, and create the key. This generates API Key and API Secret (short-lived tokens issued from this admin integration key). Keep them in your secret store; we’ll wire them to Backstage next.
Step 1: Install the Frontend & Backend plugins
From your Backstage repo root (monorepo layout assumed):
|
yarn --cwd packages/backend add @spacelift-io/backstage-integration-backend |
These are Spacelift’s official packages for Backstage; they’re compatible with Backstage ≥1.17 (check their README for older versions).
Step 2: Configure app-config.yaml with host & credentials
Provide your Spacelift instance URL and the key pair from Step 0:
|
spacelift: |
Use a proper secrets mechanism for production; app-config.local.yaml is fine for local dev.
Step 3: Wire the plugin into your app (frontend + backend)
Register the backend plugin in your Backstage backend (new backend system example):
|
// packages/backend/src/index.ts |
Add a route/page on the frontend so users can open Spacelift inside Backstage, e.g. expose a “Spacelift” page in your app routes and sidebar (exported component name per the frontend README). Once registered, you’ll see a Stacks view sourced from your Spacelift Space.
Open the Spacelift page you wired up. You should see a stacks list with current status for each stack that the integration key’s Space can access. If nothing appears, verify the Space scope on the Integration Key and that your config vars are set.
Step 5: Trigger or re-run IaC jobs from Backstage
(This shows the Spacelift dashboard tiles you’ll recognize when drilling into runs/health from Backstage.)
Step 6: Secure the surface (recommended)
The plugin uses the Integration Key permissions; configure Backstage routing/permissions so only the right personas can view/trigger runs. Spacelift’s docs explicitly call out the security model and best practices for limiting Space scope.
Designed for IaC orchestration at scale with a clean stacks list and in-portal run triggers; integrates neatly when your infra standard is Terraform/OpenTofu/Pulumi via Spacelift.
Operates existing stacks; does not generate IaC from metadata. Pair it with a generator (e.g., templates or another plugin) if you need source-of-truth → stack synthesis.
Commercial Spacelift subscription tiers; the Backstage integration itself follows the product’s licensing.
The env0 Backstage plugin brings self-service Infrastructure as Code (IaC) with governance directly into your Backstage portal. Administrators can expose approved env0 templates, and developers can launch environments through Backstage’s Create flow and monitor or redeploy them from entity pages. Control and auditing remain within env0 while simplifying the user experience within Backstage.
The plugin allows you to expose curated env0 templates in Backstage’s Create flow and deploy, monitor, and redeploy environments directly from the entity view. This bridges the gap between self-service IaC and centralized governance.
Step 1 : Install the UI Plugin and Scaffolder Backend Module
|
# Frontend (entity tab/cards + field extensions) |
Step 2: Configure Backstage to talk to env0 (proxy + token)
Add a proxy entry and env0 access token to app-config.yaml so the plugin can call the env0 API:
|
proxy: |
Use a secrets store for ENV0_ACCESS_TOKEN.
// packages/app/src/components/catalog/EntityPage.tsx
|
import { |
This surfaces deployment history, status, and redeploy controls on the entity. (You’ll typically reach this after creating or registering entities, see Image 4 for a representative Catalog view.)
Step 4: Register env0 field extensions in the Create page
|
// packages/app/src/App.tsx (within your <Route path="/create" ...>) |
Step 5: Minimal Scaffolder Template to spin up an env0 environment
This template asks for a template + project, gathers variables, and then calls the env0 create action:
|
apiVersion: scaffolder.backstage.io/v1beta3 |
Action env0:environment:create takes name, projectId, templateId, and optional variables; env0:environment:redeploy is also available for follow-up runs.
Step 6: Run from Create and monitor from the entity
Open Create → pick Deploy env0 Environment → select a Template and Project, add Variables, run. The workflow creates the environment in env0 and returns a link. Head to your entity’s env0 tab to see status, deployment history, and redeploy actions inline.
Fast path to Terraform/OpenTofu/Pulumi self-service with guardrails; templates remain curated by platform admins, developers operate from Backstage.
You’re working inside env0 workflows; it doesn’t generate IaC from Backstage metadata, pair it with templates or another generator if you need that upstream.
Commercial env0 subscription tiers; Backstage integration follows the platform’s licensing.
The Firefly Backstage plugin integrates cloud asset inventory and IaC (Infrastructure as Code) coverage/drift visibility directly into your Backstage portal. It includes a frontend that provides an entity-level IaC coverage card and a dedicated Firefly page, and a backend that imports Firefly assets, establishes relationships, and allows seamless browsing of cloud resources within Backstage systems. This integration helps platform teams quickly identify unmanaged resources and gradually bring them under IaC management.
Inside Backstage, the plugin displays resource inventory aligned with catalog entities and provides a coverage/drift snapshot showing what is managed under Terraform and where drift exists. It enables seamless browsing between Backstage systems and associated cloud resources and allows platform engineers to prioritize unmanaged resources and bring them under Terraform over time.
Step 1: Install the Frontend and Backend Plugins
|
# Frontend UI (Firefly page + entity cards) |
Step 2: Provide credentials & basic config
Export a Firefly access/secret pair for local dev (use your secret store in real deployments), then add minimal config:
|
export FIREFLY_ACCESS_KEY="<your-access-key>" |
# app-config.yaml
|
firefly: |
The docs show these exact env vars and note where to place them.
Step 3: Register the backend plugin
|
// packages/backend/src/index.ts (new backend system example) |
Step 4: Add the Firefly page and entity card
|
import { FireflyPage } from '@fireflyai/backstage-plugin-firefly'; |
In packages/app/src/components/catalog/EntityPage.tsx, add the IaC coverage card:
|
import { EntityDependenciesIaCCoverageCard } from '@fireflyai/backstage-plugin-firefly'; |
Optionally, add a sidebar link:
|
<SidebarItem to="/firefly" text="Firefly" /> |
Step 5: Import assets & verify entity relationships
With the backend plugin enabled, Firefly can import cloud accounts as systems and assets as resource entities, stitching relations so you can click from a Backstage system to its cloud resources. Head to the Firefly page in Backstage and confirm that resources populate and the coverage card renders under your target entity. (Image shows the catalog list view you’ll traverse.)
Developers can open an entity, glance at coverage/drift, and pick off unmanaged resources to codify in Terraform. Over time, the coverage ring should fill as more assets are represented in code. (Image evokes the code-to-cloud loop you’re closing; Firefly academy content and blog posts walk through inventory, coverage, and drift concepts.)
Available via Firefly subscription tiers; the Backstage plugin follows the platform’s licensing.
|
Tool |
Key Focus |
Stand-out Strength |
Best For |
|
StackGen |
IaC generation + governance + AI |
Turns Backstage metadata into compliant Terraform |
Enterprises needing self-service IaC |
|
Pulumi |
Scaffolder-driven IaC |
Native actions + stack views |
Pulumi-first infra teams |
|
Spacelift |
IaC orchestration |
Full-stack orchestration inside Backstage |
Terraform/OpenTofu/Pulumi power users |
|
env0 |
Governed self-service IaC |
Templates for provisioning + governance |
Terraform standardization projects |
|
Firefly |
Cloud asset & drift |
Asset inventory + drift detection |
FinOps + cloud visibility teams |
Most Backstage plugins operate IaC (list stacks, run jobs, show status) but don’t generate it from service intent, so teams still hand-craft or maintain templates. To cover the whole lifecycle, you usually combine tools, generation (or templates), orchestration (Spacelift/env0/Pulumi), and visibility/drift (Firefly), which adds seams for auth, RBAC, and policy. Even with automation, drift and guardrails need ongoing tuning, and multi-cloud parity still demands curated modules and policies.
StackGen starts from Backstage metadata and synthesizes compliant Terraform automatically, baking in naming, tagging, and security at generation time. Its mappings keep one domain vocabulary while targeting AWS/Azure/GCP, and its agent suite adds governance, drift alignment, incident assist, and optimization around the same pipeline. Paired with your preferred orchestrator and visibility layers, it turns the IDP into a portal that produces standardized infrastructure, not just a place to run it.
Backstage has shifted from being a simple service catalog to a central interface where infrastructure creation, orchestration, and governance converge. Plugins drive this evolution by embedding IaC workflows, compliance policies, and now AI-driven automation directly into the portal. Choosing the right plugin means more than checking a feature list; it defines how efficiently your teams move from service definition to production-ready infrastructure.
StackGen, Pulumi, Spacelift, and env0 represent different points along this spectrum. Some excel at orchestration, others at generation, and some aim to unify both while layering intelligence on top. The future points toward self-healing infrastructure portals where provisioning, drift remediation, and compliance are handled as part of a continuous lifecycle rather than isolated steps.
As AI capabilities mature, the Backstage ecosystem will likely see even deeper integrations, plugins that not only generate infrastructure but also optimize and secure it in real time. Teams evaluating their options today should pick a plugin that not only meets current needs but also leaves room for these next-generation workflows.
The official Backstage Terraform and Kubernetes plugins are good entry points for teams exploring basic IaC integration. They provide catalog awareness and scaffolding without heavy setup, making them ideal for early-stage adoption.
For smaller teams, Pulumi or env0 are often easier to start with because of their managed services and prebuilt Backstage actions. They reduce operational overhead while still supporting production-grade deployments.
Yes. Many teams run Backstage with Terraform, Kubernetes, and an orchestration tool like Spacelift or env0 side by side. Combining plugins allows you to handle generation, deployment, and drift management under one portal while maintaining specialized workflows where necessary.
StackGen emphasizes end-to-end automation: generating blueprints from service metadata, mapping abstract infrastructure vocabularies to cloud providers, and embedding AI for drift remediation and compliance. Pulumi, Spacelift, and env0 excel at orchestration and state management but rely on prewritten modules rather than generating new ones from catalog metadata.