Upcoming Workshop: Citizen Developer Agentic Software Factory on AWS
Register Here!Your developers already use Backstage to find services and owners. The next request is for a database, a queue, or a new environment from the same place.
Massdriver is the provisioning layer behind the portal. Backstage stays the front door, and every infrastructure change, from Backstage, the CLI, CI, or an AI agent, takes the same governed path.
Most Backstage rollouts start with the software catalog. Teams register their services, owners show up next to each one, and the docs finally live somewhere people look. Then a developer opens a new service page and asks the obvious question: can I get a Postgres database from here?
Backstage has a clear answer for the first step. A software template collects a form, and its actions can open a pull request, call a webhook, or trigger a CI workflow. Backstage supports custom actions and a permissions framework, so a template can do almost anything your team writes code for.
That last part is the work. Everything after the form is yours: the repository the Terraform lands in, the workflow that runs it, the cloud credentials that workflow holds, the state backend, the policy checks, the approval for production, and a way to show the developer whether the database exists yet. The portal is one of ten systems a working internal developer platform needs. Our build vs buy estimate puts all ten at 54 engineer-months for a first production version, which is about 18 months for a team of three.
The decision for a platform team is which of those systems to build and run yourself, and which to put behind Backstage as a product.
Each option keeps a portal in front. They differ in how much of the layer underneath your team builds and runs.
| Option | What you get | What stays with your team |
|---|---|---|
| Scaffolder template, pull request, CI | Full control with tools you already run. A template writes Terraform into a repository and your CI applies it after review. | One template and one workflow per resource type, cloud credentials in CI, state, policy, approvals, drift, teardown, and reporting status back to the portal. |
| Backstage with HCP Terraform or Spacelift | A mature runner with remote state, run history, and policy as code (Sentinel or OPA). Much of the execution work is done for you. | The integration in between: how a catalog entity maps to workspaces or stacks, how environments relate, how one module’s outputs reach the next, and who may change production. |
| Replace Backstage with another portal | Some portals ship self-service actions and scorecards out of the box. | The same provisioning layer, because portal actions still call automation you write, plus a migration away from a portal your developers already use. |
| Backstage with Massdriver underneath | An executable catalog built from your Terraform, OpenTofu, and Helm, a generated pipeline for every deploy, policy before apply, attribute-based access, approvals, and an audit trail. The plugin shows the result in Backstage. | Writing and owning the modules, which your team already does, and deciding the rules for who may change what. |
Scaffolder template, pull request, CI
What you get
Full control with tools you already run. A template writes Terraform into a repository and your CI applies it after review.
What stays with your team
One template and one workflow per resource type, cloud credentials in CI, state, policy, approvals, drift, teardown, and reporting status back to the portal.
Backstage with HCP Terraform or Spacelift
What you get
A mature runner with remote state, run history, and policy as code (Sentinel or OPA). Much of the execution work is done for you.
What stays with your team
The integration in between: how a catalog entity maps to workspaces or stacks, how environments relate, how one module’s outputs reach the next, and who may change production.
Replace Backstage with another portal
What you get
Some portals ship self-service actions and scorecards out of the box.
What stays with your team
The same provisioning layer, because portal actions still call automation you write, plus a migration away from a portal your developers already use.
Backstage with Massdriver underneath
What you get
An executable catalog built from your Terraform, OpenTofu, and Helm, a generated pipeline for every deploy, policy before apply, attribute-based access, approvals, and an audit trail. The plugin shows the result in Backstage.
What stays with your team
Writing and owning the modules, which your team already does, and deciding the rules for who may change what.
Backstage stays the catalog of record for services. Massdriver holds the approved infrastructure catalog, runs each change, and keeps the record.
Your platform team publishes the Terraform, OpenTofu, and Helm it already writes as bundles. Each bundle carries a schema for the inputs a developer may set, and Massdriver builds the form from it.
Massdriver plans, checks policy, applies, keeps state, and passes outputs to the components that depend on them. There is no workflow to write for each resource type.
Policies grant actions such as plan, propose, and deploy by project, environment, bundle, or a custom attribute such as a business domain. A deny always wins over an allow.
The Massdriver Backstage plugin adds a live status card and a Massdriver tab to a catalog entity. Actions that change infrastructure open in Massdriver, so policy and approvals stay in one place.
A developer on the payments team needs a Postgres database for a new checkout service, first in staging and then in production.
The developer opens the checkout service in Backstage. Its Massdriver tab shows the project and environments the service runs in. From there they open Massdriver and add the Postgres bundle your platform team published.
The form comes from the bundle’s schema. The developer can pick a supported engine version and a valid database name, and values outside those rules cannot be submitted. The database connects to the staging network without anyone copying subnet IDs.
A group policy lets payments engineers deploy in staging and only propose in production. Before the apply, policy checks (SOC 2, HIPAA, CIS) run against the plan.
Massdriver generates the pipeline, plans, and applies with cloud credentials it holds. The developer never receives a cloud key. State is stored, and the connection details pass to the checkout service.
For production, the developer proposes the same change. Separation of duty is on for that environment, so a lead who did not propose it has to approve before it applies.
The change carries the proposer, the approver, the diff, the policy results, and the outcome. The status card in Backstage shows the new database on the checkout service.
Some teams should keep the scaffolder and CI approach. If you offer few resource types, change them rarely, and have engineers who want to own every line of the pipeline, the build stays manageable and you keep full control.
“Massdriver's platform has revolutionized our approach to infrastructure, saving us 89% of the time spent managing infrastructure.”
A two-minute overview of Massdriver, the platform orchestrator that provisions what your Backstage catalog describes.
No. Backstage stays the developer portal and the catalog of record for services. Massdriver is the provisioning, policy, and audit layer underneath it, and the plugin shows Massdriver state on your Backstage entities.
You can, and many teams start there. The cost shows up later, when your team owns the workflow for every resource type along with the credentials in CI, state, policy, approvals, drift, and teardown. Massdriver is those systems already built.
In Massdriver. Actions in Backstage that change infrastructure open in the Massdriver app, where the policy check and any approval run. The Massdriver CLI, API, Terraform provider, and MCP server go through the same catalog and the same policy, so every caller takes one path.
No. Each module is published as a bundle with a massdriver.yaml next to it that declares its inputs, connections, and outputs. The Terraform or OpenTofu code stays as it is.
No. The catalog, ownership data, and docs in Backstage stay where they are. Massdriver replaces the pipelines you would otherwise write behind it.
Resource import brings existing infrastructure under Massdriver management without a redeploy, so you can start with the services already in your Backstage catalog.
Yes. Massdriver Self-Hosted installs with a Helm chart on your own Kubernetes cluster and supports air-gapped networks. See the self-hosted internal developer platform page for what runs where.
Give us an hour with your platform and security leads and have a working governed path to production on your own infrastructure within a day, then prove it for 30 days. If you stop, you keep the code.