Open-source alternatives to Cortex: Backstage and self-hosted options

Which open-source alternative to Cortex fits your team

Backstage is the main self-hosted replacement for Cortex's service catalog and documentation, but scorecards and maturity tracking need extra work. The Software Catalog, Software Templates and TechDocs cover the core of what most teams use Cortex for: registering services, assigning owners and publishing docs next to code. Backstage is an Apache-2.0 framework originally created by Spotify and now a CNCF project. Scorecard-style checks and maturity levels are not a single built-in feature you switch on, so plan to build them with plugins or custom code and confirm the coverage you need against the current plugin list before you commit.

Teams usually start looking at alternatives for one of four reasons: a renewal that arrives with a higher quote, a licensing change, a data residency requirement that a hosted control plane does not meet, or a growing sense that the catalog data and scorecard logic sit in a system they cannot easily move out of. Self-hosting Cortex is not a complete escape from the vendor relationship. Cortex documents a self-managed deployment into your own Kubernetes cluster through a Helm chart, but it requires a JWT license key and access token from the Cortex account team and a PostgreSQL database. Self-hosting therefore changes where the data runs, not whether you pay a subscription. Ask your account team in writing what the self-managed license covers, how it renews and what happens to your data if you stop renewing.

Before you choose, list the Cortex features your engineers use each week and sort them into three groups: catalog and ownership, documentation, and scorecards. The first two map closely to Backstage. The third is where your effort will go, so estimate it with your platform team using your own scorecard rules. If the scorecards are a small set of checks, a self-hosted Backstage instance may be the simpler path. If they are central to how leadership measures engineering, get a scoped plan in writing before you move anything.

Open-source options for service ownership and scorecards

Cortex combines service ownership, a catalog and scorecards in one product. Open-source replacements split these jobs: Backstage covers the catalog and portal layer well, while scorecards and maturity rules usually come from plugins or custom code. The cards below cover the core framework, the scorecard gap, and a commercial self-hosted comparison point.

Backstage as the catalog core

Backstage is an Apache-2.0 framework created by Spotify and accepted to the CNCF on September 8, 2020. It provides the Software Catalog, Software Templates, TechDocs and a plugin ecosystem, which together cover most of what teams use Cortex for in day-to-day service ownership. Services are described in catalog-info.yaml files next to the code. Check which catalog kinds and relations your ownership model needs before you migrate.

Scorecards are not a core feature

Backstage does not ship scorecards or maturity scoring as a core feature. Teams usually rebuild Cortex-style rules with community or in-house plugins, or with checks computed from catalog data and CI results. Plan for rule definitions, a scoring model, and a place to show results on entity pages. Expect this to be the largest custom work item when replacing Cortex scorecards.

Catalog descriptors as the ownership source

Ownership in Backstage comes from the owner and system fields in catalog-info.yaml and from Group and User entities. Cortex teams often hold ownership in its own UI, so the migration needs an export of service-to-team mappings and a review of which fields become the source of truth. Confirm that your identity provider sync populates Group and User entities the way your reporting expects.

TechDocs for service documentation

TechDocs lets engineers keep Markdown next to their code, and Backstage builds the documentation sites with MkDocs and its plugins. This replaces portal-hosted docs that Cortex teams may link to. Check that your MkDocs plugins and build runners fit your CI setup, and decide who owns the docs pipeline after launch.

Backstage release cadence

Backstage ships its main release line monthly, on the Tuesday before the third Wednesday of each month, and a next line weekly on Tuesdays. Your team must choose which line to follow and schedule plugin and dependency upgrades against it. Plugins from different authors may not track the same release, so confirm compatibility before upgrading.

Port as a comparison point

Port is not open source by default, so it is a comparison point rather than an open-source option. Its data integrations, most built on its Ocean framework, can be hosted by Port or self-hosted with Helm or Docker in your infrastructure. Self-hosting the integrations does not remove the Port subscription, so ask for the licensing terms in writing before comparing total cost with Backstage.

How Cortex capabilities map to Backstage and plugins

This table maps the Cortex capabilities most teams rely on for service ownership and scorecards to Backstage features, plugins or custom code. Read the coverage column first: it separates what Backstage ships with from what you must add, and marks scorecards and maturity checks as an area to confirm before you commit.

