Does self-hosting Cortex cost less than running Backstage?
Self-hosting Cortex does not remove the subscription, so it rarely lowers the licence line on its own. The self-managed deployment still needs a JWT license key and access token from the Cortex account team, a PostgreSQL database and your own Kubernetes cluster on EKS, AKS, GKE or a locally installed distribution, according to the Cortex self-managed documentation. Self-hosting therefore changes where Cortex runs and who pays for the infrastructure, but the per-seat fee remains. If your renewal or data residency driver is the location of the portal, the comparison should be drawn against the full cost of the Cortex subscription plus your own cluster and database.
Backstage carries no license fee from the project. It is an Apache-2.0 framework with no paid edition from the project itself, so its cost sits in infrastructure, initial build, plugin upkeep and staffing. Those costs recur in different ways: the Kubernetes and PostgreSQL footprint runs continuously, while building catalog entities, Software Templates and TechDocs is largely one-time work that grows with scope. Plugin upkeep is the recurring item that teams most often underestimate, because the versioning policy ships a monthly main release line and a weekly next line that your team must track.
The result depends on team size, plugin scope and in-house skills, and no general figure settles it. Ask a Cortex account team for a written quote covering seats, the license term and any support tier, and ask it to confirm which self-managed upgrades are required to stay supported. For Backstage, price your own engineers' time on plugins, upgrades and on-call support, then compare that against the subscription. Request a fixed-scope estimate from any implementation partner so the staffing assumptions are explicit and can be checked against your environment.
Which cost components move on each side
This table compares each cost component of a self-managed Cortex deployment with the same component in a self-hosted Backstage portal. Read each row for who is paid, whether the cost is one-time or recurring, and what drives it up or down. The main takeaway is that self-hosting Cortex keeps the subscription, while Backstage moves the spend into infrastructure, staffing and plugin upkeep.
| Cost component | Cortex self-managed | Self-hosted Backstage |
|---|---|---|
| Subscription or license | Recurring fee paid to Cortex; the self-managed edition still requires a license key and access token from the Cortex account team. Ask what is included and how seats are counted. | No license fee. Backstage is Apache-2.0 licensed and has no paid edition from the project itself. Recurring cost is staff time, not a vendor invoice. |
| Kubernetes infrastructure | Recurring cloud or data center cost paid to the cloud provider or hardware owner, on EKS, AKS, GKE or a locally installed distribution. | Recurring cost paid to the cloud provider or hardware owner for the same kind of cluster. Sizing depends on plugins and catalog volume. |
| PostgreSQL database | Recurring cost for a managed or self-run PostgreSQL instance, paid to the cloud provider or internal team. | Recurring cost for PostgreSQL, which Backstage uses in production. Each backend plugin gets its own logical database, so plan capacity and backups per database. |
| Initial implementation | One-time cost for install, Helm configuration and identity setup, paid to internal staff or a partner such as DeployOpen under a written scope. | One-time cost for building the portal, configuring authentication and catalog ingestion, and writing catalog-info.yaml files, paid to internal platform engineers or a partner. |
| Migration and data mapping | One-time cost to export descriptors through the REST API and rebuild ownership and scorecard data, paid to internal staff or a partner. | One-time cost to convert Cortex entities into Backstage descriptors and rebuild scorecards with plugins or custom checks, paid to internal engineers or a partner. |
| Plugin upkeep | Limited to what the vendor ships. Changes to scorecards or integrations depend on the vendor roadmap and configuration options. | Recurring engineering time to maintain plugins, custom checks and integrations as Backstage releases change. This is the largest ongoing effort to plan for. |
| Upgrades and security patches | Recurring staff time to apply self-managed releases and keep them supported, paid to internal staff and covered by the license. | Recurring staff time to follow the monthly and weekly release lines, test upgrades and apply security backports, paid to internal staff or a retainer partner. |
| Support and internal skills | Vendor support is covered by the subscription. Internal skills are needed mainly for Kubernetes and PostgreSQL operations. | No vendor support contract by default. Needs in-house skills in React, Node.js, Kubernetes and PostgreSQL, or a paid support retainer. |
What moves the Cortex and Backstage comparison
The same six forces shift both sides of the comparison. Seat counts and catalog size drive Cortex's subscription, while integrations, upgrades and staffing drive the in-house cost of running Backstage. Check each one against your own environment before you compare totals.
Seats and catalog size
Cortex pricing is tied to the people and catalog entities you license, so a larger engineering organization or a bigger catalog raises the recurring subscription. Backstage has no license fee for either, but a larger catalog means more entities to ingest, more database load and more ownership data to keep accurate. Ask Cortex how seats and entities are counted for a self-managed license, and size your PostgreSQL and Kubernetes capacity against your real entity count.
Integrations and plugins needed
Every source you want in the catalog, such as Kubernetes, CI systems, cloud accounts and incident tools, adds either a Cortex integration or a Backstage plugin. Backstage's plugins are open source, but each one needs installation, configuration and ongoing maintenance by your team or a partner. List the integrations you need on day one and count how many already exist as maintained plugins versus custom work.
Edition and deployment model
A self-managed Cortex deployment still requires a license key and access token from the vendor, so hosting it yourself moves infrastructure cost to you without removing the subscription. Backstage is Apache-2.0 licensed and has no paid edition from the project. Confirm with Cortex exactly which components its self-managed license covers, including support, upgrades and any feature tiers, and whether the license requires outbound network access.
Availability and backup requirements
A portal that engineers use for deployments and ownership lookups needs high availability, tested backups of its PostgreSQL databases and a restore procedure. With Cortex, the vendor's software is yours to run but the database and cluster are your responsibility. With Backstage, you own the application, the database layout and the caching layer, which Backstage supports with Redis, Memcache, Infinispan or in-memory caching. Price the on-call and recovery testing these requirements imply.
Upgrade cadence and security backports
Backstage's main release line ships monthly and the next line ships weekly, so your team must plan regular upgrades to stay current. The versioning policy says high and critical vulnerabilities are backported to releases from the last 6 months where feasible, so falling behind that window can leave you without fixes. Cortex upgrades are delivered through the vendor's chart, which shifts the timing work to the vendor but still requires your cluster changes. Estimate how many upgrade cycles per year your team can absorb.
Existing platform engineering skills
The largest hidden cost in self-hosting Backstage is staff time. Someone must own TypeScript and Node.js plugin code, Kubernetes operations, authentication resolvers and the upgrade pipeline. Teams that already run Kubernetes and maintain internal tooling absorb this work more easily than teams that do not. Ask whether you have, or can hire, people who can maintain the portal for the long term, and whether a fixed-scope implementation partner or a retainer would cover the gap.
How to build the comparison with your own numbers
This sequence turns the cost components into a comparison built on your own contract, infrastructure and staffing figures. Each step produces a number or a written answer you can place side by side before deciding whether to stay on a licensed Cortex deployment or move to a self-hosted Backstage portal.
Pull your current Cortex contract terms
Ask your procurement or finance lead to gather the signed order form, renewal date, seat count, and any amendments, then list what the license covers: the number of seats or entities, support tier, and whether self-managed deployment is included. Confirm with your Cortex account team in writing whether the self-managed license key and access token are priced separately from the SaaS subscription. The step is done when you have one page that states the annual subscription amount, the renewal terms, and the license scope in your own words.
Confirm self-managed terms with the vendor
Send Cortex a short written list of questions covering what the self-managed license permits, how license keys are renewed, whether upgrades and new releases are included, and what happens to support if you run an older version. Ask whether the license depends on internet access to pull images, since your network team will need that answer. The step is done when the vendor's answers are attached to your file and you know which costs remain even if you stop using Cortex's hosted service.
Price your Kubernetes and PostgreSQL footprint
Work with your cloud or platform team to pull the last three months of bills for the Kubernetes cluster, node pools, managed PostgreSQL, storage, backups and egress that a self-managed Cortex deployment would use. Separate the share attributable to the portal from shared platform costs, and note which items are reserved, committed or on demand. The step is done when you have a monthly figure for infrastructure and a list of the drivers, such as node count, database size and backup retention, that would change it.
Count the plugins your scorecards need
Inventory the scorecard rules, ownership views and catalog integrations your teams use in Cortex today, such as service ownership, on-call data, CI status and repository metadata. Map each one to a Backstage catalog feature, a community plugin, or a custom check you would have to write and maintain, and mark the ones with no clear equivalent. Compare this list against the Cortex vs Backstage and scorecard pages before deciding. The step is done when you have a numbered list of plugins and custom checks with an owner and a note on whether each one is available, partial or missing.
Estimate monthly staff hours for upgrades
Ask the platform team to record the hours spent on the last two or three Backstage or Cortex upgrades, plugin fixes and dependency updates, including testing and rollback. Backstage's main release line ships monthly, and its versioning policy backports high and critical vulnerability fixes to releases from the last 6 months where feasible, so plan for a recurring cadence. Separate planned upgrade work from unplanned incidents. The step is done when you have an average monthly hours figure per role, with a note on which tasks you can staff in-house and which you would outsource.
Build a three-year cost sheet
Place the subscription, infrastructure, staff time and any outside support in one spreadsheet with separate rows for one-time costs such as migration, plugin build-out and training, and recurring costs such as subscription, cloud and upkeep. Keep each figure tied to the source that produced it, and mark the assumptions you cannot yet confirm. Run a version with higher staff hours and a version with lower ones so the decision does not hinge on one estimate. The step is done when both scenarios show the one-time and recurring totals side by side for Cortex and for self-hosted Backstage.
Request a fixed-scope written quote
Send DeployOpen a written brief with your catalog entity count, the scorecards and ownership rules to rebuild, your identity provider, your cloud or data center targets, and the compliance evidence you must produce. DeployOpen works from agreed written scope, so the quote follows from the deliverables, timelines and exclusions you confirm in that document. Ask for the quote to list one-time implementation items separately from any optional retainer for upgrades and support. The step is done when you hold a fixed-scope proposal you can compare line by line with the cost sheet.
Where Backstage costs land in your budget
Backstage carries no license fee. The project is released under the Apache License 2.0 and there is no paid edition from the project itself, so the recurring cost of a self-hosted portal is infrastructure, developer time and upkeep, not a subscription. Infrastructure means a PostgreSQL database in production (SQLite is for development), plus a caching layer if you choose one: Redis, Memcache, Infinispan or in-memory caching are all supported. Ask your platform team which managed or self-run PostgreSQL service, backup policy and cache sizing they would use, and what each one costs in your own cloud or data center account, since those prices come from your provider, not from Backstage.
Most of the effort is build work, and it is paid for in engineering hours rather than licenses. Your team will assemble the app from Backstage's core features (the Software Catalog, Software Templates and TechDocs) and then configure the plugins you need. Scorecards are not packaged in Backstage, so their setup is also build work. Plan for the people who will write catalog-info.yaml descriptors, author templates, maintain TechDocs MkDocs sites and wire up sign-in resolvers so every provider maps to the same identity. Upkeep is the recurring part: Backstage's main release line ships monthly and its next release line ships weekly, and the versioning policy says the project supports exactly two adjacent even-numbered Node.js releases, which were Node.js 22 and 24 as of Backstage 1.46.0. Each Node.js change and each plugin update lands on your team, so confirm who owns that calendar and how much of it you can absorb.
When you request a quote for a self-hosted Backstage portal, ask the implementation partner to split the estimate into one-time build work (app scaffolding, plugins, scorecard rules, TechDocs pipelines, authentication) and recurring work (upgrades, dependency and security patching, plugin maintenance, on-call). The Backstage versioning policy says high and critical severity vulnerabilities will be backported to releases from the last 6 months where feasible, which shows why staying on a supported release line matters for security. Ask also what happens to the portal when the original builders move on. Those answers, not a license line, determine how Backstage's total cost compares with a subscription over the years you expect to run it.
Questions buyers ask before comparing costs
Does self-managing Cortex remove the subscription?
No. Cortex's self-hosting documentation says a self-managed deployment still requires a JWT license key and an access token from the Cortex account team, so the subscription remains in your budget even though the portal runs in your own Kubernetes cluster. What changes is where the workload runs. You still pay for the cluster, the PostgreSQL database, backups, upgrades and the staff who operate them. Ask Cortex to confirm in writing what the license covers, how seats are counted, and whether the license is renewed on the same cycle as a SaaS contract.
How much effort does a Backstage build take, and what drives it?
The effort depends mostly on how many systems you connect and how much you customize. Backstage's core features are the Software Catalog, Software Templates and TechDocs, and the architecture overview lists Kubernetes and search plugins as well. Each catalog source, each entity kind you model, each scorecard rule and each template adds design and testing work. Your engineers must also learn the Backstage codebase, since it is a framework rather than a finished product. Ask any implementation partner to break the estimate into catalog modeling, plugin integration, templates, authentication and operations, and to state which of those items are fixed in the written scope.
Can our team build and run Backstage without outside help?
Many teams can, provided they have engineers comfortable with TypeScript, Node.js, Kubernetes and PostgreSQL. The versioning policy requires you to track monthly main releases and weekly next-line releases, and to keep up with Node.js versions, since Backstage supports exactly two adjacent even-numbered Node.js releases. High and critical vulnerabilities are backported to releases from the last 6 months where feasible, so you must upgrade regularly to stay covered. Be honest about spare capacity: if no one can own upgrades for the portal over the long term, the internal cost is the main risk. An outside team can plan, build or harden the portal, but your staff still need the skills to run it.
How long does a migration from Cortex take, and what sets the timeline?
No duration is fixed by the researched facts, so treat any number you hear as a claim to verify. The main drivers are the number of entities to convert, how many of your scorecards must be rebuilt with plugins or custom checks, how many data sources feed ownership information, and whether teams can cut over in stages. Ownership data must stay in sync during cutover, which usually makes a parallel run the longest phase. Ask for a written plan that lists each phase, the entity count and the acceptance criteria, and confirm which steps depend on your own teams, such as approving catalog-info.yaml changes.
How does authentication setup affect the cost of a Backstage portal?
Authentication affects both the build and the security review. Backstage ships 19 built-in authentication providers, including GitHub, GitLab, Google, Azure, Okta, Auth0 and generic OIDC, so the provider itself is rarely the hard part. The cost comes from the sign-in resolvers, which must map each provider to one consistent identity, and from excluding guest access in production, as the authentication documentation advises. Identity mapping across several providers, group membership sync and access rules for catalog entities add design and testing time. If you already run an identity provider, confirm its integration with your team before estimating the work.
What does ongoing support look like after the portal goes live?
Ongoing cost is recurring and usually larger than the first build. It covers monthly and weekly Backstage upgrades, dependency and Node.js updates, plugin maintenance, monitoring, PostgreSQL backups, catalog data quality and onboarding of new teams. DeployOpen offers ongoing support, upgrades and continuous testing as retainers, and most engagements are fixed-scope with scope, deliverables and timelines agreed in writing before work starts. Ask any provider which upgrades are included, how security patches are handled, what response times are committed in writing, and what happens to the portal if the engagement ends.
When should we ask for a quote, and what should it include?
Ask for a quote once you have a written list of systems to connect, entity types to model, scorecard rules and teams in scope, because those inputs determine the price. DeployOpen does not publish a price list. A quote follows from the written scope, so include your current Cortex seat count and renewal date, the hosting target, your authentication providers and your compliance needs. Ask the quote to separate one-time work from recurring retainers, state assumptions, and name who pays for Kubernetes, PostgreSQL and Cortex licensing, so the total cost of ownership can be compared fairly.
When a fixed-scope review makes sense
Bring in outside help before the renewal date, not after it, when the cost model depends on things you cannot yet count. The two common cases are plugin scope and migration effort. A Backstage portal is only as complete as the plugins your teams need, and each plugin brings its own configuration, data source and upkeep. If nobody has listed the integrations that must work on day one, any estimate for a self-hosted portal is a guess. The same holds for migration: the work to move ownership data, scorecards and templates out of Cortex depends on how many entities exist, how consistent their descriptors are, and which reports leadership relies on. A written scope turns those unknowns into named deliverables before anyone commits budget.
A fixed-scope review examines the inputs that drive cost, not the outcome of a decision. In practice that means reviewing your current Cortex seat count and contract terms, the entity types and descriptor fields in use, the scorecards and integrations that must be reproduced, the identity provider and sign-in resolvers that Backstage would need, and the hosting footprint for Kubernetes and PostgreSQL in your own environment. Ask the reviewer to separate one-time work (plugin selection, migration, hardening) from recurring work (upgrades on the monthly and weekly release lines, security backports, plugin maintenance). The deliverable should be a written plan with agreed scope, timelines and a quote that follows from that scope. Confirm with the vendor, in writing, what your current license terms require before you decide whether the review should be completed before or after notice is given.
How DeployOpen scopes a fixed-price Backstage implementation
DeployOpen plans and implements self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For a Cortex cost vs self-hosted Backstage decision, we start from a written scope that separates the Cortex subscription you may still owe from the Backstage build, hosting and upkeep work.
How we scope
- Inventory the Cortex contract terms, license needs and the services you would retire at cutover
- Agree in writing which Backstage features, plugins and data sources are in and out of scope
- Confirm the Kubernetes and PostgreSQL hosting you already run or plan to run for the portal
- Ask for a quote that itemizes build, hosting setup, plugin work, testing and handover separately
How we build
- Deploy Backstage in your infrastructure with PostgreSQL, one logical database per backend plugin
- Configure authentication with sign-in resolvers so every identity provider maps to one user
- Model services, owners and APIs as catalog-info.yaml descriptors that your teams review in Git
- Test catalog imports, templates and TechDocs builds in a staging environment before cutover
How we hand over
- Document the deployment, configuration, upgrade steps and owner responsibilities for your team
- Set up a repeatable upgrade routine that follows the Backstage release line you choose
- Provide runbooks for backups, database recovery and the Node.js versions the project supports
- Train platform and security staff on the catalog, templates and plugin configuration you received
How we support
- Offer ongoing support, upgrades and continuous testing as a retainer after the fixed-scope work ends
- Keep dependency and plugin updates tested before they reach production portals
- Review security advisories against your deployed Backstage version and plan patches with your team
- Confirm retainer scope, response expectations and the systems covered in writing before signing
