Should we self-host Backstage or use Roadie to manage it?

Roadie is hosted and managed Backstage, so the plugin ecosystem, software templates and TechDocs are identical. What changes is who runs the instance and absorbs a release every two weeks. What does not change is that your engineers still write and maintain the catalog YAML.

Is Roadie the same product as Backstage?

It is Backstage, hosted and managed, so the plugin ecosystem, software templates and TechDocs all come with it. The differences are operational and commercial rather than functional.

What does Roadie cost?

The Teams plan carries a 50-seat minimum, putting the floor at around 1,200 US dollars a month, and RBAC, the REST API and SLA guarantees require Growth at 100 seats or more.

Can we customise Roadie as freely as self-hosted Backstage?

Less freely. A managed platform necessarily constrains what you can change at the infrastructure level. For most teams that is a fair trade, and for teams doing deep customisation it is the reason to self-host.

Roadie vs Backstage

Q: Does Roadie remove the YAML maintenance?

No, and this is the most common misunderstanding. Roadie manages the instance, not the declarations inside it. Your engineers still write and update catalog-info.yaml, which is where catalog staleness comes from.

At a glance

	Roadie	Self-hosted Backstage
Underlying product	Backstage	Backstage
Who runs the instance	Roadie	You
Upgrade burden	Absorbed by Roadie	Yours, every two weeks, without semantic versioning
Plugin ecosystem	Full access, without running the infrastructure	Full access, and you wire it up
Software templates and TechDocs	Included	Included
Catalog source	`catalog-info.yaml` committed to repositories	`catalog-info.yaml` committed to repositories
Who maintains the catalog content	Your engineers	Your engineers
Infrastructure customisation	Constrained by the managed platform	Unlimited
Cost	50-seat minimum on Teams, 100 or more for RBAC and the API	No licence, plus the engineering time to run it

How the two differ in practice

This is the narrowest comparison in the family, because underneath they are the same software. Roadie is Backstage with somebody else operating it, so the feature discussion is short and the operational one is the whole thing.

The burden Roadie takes is real and recurring. Backstage releases every two weeks and does not honour semantic versioning, which means patch versions can carry breaking changes and upgrade work never finishes. Teams routinely report a dedicated week for a major upgrade. Handing that to a vendor is value delivered every fortnight rather than a one-off convenience, and it is the reason most Roadie customers are there.

The burden Roadie does not take is the one teams most often assume it does. Roadie manages the instance, not the declarations inside it. Your engineers still write, commit and update catalog-info.yaml files, and the catalog still drifts when they stop. New services go unregistered, owners go stale after a reorganisation, and declared dependencies diverge from what production is actually calling. Moving to a hosted Backstage does not touch any of that, and a team that adopted Roadie expecting it to will be disappointed in about three months.

The commercial shape is the other real difference. The Teams plan carries a 50-seat minimum, which sets a floor around 1,200 US dollars a month before anybody has opened the portal, and RBAC, the REST API and SLA guarantees sit on Growth at 100 seats or more. For a 30-engineer company that is paying for 50 and waiting for features it needed on day one. For a 300-engineer company it is unremarkable.

Where each one is stronger

Roadie is stronger for the common case, which is a team that wants Backstage's capabilities and has discovered that running Backstage is a job. Software templates and TechDocs arrive working rather than as a project, the upgrade treadmill belongs to somebody else, and the platform engineers you have can spend their time on golden paths instead of on version maintenance. If your Backstage adoption stalled on operational overhead specifically, Roadie addresses exactly that.

Self-hosting is stronger in two cases. The first is deep customisation: a managed platform constrains what you can change at the infrastructure level, and organisations doing genuinely unusual things with Backstage will hit those constraints. The second is arithmetic. Below 50 engineers the seat minimum is poor value, and a small team with one capable engineer can run a modest Backstage instance for less than the floor costs.

There is also a data and control argument for self-hosting that some regulated environments treat as decisive, and which is worth checking early rather than late.

How to choose

Work out first whether your problem is operations or content, because Roadie only solves one of them. If your Backstage is behind on upgrades and nobody wants to own it, Roadie is the direct fix. If your Backstage is current but nobody trusts the catalog, Roadie changes nothing at all and the money is wasted.

Then do the seat arithmetic against your actual headcount rather than your projected one. The 50-seat floor and the 100-seat gate for RBAC and the API are the two numbers that decide whether this is good value, and they are knowable before any demo.

If the catalog content is the problem, neither option here addresses it. What teams move to when they leave Roadie covers that case, and what a service catalog is and what it is for names the failure you are buying against.

If you are still choosing a portal at all rather than fixing an existing one, how Backstage compares to Port is the wider decision that sits above this one.

A catalog built the other way

Roadie fixes who runs the instance. Neither option here changes where the catalog content comes from, which is a person declaring it. NOFire AI reads the catalog from what is actually running, so there is no file to keep current.

Services, owners and dependencies come from deploys, traces, repositories, cloud resources and incidents. Each fact is dated and marked observed or inferred.
A service nobody declared still appears. So does a service with no owner.
A wiki is generated for every service and updated as production changes. Nobody writes or commits a page.
A policy gate reads the same map to bound what an agent can do, and holds a write for a person or refuses it.
Coding agents run in a microVM through brig, our open-source sandbox. The control system watches that run from outside the boundary and can stop it.

Check it against the three entities you believe are wrong today. Why a declared catalog drifts describes the failure, and what teams move to when they leave Roadie covers the switch.