Cortex capability	Backstage equivalent	Coverage note
Service catalog and ownership	Component, Group and User entities defined in catalog-info.yaml files stored beside each service	Built in. Ownership depends on keeping the owner field accurate, so plan how team data gets populated from your identity provider.
Documentation	TechDocs, which builds MkDocs sites from Markdown kept next to the code	Built in. Teams need to adopt docs-like-code and the MkDocs plugins they rely on must be checked for your setup.
API definitions	API entities that can carry OpenAPI, AsyncAPI, GraphQL or gRPC definitions	Built in for registration and display. Validation rules and API-level scorecards are not included and need custom work.
Self-service workflows	Software Templates that scaffold repositories and register new catalog entries	Built in for scaffolding. Day-two actions such as scaling or rotating secrets require custom actions or separate tooling.
Scorecards and maturity checks	No native equivalent. Community plugins and custom scripts that read catalog data and run rules	Gap to confirm. Verify the maturity, maintenance status and release cadence of any plugin you select, and budget for custom rule code.
Ownership and scorecard reporting	Catalog views and custom dashboards built with plugins or external reporting tools	Partial. Expect to design the reporting layer yourself and test it against your scorecard definitions.
Licensing and hosting	Apache-2.0 framework run in your own Kubernetes or cloud environment	No vendor license key is required for the framework. Confirm third-party plugin licenses individually.

What Backstage gives you out of the box and what needs custom work

Backstage covers the core of what a Cortex team uses day to day: the Software Catalog, Software Templates and TechDocs. Each service is described by a catalog-info.yaml file using kinds such as Component, API, System, Group and User, and TechDocs builds docs from Markdown kept next to the code. Scorecard rules, maturity levels and ownership scoring are a different matter. Backstage does not ship a scoring engine for them, so you will either adopt a community plugin that evaluates rules against catalog data, or write that logic in-house. Confirm the exact plugin coverage you need against the current plugin list before you commit to a design, because the answer differs for each rule family.

The work starts with defining the rules in writing: which fields make a service owned, which CI signals count as passing a check, and what each maturity level requires. Those rules then need inputs. Ownership and team data usually come from your identity provider and the catalog's Group and User entities, while build, test and deployment signals come from CI and observability systems. Plan a small pipeline that reads these sources, evaluates each rule and writes results back to the catalog as annotations or a dedicated view. Ask whether the Cortex scorecard definitions can be exported so the rules are not rebuilt from memory.

The maintenance cost is the part teams underestimate. Backstage ships a monthly main release line and a weekly next line, so any custom plugin or scoring code needs a named owner who tracks breaking changes and upgrades the dependency on a schedule. Pin a release line, test scorecard output against known services after each upgrade, and budget for that work as a recurring cost. A Cortex subscription moves this maintenance to the vendor, so the comparison should count your engineers' hours against the license fee.

Cost components of Cortex versus a self-hosted Backstage portal

Self-managing Cortex moves where the software runs, not who sells it. Cortex documents a deployment into your own Kubernetes cluster through a Helm chart, and the install requires a JWT license key and an access token from the Cortex account team. The subscription therefore continues, and your team takes on the infrastructure that the vendor hosts in the SaaS model.

Vendor license (recurring): Cortex pays for the license key and access token, which your account team issues. Ask whether the license term, renewal mechanics and user or service counts are fixed in the order form.
Kubernetes cluster (recurring): Your platform team pays for cluster capacity on EKS, AKS, GKE or a locally installed distribution, plus node upgrades and monitoring.
PostgreSQL database (recurring plus one-time setup): Your database team provisions, backs up, patches and restores the PostgreSQL instance that Cortex requires.
Operations and upgrades (recurring): Your engineers apply Helm chart upgrades, rotate credentials and respond to incidents in your environment.
Install effort (one-time): Initial setup, network and identity configuration, and validation of the deployment.

Ask the account team which components are included in the license and which of the above remain your responsibility.

Backstage is an Apache-2.0 framework, so the project itself carries no license fee. Your costs are the infrastructure to run it, the people who operate it, and the build work that turns the framework into a portal your teams use. Infrastructure is the most visible line, but it is usually the smallest part of the total.

