VS

Backstage catalogs your services. Massdriver provisions them.

A developer portal and a platform orchestrator do different jobs, and most platform teams end up wanting both.

Backstage is an open source framework for building a developer portal. It came out of Spotify and is now a CNCF project. It gives you a software catalog, scaffolder templates, TechDocs, and a plugin system, and it acts as the front door to all of them. Backstage does not provision infrastructure, run pipelines, or hold cloud credentials.

Massdriver is a platform orchestrator with a developer portal included. Your platform team publishes the Terraform, OpenTofu, and Helm it already writes as bundles in a catalog. Developers and AI agents provision from that catalog, every deploy is policy-checked before it lands, and Massdriver runs the provisioning itself, so there is no separate pipeline to build.

Backstage

Backstage is a portal framework. Its catalog holds metadata about your services: who owns them, where the docs are, which CI runs are green, which dependencies exist. Scaffolder templates create new repositories and file skeletons from a form. Plugins surface data from other systems inside one UI.

Everything Backstage does is about visibility and coordination. When a scaffolder template appears to "create infrastructure", it is calling something else, such as a CI job, a script, or a Terraform run in another tool, because Backstage itself runs nothing.

Massdriver

Massdriver's catalog is executable. A bundle is a package of infrastructure as code, a schema that describes the inputs a developer may set, and the policy that applies to it. When a developer places a bundle on the canvas, or an agent requests one through the API, Massdriver generates a pipeline for that deploy, runs it, records the result, and keeps the environment graph current.

The portal is one way in. The CLI, the GraphQL API, the Terraform provider, and the MCP server are the others. They all go through the same catalog and the same policy, so there is no path to production that goes around what the platform team approved.

The cases where Backstage is the right choice

Backstage is a good choice when:

• Provisioning is already solved. Your team has a mature Terraform pipeline, developers can request what they need without a ticket, and what you lack is one place to see it all.
• You have a team to run it. Backstage is a Node application you host, upgrade, and extend. A platform team of a few people can carry it. A part-time owner cannot.
• The problem is discovery. Hundreds of services, unclear ownership, docs in six places. The catalog fixes that.

If that describes your organization, Backstage in front of a working provisioning layer is a strong setup. Massdriver can be that layer, but so can other tools.

The stall

The common failure starts with a team adopting Backstage to give developers self-service. They write a scaffolder template that calls a GitHub Actions workflow, which runs Terraform, which provisions a database, and it works in the demo.

After the demo, every new resource type needs a new template, a new workflow, and a new module. Policy ends up in the template's form, in the workflow's checks, and in the Terraform, with state and secrets somewhere in CI and nobody owning the middle. Developers go back to filing tickets, and the portal becomes a read-only catalog with a "request infrastructure" button that opens Jira.

This is the gap the build-vs-buy analysis puts numbers on: the portal was the visible part, and the provisioning layer underneath it was the two-year project.

Using both

Massdriver publishes a Backstage plugin. It surfaces Massdriver projects, environment graphs, instance details, bundle repositories, and cloud resources inside Backstage. Link a catalog entity to a Massdriver project, environment, or instance and it gets a live status card and a Massdriver tab. Actions that change infrastructure deep-link into the Massdriver app, so policy stays in one place.

The link is one annotation in catalog-info.yaml:

metadata:
  annotations:
    # Point the entity at the most specific matching Massdriver resource.
    massdriver.cloud/project-id: ecommerce
    # ...or one environment in that project:
    # massdriver.cloud/environment-id: ecommerce-prod
    # ...or one deployed instance in that environment:
    # massdriver.cloud/instance-id: ecommerce-prod-checkout

With both in place, Backstage stays the front door and the catalog of record for services. Massdriver is the execution layer: the approved infrastructure catalog, the provisioning, the policy gate, and the audit record.

A two-minute overview

A two-minute overview of Massdriver, the platform orchestrator side of this comparison.

Customer results

AMD Global Telemedicine moved its release process onto Massdriver and cut engineering time on releases by 89%. One release that took three engineers three hours now takes one engineer under an hour. Their developers did not learn Terraform to get there.

Bottom Line

Backstage answers the question of what you have and who owns it. Massdriver answers what can be built, by whom, under which policy, and then builds it.

If you have picked Backstage as the portal, the next question is what provisions the infrastructure underneath it. Massdriver is built for that question, and the plugin means you do not have to choose between them.