Top 5 Backstage Plugins for Infrastructure Automation (2025 Comparison)
1) StackGen Backstage Plugin – Turning Metadata into Infrastructure
Overview
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.
Key Features
1. Metadata-Driven IaC Generation
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:
- VPCs, subnets, and networking
- Compute instances or Kubernetes resources
- Managed database instances
- Security groups and IAM policies
All generated Terraform follows your organization’s patterns, tagging rules, and compliance constraints.
2. Cloud-Agnostic Mapping & Overrides
StackGen abstracts your Backstage components into logical resource types and lets you map them to specific resources per cloud provider.
For example:
- service → aws_ecs_service on AWS
- database → gcp_sql_database_instance on GCP
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:
- A DevOps Copilot (“Aiden”), integrated into the StackGen Backstage plugin for chat-based infra modeling.
- Built-in observability for the generated stacks, allowing teams to monitor infra health without leaving Backstage.
Hands-on Example
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
npmScopes:
stackgenhq:
npmRegistryServer: "https://npm.pkg.github.com"
npmAlwaysAuth: true
npmAuthToken: "${REGISTRY_AUTH_TOKEN}"
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
yarn --cwd packages/backend add @stackgenhq/backstage-plugin-stackgen-backend
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
stackGen:
baseUrl: ${STACKGEN_ADAPTER_URL}
apiToken: ${STACKGEN_PAT}
# Optionally restrict plugin usage to specific teams/workspaces
allowedTeams:
- 20f0e210-15ce-4d2c-9e29-0555bffee7bc
- 20f0e211-15ce-4d2c-9e29-0555bffee7bd
Now register the backend plugin. If you’re on the new Backstage backend system, your entry point resembles this:
// packages/backend/src/index.ts
import { createBackend } from '@backstage/backend-defaults';
import { stackGenPlugin } from '@stackgenhq/backstage-plugin-stackgen-backend';
const backend = createBackend();
backend.add(stackGenPlugin());
backend.start();
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:
import { StackGenPage } from '@stackgenhq/backstage-plugin-stackgen';
import { Route } from 'react-router-dom';
// within < FlatRoutes> ...
< Route path="/stackgen" element={< StackGenPage />} />
Expose that route in your sidebar, e.g., Root.tsx:
import CloudIcon from '@mui/icons-material/Cloud';
< SidebarItem icon={CloudIcon} to="/stackgen" text="StackGen" />
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
Here’s a minimal pair you can drop into a repo and register:
# catalog-info.yaml (orders-api)
apiVersion: backstage.io/v1alpha1
kind: Component
metadata:
name: orders-api
description: Orders service API
spec:
type: service
owner: team-orders
lifecycle: production
system: orders
---
# catalog-info.yaml (orders-db)
apiVersion: backstage.io/v1alpha1
kind: Resource
metadata:
name: orders-db
description: Primary database for Orders
spec:
type: database
owner: team-orders
system: orders
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.
Step 5: Create Mappings (abstract types → cloud resources)
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.
Treat mappings like your organization’s cookbook. Bake in naming conventions, mandatory tags, encryption defaults, and network baselines so every generated stack is born compliant. As your standards evolve, you’ll update the mapping once and re-sync services; no need to refactor dozens of hand-written Terraform modules.
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.
Step 7: Review and export Terraform, then hand off to CI/CD
From the same UI, export the generated Terraform bundle. A typical scaffold looks like this:
infra/
orders/
main.tf
variables.tf
outputs.tf
modules/
orders-service/
orders-db/
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
on:
pull_request:
paths: ["infra/orders/**"]
push:
branches: [main]
paths: ["infra/orders/**"]
jobs:
plan-apply:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: hashicorp/setup-terraform@v3
- run: terraform -chdir=infra/orders init
- run: terraform -chdir=infra/orders plan -out=tf.plan
- if: github.ref == 'refs/heads/main'
run: terraform -chdir=infra/orders apply -auto-approve tf.plan
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.
Pros
- Generates infrastructure, freeing developers from manual Terraform authoring.
- Governance and compliance embedded directly into the output for org-wide consistency.
- AI-powered agents reduce drift, incidents, and misconfigurations.
Cons
- Integration is request-based; you’ll need vendor provisioning before installing the plugin.
- Not a one-click OSS add-on from a public registry yet.
Pricing
StackGen operates as a vendor platform with enterprise licensing. Contact StackGen for pricing details.
2) Pulumi Backstage Plugin
Overview
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.
Key Features
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.
Hands-On
Step 1: Install the UI plugin and Scaffolder backend module
# Frontend (entity tab/card)
yarn --cwd packages/app add @pulumi/backstage-plugin-pulumi
# Backend (Scaffolder actions)
yarn --cwd packages/backend add @pulumi/backstage-scaffolder-backend-pulumi
Step 2: Wire the Scaffolder actions and set auth
// packages/backend/src/plugins/scaffolder.ts (or your scaffolder router file)
import { createRouter } from '@backstage/plugin-scaffolder-backend';
import { pulumiNewAction, pulumiUpAction } from '@pulumi/backstage-scaffolder-backend-pulumi';
const router = await createRouter({
// ... your deps ...
actions: [
pulumiNewAction(/* opts */),
pulumiUpAction(/* opts */),
],
});
export default router;
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
import {
isPulumiAvailable,
EntityPulumiCard,
EntityPulumiMetdataCard,
PulumiComponent,
} from '@pulumi/backstage-plugin-pulumi';
import { EntityLayout, EntitySwitch, Grid } from '@backstage/core-components';
const pulumiContent = (
< EntitySwitch>
< EntitySwitch.Case if={isPulumiAvailable}>
< PulumiComponent />
< /EntitySwitch.Case>
</EntitySwitch>
);
// Add a Pulumi route/tab for services:
< EntityLayout.Route path="/pulumi" title="Pulumi" if={isPulumiAvailable}>
{pulumiContent}
< /EntityLayout.Route>
// Optionally surface cards on overview/system pages:
< EntitySwitch.Case if={isPulumiAvailable}>
< Grid item md={6}> < EntityPulumiCard variant="gridItem" /> </Grid>
< /EntitySwitch.Case>
< EntitySwitch.Case if={isPulumiAvailable}>
< Grid item md={6}> < EntityPulumiMetdataCard /> </Grid>
< /EntitySwitch.Case>
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
metadata:
annotations:
pulumi.com/project-slug: org/myproj
# System level (optional)
spec:
owner: team-foo
---
# For system entity:
metadata:
annotations:
pulumi.com/orga-slug: org
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
kind: Template
metadata:
name: pulumi-quickstart
title: Pulumi Project + Up
spec:
owner: platform-team
type: service
parameters:
- title: Settings
required: [projectName, stackName, language]
properties:
projectName: { type: string }
stackName: { type: string }
language: { type: string, enum: [typescript, python, go, dotnet] }
steps:
- id: pulumi-new
name: Create Pulumi project
action: pulumi:new
input:
name: $
organization: your-org
stack: $
template: "typescript" # or a repo URL template
folder: ./infra/$
- id: pulumi-up
name: Deploy stack
action: pulumi:up
input:
name: $
organization: your-org
stack: $
workDir: ./infra/$
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 result
In Backstage, open Create, choose your Pulumi Project + Up template, supply parameters, and execute. After the run, open the entity and switch to the Pulumi tab to view stack details and recent activity. That tab pulls from Pulumi Cloud and shows updates for the entity’s stack(s).
Pros
Excellent Scaffolder integration; straightforward developer UX anchored in Backstage’s Create flow.
Cons
Purpose-built for Pulumi; not an orchestration layer for mixed Terraform/OpenTofu stacks.
Pricing
Plugin is open source; advanced features live behind Pulumi Cloud tiers if you adopt managed deployments/enterprise capabilities.
3) Spacelift Backstage Integration
Overview
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.
Key Features
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
yarn --cwd packages/app add @spacelift-io/backstage-integration-frontend
These are Spacelift’s official packages for Backstage; they’re compatible with Backstage ≥1.17 (check their READ ME 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:
hostUrl: '< your-subdomain>.app.spacelift.io' # no https://
apiKey: ${SPACELIFT_API_KEY}
apiSecret: ${SPACELIFT_API_SECRET}
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
import { createBackend } from '@backstage/backend-defaults';
import { spaceliftPlugin } from '@spacelift-io/backstage-integration-backend';
const backend = createBackend();
backend.add(spaceliftPlugin());
backend.start();
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.
(Shows the standard Backstage “register” UI, useful context if your team registers components alongside enabling the Spacelift page.)
Step 4: View stacks and statuses in Backstage
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.
(This shows a representative Spacelift stacks list; in Backstage you’ll see a similar stacks table exposed via the plugin.)
Step 5: Trigger or re-run IaC jobs from Backstage
From that list, choose a stack that allows re-runs and click the Re-run/Trigger control. The plugin calls Spacelift to start a run; you can then hop to the detailed run view in Spacelift if needed. This closes the loop for day-to-day orchestration without leaving the portal.
(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.
Pros
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.
Cons
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.
Pricing
Commercial Spacelift subscription tiers; the Backstage integration itself follows the product’s licensing.
4) env0 Backstage Plugin
Overview
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.
Key Features
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.
Hands-On Setup (Step-by-Step)
Step 1 : Install the UI Plugin and Scaffolder Backend Module
# Frontend (entity tab/cards + field extensions)
yarn --cwd packages/app add @env0/backstage-plugin-env0
# Backend (Scaffolder actions for env creation/redeploy)
yarn --cwd packages/backend add @env0/backstage-scaffolder-backend-env0
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:
'/env0':
target: 'https://api.env0.com'
changeOrigin: true
headers:
Authorization: Basic ${ENV0_ACCESS_TOKEN}
Accept: application/json
Content-Type: application/json
Use a secrets store for ENV0_ACCESS_TOKEN.
Step 3: Add env0 to your Entity page (tab + overview card)
// packages/app/src/components/catalog/EntityPage.tsx
import{
Env0TabComponent,
Env0EnvironmentDetailsCard,
isEnv0Available,
} from '@env0/backstage-plugin-env0';
import { EntityLayout, EntitySwitch, Grid } from '@backstage/core-components';
// Tab for env0 environments
< EntityLayout.Route if={isEnv0Available} path="/env0" title="env0">
< Env0TabComponent />
< /EntityLayout.Route>
// Optional details card on Overview
< EntitySwitch>
< EntitySwitch.Case if={isEnv0Available}>
Grid item md={6}> < Env0EnvironmentDetailsCard /> </Grid>
< /EntitySwitch.Case>
< /EntitySwitch>
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
These custom fields let your template list env0 templates/projects and collect variables dynamically:
// packages/app/src/App.tsx (within your < Route path="/create" ...>)
< ScaffolderFieldExtensions>
< Env0TemplateSelectorExtension />
< Env0ProjectSelectorExtension />
< Env0VariableInputExtension />
< /ScaffolderFieldExtensions>
- Template Selector queries env0 for allowed templates using the API key.
- Project Selector lists projects (optionally filtered by the selected template).
- Variables Input renders env0 variables for the chosen template/project.
(This is exactly what users will interact with in Backstage’s Create flow)
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
kind: Template
metadata:
name: env0-environment-from-template
title: Deploy env0 Environment
tags: [env0, terraform]
spec:
type: infrastructure
owner: platform-team
parameters:
- title: Choose Template & Project
required: [env0_template_id, env0_project_id]
properties:
env0_template_id:
title: env0 Template
type: string
ui:field: Env0TemplateSelector
env0_project_id:
title: env0 Project
type: string
ui:field: Env0ProjectSelector
ui:options:
env0TemplateId: "$"
- title: Variables
properties:
env0_variables:
title: Variables
type: array
ui:field: Env0VariablesInput
steps:
- id: env-create
name: Create env0 Environment
action: env0:environment:create
input:
name: $-$
projectId: $
templateId: $
variables:
$
output:
links:
- title: Open environment in env0
url: $
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.
Pros
Fast path to Terraform/OpenTofu/Pulumi self-service with guardrails; templates remain curated by platform admins, developers operate from Backstage.
Cons
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.
Pricing
Commercial env0 subscription tiers; Backstage integration follows the platform’s licensing.
5) Firefly Backstage Plugin , Hands-On Guide
Overview
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.
Key Features
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.
Hands-On Setup (Step-by-Step)
Step 1: Install the Frontend and Backend Plugins
# Frontend UI (Firefly page + entity cards)
yarn --cwd packages/app add @fireflyai/backstage-plugin-firefly
# Backend provider (imports assets/accounts; relationships)
yarn --cwd packages/backend add @fireflyai/backstage-backend-plugin-firefly
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>"
export FIREFLY_SECRET_KEY="< your-secret-key>"
# app-config.yaml
firefly:
accessKey: ${FIREFLY_ACCESS_KEY}
secretKey: ${FIREFLY_SECRET_KEY}
# optional: region / apiBase if your tenant requires it
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)
import { createBackend } from '@backstage/backend-defaults';
import { fireflyPlugin } from '@fireflyai/backstage-backend-plugin-firefly';
const backend = createBackend();
backend.add(fireflyPlugin());
backend.start();
Step 4: Add the Firefly page and entity card
In packages/app/src/App.tsx, add the Firefly page route:
import { FireflyPage } from '@fireflyai/backstage-plugin-firefly';
import { Route } from 'react-router-dom';
< Route path="/firefly" element={< FireflyPage />} />
In packages/app/src/components/catalog/EntityPage.tsx, add the IaC coverage card:
import { EntityDependenciesIaCCoverageCard } from '@fireflyai/backstage-plugin-firefly';
import { Grid } from '@backstage/core-components';
< Grid item md={6} xs={12}>
< EntityDependenciesIaCCoverageCard />
< /Grid>
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.)
Step 6: Use drift/coverage to move strays under IaC (see Image 4)
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.)
Pros
- Surfaces resource inventory + IaC coverage directly on Backstage entities.
- Helpful drift visibility to prioritize bringing unmanaged resources under Terraform.
- Backend provider can import assets and accounts to build a navigable cloud graph inside the catalog.
Cons
- Primarily visibility-oriented; does not generate IaC from Backstage metadata.
- Requires Firefly subscription/tenant and credentials management.
Pricing
Available via Firefly subscription tiers; the Backstage plugin follows the platform’s licensing.