Hosting (recurring): Your platform team pays for the Kubernetes or VM capacity, the database backing the catalog and the CI pipeline that builds the portal image.
Build and plugin work (one-time, then ongoing): Your engineers or an implementation partner configure the Software Catalog, Software Templates and TechDocs, then maintain custom plugins as Backstage releases change.
Identity and catalog integrations (one-time plus recurring): Connecting your identity provider for users and groups, and keeping catalog-info.yaml files current, takes sustained effort from owners.
Upgrades (recurring): Backstage ships on a published cadence, so someone must track releases and test plugin compatibility.
Internal skills (recurring): Staff who know TypeScript, React and Kubernetes must be hired, trained or retained.

Ask for a written breakdown of which of these items sit in the scope of any quote, and whether ongoing upgrades are included in a retainer.

What drives the multi-year cost of running Backstage

This table compares the cost components of a Cortex subscription with a self-run Backstage portal, marking which items are one-time and which recur. Read it as a checklist for a written quote and an internal budget, since no figures are given here. The main takeaway is that Backstage removes the vendor license line but adds recurring engineering work that must be staffed.

Cost component	Who is paid or who carries it	One-time or recurring	What drives it up or down
Cortex subscription or license	Cortex, for hosted use or the self-managed license key	Recurring	Seat or service count, edition, and renewal terms; confirm whether self-managed use is priced differently from hosted
Cortex self-managed infrastructure	Your cloud account for the Kubernetes cluster and PostgreSQL database	Recurring	Cluster size, database sizing, and high availability choices; Cortex requires a license key and access token from its account team
Backstage infrastructure	Your cloud account or data center for the portal, database, and CI runners	Recurring	Number of catalog entities, TechDocs build frequency, and plugin load; Backstage has no license fee under Apache-2.0
Initial implementation	Internal platform team or an implementation partner, under a fixed-scope written plan	One-time	Number of integrations, identity provider connection, and how many scorecard rules are rebuilt
Catalog and ownership migration	Internal team or partner, to convert Cortex service and team data to catalog-info.yaml	One-time	Data quality in Cortex, how many services lack owners, and whether ownership comes from your identity provider
Scorecard and plugin development	Internal engineers or a contractor, for scorecard logic and custom views Cortex provides	One-time, then recurring upkeep	Number of custom scorecard rules and integrations; confirm which maturity features exist as plugins before estimating
Upgrades on the monthly release line	Internal platform engineers, testing and applying framework and plugin updates	Recurring	Plugin count, custom code depth, and how often you adopt each release; the main release line ships monthly
Support and internal skills	Internal staff, community resources, or a retained support contract	Recurring	Team size, on-call expectations, and skill depth in TypeScript, Kubernetes, and identity; ask any partner for a retainer scope in writing

What you give up when you leave Cortex and the usual workarounds

Leaving Cortex means replacing more than a catalog. Scorecards, maturity views and vendor support each need a deliberate replacement, and each has a different cost profile. The cards below name the usual workaround for each gap and what to confirm before you commit.

Vendor-supported scorecards

Cortex ships scorecard rules and reports as a managed feature. Backstage has no built-in scorecard engine, so teams typically add a community or custom plugin, or write scheduled jobs that read catalog-info.yaml fields and tags and publish pass or fail results. Map every scorecard rule to a data source before you migrate. Rules that depend on runtime signals such as deploy frequency or alert status need an integration you must build and maintain. Confirm which rules Cortex supports natively in your version and which ones you have been using in practice.

Out-of-the-box maturity dashboards

Cortex gives leaders maturity views across services without extra configuration. In Backstage, the Software Catalog lists entities and their metadata, but aggregated maturity dashboards need a plugin or a custom front end fed by your scorecard data. Plan for a reporting layer that answers the questions your leadership asks each quarter, such as the share of services with an owner and a runbook. Decide early whether the dashboard lives in Backstage or in an external BI tool, because that choice sets who maintains it.

Vendor support and escalation

