Backstage vs Cortex

At a glance

	Backstage	Cortex
What you are getting	An open-source framework to build a portal from	A finished commercial product
Catalog source	catalog-info.yaml committed to repositories	cortex.yaml descriptors authored by engineers
Scorecards	Through plugins such as Tech Insights, built and maintained by you	Rule authoring as a first-class feature
Driving standards across teams	Tech Insights, a community plugin giving scorecards and checks, installed and configured by you	Initiatives, with per-team progress tracking
Time to usable	Six to twelve months on most published accounts	Three-week onboarding minimum, three to six months to full coverage
Upgrade burden	Releases every two weeks without semantic versioning	None on your side
Extensibility	Unlimited, and yours to write	Within the product's model
Licence cost	None	Per seat, plus implementation and professional services
Staleness without an owner	Drifts	Drifts

How the two differ in practice

The honest framing is build versus buy, and the feature grid mostly distracts from it. Both products end up presenting engineers with a catalog of services, an owner per service, and some notion of whether a service meets a standard. How you get there is where the money goes.

Backstage hands you the components and the responsibility. A demo instance runs in an afternoon, which is the source of most underestimation, while a usable one takes upwards of seventy setup steps and six to twelve months of TypeScript and React work on most published accounts. Every plugin is a separate codebase with its own frontend, backend and schema, and cross-plugin queries are architecturally awkward as a result. Releases arrive every two weeks and do not honour semantic versioning, so upgrade work never finishes.

Cortex hands you the product and the bill. Onboarding starts at around three weeks, with full catalog population and scorecard configuration typically taking three to six months, which is faster than Backstage by a wide margin but slower than the sales cycle implies. Scorecards are the strongest part: a rules engine over declared metadata, with Initiatives on top so a platform team can run a readiness programme and track each team's progress against it.

What neither does is keep itself true. Both are declaration-based. Backstage reads YAML from repositories, Cortex reads descriptors, and both reflect what somebody remembered to write down. Ownership drifts silently after a reorganisation in either product, because the field still names whoever it named. This is the shared limit and it is the one that determines whether the investment still pays back in year two.

Where each one is stronger

Cortex is stronger for the large majority of organisations, and the reason is simply that most engineering teams should not be building portal software. Scorecards work on day one instead of being a plugin project, Initiatives exist for the specific job of moving many teams to one standard, and nobody on your payroll owns an upgrade cycle. If the mandate is a compliance or readiness programme with a date attached, Cortex is close to the obvious answer.

Backstage is stronger in the two situations where owning the code is worth its cost. The first is an unusual environment where any commercial product would need extending past its intended shape. The second is an organisation with a genuine platform engineering function that will build internal tooling anyway, where Backstage is a foundation rather than an extra burden. The ownership argument is also real: no vendor can raise the price, change the licence, or be acquired and point the roadmap elsewhere.

The caution on Cortex is cost shape rather than capability. Per-seat licensing plus implementation plus a platform engineer carrying catalog hygiene is a number that teams below a couple of hundred engineers often find exceeds what it returns before adoption reaches critical mass.

The caution on Backstage is that the six-to-twelve-month figure is not pessimism. Teams miss it most often because they scoped from the demo instance.

How to choose

Start with a headcount question, because it settles this faster than any feature list. Can you assign at least one engineer to a portal indefinitely, not as a quarter-long project? If not, Backstage will not reach a usable state, and the comparison is over.

If you can, ask the second question: is your environment actually unusual? Most teams believe theirs is and most are wrong. Write down the three entity types that you think would not fit a commercial product's model, then check whether Cortex handles them. Usually it does.

Then price both honestly, with engineering time in the Backstage column at its real cost. The framework being free is true and it is not the same as the deployment being cheap.

Finally, decide whether a declared catalog solves your actual problem. If the pain is that no catalog exists, both fix it. If the pain is that the catalog you have is wrong, both will reproduce it, and what teams move to when they leave Backstage covers the different shape of product built for that. What a service catalog is and what it is for is the right place to start if the requirement is still vague.

A catalog built the other way

Both of these are declared: somebody writes the entity down, and somebody keeps it true. 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 Backstage covers the switch.