A commercial product comes with a support contract, a named account team and an upgrade path. With Backstage, support comes from the open-source community, your internal platform team, or a retained partner. Backstage releases on a published schedule, so upgrades are routine work, but plugin compatibility with each release is your responsibility. Ask any implementation partner for a written retainer scope covering upgrades, incident response and plugin maintenance before you retire the vendor contract.

Pre-built integrations

Cortex connects to source control, incident tooling, cloud accounts and monitoring through its own connectors. Backstage offers a plugin ecosystem, but coverage varies by tool and by plugin maintenance status. Inventory every integration you rely on today, including the ones that feed ownership data from your identity provider. For each one, check whether a maintained Backstage plugin exists and whether it supports your current versions, and budget for a custom connector where it does not.

Self-hosting does not remove the license

Cortex documents a self-managed deployment into your own Kubernetes cluster with a Helm chart, a PostgreSQL database and a JWT license key from the account team. Running it yourself moves hosting responsibility to you but keeps the subscription. Compare that recurring license with the cost of running Backstage, which is open source under Apache-2.0 but still needs engineering time, hosting and plugin upkeep. Ask Cortex for a written quote that separates license, support and any deployment assistance.

How to move a Cortex service catalog to Backstage

This sequence moves service ownership, catalog records and scorecard logic from Cortex into Backstage in stages, so each step can be checked before the subscription is ended. The output is a Backstage catalog that matches Cortex on ownership and docs, plus a parallel scorecard run that shows where the two systems disagree.

Inventory services and scorecard rules
Your platform team exports the list of services, their owners, tiers and tags from Cortex, then writes down every scorecard rule with its criteria, weight and the teams it applies to. Some rules will map to built-in Backstage catalog fields, while others will need a plugin or custom code, and that split depends on your own rule set. The step is done when every service and every rule has a row in one inventory that a reviewer has signed off, with each rule marked as native, plugin or custom.
Export entity and ownership data
Using the Cortex API or an export your account team provides, the platform team pulls entity records, relationships, owner assignments and custom metadata into a neutral file such as CSV or JSON. Confirm with Cortex which fields the export includes, because custom properties and historical data may need a separate request. The step is complete when a row count per entity type matches the counts shown in the Cortex interface and a sample of ten services has been checked by hand.
Generate catalog-info.yaml from the export
A script or template turns each exported service into a catalog-info.yaml descriptor in the repository that owns it, using Component entities for services and System or Domain entities for groupings. API entities can carry OpenAPI, AsyncAPI, GraphQL or gRPC definitions if your services publish them, so add those references where they exist. Engineers review generated files in pull requests, since repository owners know details the export does not capture. The step is done when every service repository has a merged descriptor that validates in a Backstage instance.
Map identity provider groups to owners
Ownership in Backstage points to Group and User entities, which are normally ingested from your identity provider. Compare the team names in Cortex with the groups in your directory, and agree on a mapping for teams that were named differently or merged. Record exceptions, such as shared services with no clear team, so they are not silently assigned. The step is complete when each Component has an owner that resolves to a group or user in the Backstage catalog, and the unresolved list is empty or documented.
Migrate documentation to TechDocs
Cortex documentation that lives outside the code, such as wiki pages or linked runbooks, needs a decision: move it into Markdown next to the service, or link to it from the catalog entry. TechDocs builds MkDocs sites from Markdown kept with the code, and you should confirm which MkDocs plugins your documentation depends on before choosing the build path. The step is done when each migrated service renders its docs in Backstage and the platform team has compared a list of pages against the original sources.
Run a pilot with a small set of services
Choose a pilot group of services that covers different languages, owners and scorecard rules, and load them into a non-production Backstage instance. Teams that own the pilot services check that their owners, dependencies and docs look correct and report gaps in a shared issue list. The pilot shows which scorecard rules need a plugin or custom work, and which can be met with catalog fields alone. The step is complete when the pilot owners sign off and each open gap has a named owner and a decision.
Run scorecards in parallel
Keep Cortex active while the same rules run in Backstage against the full catalog. Compare pass and fail results per service and per rule each week, and track every mismatch to a root cause, such as a missing field, a rule that reads data Backstage does not hold, or a difference in how scores are calculated. Because your rule definitions decide how much the two will differ, expect some disagreement and agree on which system is authoritative for each rule. The step is done when the mismatch list is closed or accepted by the scorecard owners.
Cut over and decommission the Cortex subscription
Switch reporting, team dashboards and any automation that reads scorecard results to Backstage, and announce the date after which Cortex is read-only. Retain an export of Cortex data for audit or records purposes, and confirm the retention terms with your compliance lead and with Cortex. Your contract, notice period and any license key on a self-managed Helm deployment determine when the subscription can end, so check those terms before you stop renewing or shut down the cluster. The step is complete when the license is released, the cluster is removed or repurposed, and the decommissioning record is filed.

Which option fits by situation

When a contract, sovereignty rule or internal policy requires catalog metadata, scorecard results and documentation to stay inside your own cloud account or data center, Backstage fits well because you install and operate it there. Cortex does offer a self-managed deployment into your own Kubernetes cluster, but it still needs a PostgreSQL database and a license key and access token issued by the vendor, so your data stays in your infrastructure while the vendor relationship remains.

Hosting footprint: Backstage runs as your application with your database, so the hosting boundary is entirely yours to define.
Scorecard data: Rules that today read from Cortex's data model must be rewritten as plugins or scripts that read your own catalog and CI data.
Integrations: Each source system (source control, incident tooling, cloud accounts) needs a connector that your team owns and monitors.
Egress: Confirm which telemetry, plugin or update calls leave the network, since some plugins call external services by default.
Vendor access: Confirm whether any vendor support path still requires remote access or data export.

Confirm with your data protection team exactly which data classes will be stored, where backups go, and who can read them before choosing a deployment target.

When your teams need scorecards, entity types or workflows that a packaged product does not model well, Backstage fits because its catalog uses open YAML descriptors and its plugin system lets you add views and actions. The catalog supports kinds such as Component, API, Resource, System, Domain and Group, and API entities can carry OpenAPI, AsyncAPI, GraphQL or gRPC definitions, which gives you a flexible base for ownership and maturity data.

Descriptor model: Ownership and maturity fields live in catalog-info.yaml files kept in each repository.
Custom checks: Maturity rules become code, reviewed and tested like any other service.
Plugin ecosystem: Many common needs already have community plugins, but each one must be vetted for maintenance status and version compatibility.
Upgrade discipline: Backstage ships on a monthly main line and a weekly next line, so plan a regular upgrade cadence and test plugins against it.
Ownership of code: Your team becomes responsible for every custom plugin after handover.

Confirm which scorecard rules you truly need on day one and which can wait, because each custom rule is code your team must keep working.

How long and how much effort does a Cortex to Backstage move take?

Can our own engineers move from Cortex to Backstage without outside help?

Yes, a capable platform team can do it internally, provided it has people who know Kubernetes, TypeScript or React, and the operational habits to run a portal in production. Backstage is a framework rather than a finished product, so your team will build or configure the app, choose and maintain plugins, and own the catalog data. The main question is capacity: the migration competes with the platform team's other work, and the portal needs ongoing ownership after launch. Many teams start internally and bring in outside help for specific pieces such as the catalog import, the scorecard logic or the hardening review.

What work does a Cortex to Backstage migration require from our teams?

The work splits into four areas that your teams need to supply:

Service inventory: deciding which Cortex entities become Backstage components, APIs, systems, domains and groups, and where each catalog-info.yaml file lives.
Ownership data: confirming team and user records against your identity provider so owners resolve correctly.
Scorecard rules: translating each Cortex scorecard rule into a plugin, a custom check or a manual process.
Adoption: moving docs into TechDocs, retraining service owners and retiring the old portal on a date both sides agree.

Each area needs named owners on your side, because they depend on knowledge that lives in your services and org chart, not in the framework.

What drives the cost of moving off Cortex to Backstage?

Cost depends mostly on the size and messiness of your service catalog, how many Cortex scorecards you rely on, and how much custom integration you have. Cost has two main parts. One-time costs cover design, catalog import, scorecard rebuilding, identity integration and migration testing. Recurring costs cover hosting the Backstage instance, the PostgreSQL database and the Kubernetes cluster, plus the engineering time needed to upgrade Backstage and maintain plugins. Your Cortex subscription ends only if you stop paying for it, so compare the full Cortex contract with the ongoing Backstage operating cost, not just the license line. Ask your team for an estimate of its own hours before comparing totals.

Does a self-managed Cortex still need a license and vendor access?

Yes. Cortex's self-managed deployment runs in your own Kubernetes cluster through a Helm chart, but it requires a JWT license key and an access token from the Cortex account team, along with a PostgreSQL database. Hosting it yourself moves the data and infrastructure under your control, but it does not remove the subscription. Before you decide, confirm with Cortex which upgrade, support and update channels the license covers, what happens to access if the subscription lapses, and how the license key is rotated. Those answers determine whether a self-managed Cortex solves your residency or lock-in concern.

How do Backstage's release lines affect upgrade work after migration?

Backstage publishes a main release line monthly, on the Tuesday before the third Wednesday of each month, and a next release line weekly on Tuesdays, as described in its versioning policy. Your team does not have to take every release, but it should choose a cadence and stick to it. Plan for regular dependency and plugin updates, test them in a non-production environment, and track breaking changes in the plugins you use. Ask any outside partner how it handles upgrades, whether that is a retainer covering upgrade work or a fixed-scope upgrade, and what testing it performs before a change reaches production.

Which scorecard features need plugins or custom work in Backstage?

Backstage gives you the catalog, templates, TechDocs and a plugin ecosystem, but scorecards and maturity tracking are not a single built-in feature you switch on. Expect to address scorecard criteria through catalog metadata, a scoring plugin or custom code that reads entity data and reports results. Verify each plugin's maintenance status, license and compatibility with your Backstage version before you rely on it. Scorecards that depend on data from your CI, security scanners or cloud accounts will need custom connectors, and those connectors become part of the software you maintain.

What should we ask for in a fixed-scope quote for this migration?

Ask for a written scope that lists the Cortex entities and scorecards in scope, the target Backstage architecture, the hosting environment and the systems to integrate, such as your identity provider and source control. Request named deliverables for the catalog import, scorecard rebuild, TechDocs setup, documentation, testing and handover, plus the acceptance criteria for each. Ask what is excluded, how changes to scope are priced, what support follows go-live, and whether an upgrade retainer is available. DeployOpen works from a written scope and provides a quote from it, and it does not publish a price list.

What should we confirm about Cortex data before we start the move?

Confirm exactly what Cortex can export, in what format and with what fidelity. Check which entities, owners, custom fields and scorecard results you need to keep, and whether historical scorecard data matters to audits or reporting. Confirm the Cortex data export terms in your contract, and whether any data stays in Cortex's systems after the subscription ends. Decide early whether historical records will be archived in your own storage, since a Backstage catalog holds current entity state rather than a full history of past scores.

How DeployOpen scopes and hands over a Backstage replacement

DeployOpen plans, implements, customizes, integrates, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure, including Backstage for teams replacing Cortex. We agree scope, deliverables and timelines in writing before any work starts, so the migration of service ownership and scorecard data is defined up front.

How we scope

Inventory which Cortex entities, owners, teams and scorecard rules must move to Backstage catalog kinds.
Confirm where your cloud accounts, data centers or air-gapped networks will host Backstage and its PostgreSQL database.
Agree in writing which plugins, custom scorecard logic and identity provider integrations are in and out of scope.

How we build

Set up the Backstage instance and convert ownership data into catalog-info.yaml descriptor files kept next to the code.
Build or configure scorecard and maturity checks as plugins or custom code, and document each rule and its data source.
Test the portal, its integrations and access controls, then harden and integrate it with your existing CI and identity systems.

How we hand over

Deliver written documentation covering the architecture, catalog conventions, TechDocs setup and operating runbooks.
Walk your platform and engineering teams through ownership of the catalog, templates and plugin upgrades.
Provide evidence for internal controls and compliance assessments, while independent auditors and certification bodies issue any formal reports.

How we support

Offer ongoing support, backups, version upgrades and continuous testing as a retainer after handover.
Plan upgrades around Backstage's published release cadence, confirming the timing with your own change process.
Ask any provider for a quote built from the written scope, including who pays for hosting, licenses and staff time.

Open-source alternatives to Cortex