Atlassian Compass cost vs self-hosted Backstage: where the money moves
Backstage carries no license fee, so self-hosting moves the cost into infrastructure, implementation and people. Backstage is an Apache-2.0 framework with no paid edition from the project itself, so the question for a platform leader facing a Compass renewal or the DX transition is what you will pay to run it, not what you will pay to license it. On the Compass side, pricing is billed per full user each month under Standard and Premium tiers. Take your current rates from your own Atlassian order form, because the figures depend on your contract and currency. The DX price after the transition is not published in the sources behind this page, so ask Atlassian for it in writing before comparing totals.
On the self-hosted side, the recurring costs are the cluster and compute that run the Backstage backend and frontend, a PostgreSQL database (Backstage uses PostgreSQL in production and gives each backend plugin its own logical database), storage and backups, and the engineering time to keep up with monthly and weekly release lines and backport security fixes. Plugin work is usually the largest variable, since integrations with your source control, CI and cloud accounts each need configuration or custom code. Confirm with your own engineers which costs already sit in existing budgets, such as Kubernetes clusters and database operations, so you do not count them twice.
The answer depends on three inputs: your full user count, the plugin scope you need at launch, and the staff you already have who can run a Backstage instance. A small team with an existing platform group will see a very different balance from an organization that must hire for the work. Build a side-by-side model with one line per component (licence, hosting, database, migration, plugins, and platform staffing), mark which lines are one-time and which recur, and ask each vendor for the same assumptions so the comparison is fair. Consider DeployOpen's fixed-scope engagements as one way to price the implementation and the first year of hardening, with the quote following from a written scope.
Which cost components change when you move off Compass
This table compares each cost component of running Compass with running Backstage yourself, and marks whether it is paid once or recurs. Use the Compass column to check your current Atlassian billing and any DX terms you receive, and the Backstage column as work your own team or an outside partner would carry. The main takeaway is that self-hosting removes the subscription line but keeps recurring costs for hosting, the database, upgrades and platform staff.
| Cost component | Atlassian Compass | Self-hosted Backstage | One-time or recurring |
|---|---|---|---|
| Subscription or license | Billed per full user each month on Standard or Premium; confirm current rates with Atlassian | No license fee; Backstage is Apache-2.0 with no paid edition from the project | Recurring for Compass; none for the Backstage software |
| Price after DX transition | Not published in our sources; request written terms from Atlassian or DX | Not applicable if you keep Backstage | Recurring if you accept DX |
| Infrastructure | None on your side; Atlassian hosts the service | Compute to run the backend and frontend, plus CI capacity to build and deploy them | Recurring |
| PostgreSQL | Not applicable | Production database; each backend plugin gets its own logical database through Knex | Recurring for hosting, backups and upgrades |
| Implementation | Setup of components, teams and integrations, mostly internal time | Initial build of catalog, sign-in, templates and TechDocs; scope it in writing if outsourced | One-time |
| Migration | Export from compass.yml files and UI-created components | Convert to catalog-info.yaml entities, map teams and rebuild scorecards | One-time |
| Plugin work | Built-in integrations come with the subscription; confirm coverage for your tools | Plugins for each integration you need, built or maintained by your team or a partner | One-time build, then recurring maintenance |
| Upgrades | Handled by Atlassian as part of the service | Main line ships monthly, next line weekly; high and critical fixes backported to the last 6 months where feasible | Recurring |
| Support and platform team | Vendor support under your subscription terms | No vendor support by default; staff or a retained partner cover on-call, TypeScript and plugin skills | Recurring |
What moves the Compass versus Backstage comparison most
Compass pricing scales with people, while a self-hosted Backstage portal scales with infrastructure and the engineers who run it. The cards below show which variables push the comparison toward each side, so you can model your own numbers before asking for a quote.
Number of full users billed
Compass charges per full user each month, so headcount with edit or admin access is the main recurring line on that side. Backstage does not charge per user, but more users means more sign-in traffic, more catalog views and more support questions. Ask Atlassian how it counts full users and whether read-only viewers are billed, and count your own engineers who will edit entities.
Catalog size and entity count
Both sides grow with the number of components, APIs, systems and teams. Backstage stores entities in PostgreSQL and ingests them from catalog-info.yaml files, so a larger catalog raises database size, ingestion load and the effort to keep ownership data current. Compare how many components already have a Compass definition and how many exist only as UI records that must be exported.
Jira, Bitbucket and custom plugins
Compass integrates natively with Jira and Bitbucket, which lowers integration work on that side. Backstage reaches the same systems through plugins, and each custom plugin you need adds build, testing, upgrade and ownership effort on the platform team. Count the integrations you use today, mark which ones have maintained community plugins, and budget for the rest as recurring maintenance.
Availability and on-call expectations
Compass is operated by Atlassian, so uptime and incident response sit in its service terms. A self-hosted Backstage portal makes your team responsible for hosting, database backups, patching and on-call coverage for the portal itself. Decide early whether the portal is a business-hours tool or a dependency for deployments and incident response, because that choice sets how much on-call capacity you must fund.
Data residency and access control
Self-hosting lets you keep catalog data, ownership records and any linked documentation inside your own cloud account or data center. That matters when catalog metadata reveals sensitive architecture details. Configure sign-in resolvers so each identity provider maps to one user, and avoid guest access in production, as the Backstage authentication guidance advises. Confirm where Compass stores data for your region before you assume a difference.
Platform team skills and upgrade load
Running Backstage well needs people who can work with TypeScript, Node.js, Kubernetes, PostgreSQL and the plugin ecosystem. Backstage ships a monthly main line and a weekly next line, so someone must schedule and test upgrades. Existing skills on the platform team reduce the cost of this side, while a team without them should price in hiring, training or an implementation partner for the first year.
Where the recurring Backstage cost sits
The recurring cost of self-hosted Backstage sits in four places once the portal is live: the hosting footprint for the Backend and frontend, a production PostgreSQL database, the caching layer, and the upgrade work that keeps the portal current. Backstage uses PostgreSQL in production and gives each backend plugin its own logical database through Knex, so the catalog, scaffolder and other plugins each add tables and data to the same database service. Ask your platform team to size that database for backups, point-in-time recovery and failover, because these are the items that keep running every month whether or not anyone adds a new feature.
Caching is a choice you make early. The architecture overview lists Redis, Memcache, Infinispan and in-memory caching as options, so you can run a managed or self-hosted Redis for a shared cache or accept in-memory caching for a smaller instance. Each option changes what you operate. A shared cache is one more service with its own patching, monitoring and failover, while in-memory caching ties state to a single process. Decide this with the team that will carry the pager, not after go-live.
Upgrades are the largest recurring labor line. The main release line ships monthly, on the Tuesday before the third Wednesday of each month, and the versioning policy says high and critical vulnerabilities are backported to releases from the last 6 months where feasible. Node.js support also follows that policy: as of Backstage 1.46.0 it covers Node.js 22 and 24. Confirm the current release line and supported Node.js versions in the versioning policy before you cost upgrades, and budget time to test plugins against each release, since plugin updates often trail core changes.
How to build the Compass versus Backstage model with your own numbers
This sequence turns the cost comparison into a model built from your own invoices, quotes and rate cards, so each cost line has a named source. The result is a three-year total you can test against changes in user count before you decide.
Export current Compass invoice lines
Finance and the account owner pull the last twelve months of Atlassian invoices and list each Compass line by tier, Standard or Premium, and by billing basis. Record the number of full users billed per month, since Compass is priced per full user. Confirm the currency, any tax or reseller markup, and whether any discount applies. The step is done when you have one table of monthly Compass cost by tier that reconciles to the invoices.
Get the DX price in writing
Ask Atlassian, in writing, what DX will charge for the catalog and scorecard capabilities you use, the billing unit, the term, the start date and any price protection. Do not assume the DX price matches Compass. Treat the answer as an open input until it arrives, and mark it as unconfirmed in the model if Atlassian has not yet provided a figure. The step is done when the quote is on file and the model shows it as a sourced line.
Count components, teams and users
Platform engineering exports the number of components, APIs, systems, groups and users that would need to exist in the new catalog. Pull component counts from your Compass exports and repositories, and team counts from your identity provider. Note which components are inactive, so they do not inflate the estimate. The step is done when you have counts for each entity kind and a user count that matches the billing basis used in step one.
Price hosting and PostgreSQL internally
Infrastructure and finance price the Kubernetes capacity, PostgreSQL, storage, backups, networking and the caching layer for a Backstage instance, using your own cloud or data center rate card. Backstage is Apache-2.0 licensed with no paid edition from the project, so this line replaces the subscription cost rather than adding a license fee. Separate the one-time setup from the recurring hosting and database cost. The step is done when each infrastructure line has a rate card reference and a monthly figure.
Scope migration and plugin work in writing
Platform engineering and any implementation partner agree a written scope covering catalog import, template work, authentication and identity resolvers, TechDocs setup, and any plugin integrations you need. Ask each partner for a fixed-scope quote with deliverables and timelines stated in the document. Keep one-time migration costs in a separate column from recurring support. The step is done when the scope and quotes are attached to the model with no undefined line items.
Assign platform staff hours to run the portal
The platform lead estimates recurring staff hours for upgrades, plugin maintenance, catalog quality, on-call and security patching. Backstage ships a main release line monthly and a next line weekly, and high and critical vulnerabilities are backported to releases from the last six months where feasible, so budget time for regular upgrades. Convert hours to cost using your internal loaded rate. The step is done when recurring staff cost is a named line in the model, with the assumptions written beside it.
Compare three-year totals with a sensitivity check
Finance builds a three-year view that separates one-time costs from recurring costs for both the Compass or DX path and the self-hosted Backstage path. Then run a sensitivity check by changing the user count up and down, and note the point where the cheaper option changes. Label any hypothetical scenario as illustrative. The step is done when the decision memo states the three-year totals, the break-even user count and which quoted figures are still unconfirmed.
When staying on a commercial portal is the cheaper answer
A small Compass footprint, a team with no platform engineers, or a short remaining contract can make the subscription the cheaper answer. Backstage is free to download under the Apache License 2.0, but running it is not free. A small catalog of a few dozen components may not justify the hosting, the PostgreSQL database, the plugin configuration and the upgrade work that come with a portal you operate yourself. If nobody on the team has time to own a Node.js application, review plugin updates or respond to security backports, the monthly Compass fee may buy more predictable effort than the staff hours it would take to replace it. Before deciding, ask Atlassian for the current Compass pricing for your number of full users, and ask DX what its transition terms cover, since the DX price after the transition is not yet known to us.
Self-hosting a commercial product does not automatically remove the subscription. Cortex and OpsLevel both document self-managed deployments that still require a vendor license key or license file, as described in the Cortex self-managed documentation and the OpsLevel self-hosted documentation. Those editions move the hosting cost to your side while keeping the license fee. OpsLevel's published minimums for its self-hosted edition are 16 CPU, 16 GB of memory and 120 Gi of disk for production. These are OpsLevel's figures for its own product, not requirements for Backstage, but they show what a licensed self-managed edition asks of your infrastructure before any license cost is counted.
Questions buyers ask before comparing Compass with Backstage
How much does self-hosting Backstage actually cost?
No single figure applies, and this page does not give one. Self-hosted Backstage has no license fee from the project itself, since it is Apache-2.0 licensed, so the cost sits in components: the compute and storage that run the portal, a managed or self-run PostgreSQL database, build and deploy pipelines for the portal, the engineering time to build and customize plugins, and the platform team that upgrades and supports it. Ask for your own hosting rates, your staff loaded costs, and the number of engineers who will maintain the portal. Those three inputs, together with the scope of plugins you need, determine the total. Compare the result with your current Compass subscription, your expected Compass renewal or DX terms, and the time your engineers spend on catalog upkeep today.
How long does a Compass to Backstage migration take?
The duration depends mainly on how many components, teams and scorecards you move, how clean your existing data is, and which integrations you need to rebuild. Components already defined in compass.yml files convert more predictably than components created only in the UI, which must be exported and reviewed first. Plan time for identity provider mapping, sign-in resolver configuration, a review of ownership, and a parallel period while teams check their entities. Ask for a written scope that lists the number of components, the scorecard rules to rebuild and the acceptance criteria before work starts. Timelines should follow from that scope, not from a generic estimate.
Can our internal team run Backstage without outside help?
Many teams can, but it depends on skills in three areas. Your team needs Kubernetes experience to deploy and operate the portal, PostgreSQL administration to run the database that Backstage uses in production, and TypeScript and React skills to build or change plugins. Backstage also has a release cadence: the main release line ships monthly and the next line ships weekly, so someone must own upgrades. Assess whether you have at least one engineer comfortable with each area and whether that person has time beyond the initial build. If a skill is missing, a fixed-scope implementation can cover the build and handover, and a retainer can cover upgrades later.
What do we need to provide for a Backstage implementation?
The work needs named owners on both sides before it starts. Assign a product owner who can decide catalog conventions, an engineering owner for the portal platform, and a security contact who approves identity and access design. Access is also required: read access to the Git repositories that hold compass.yml files and service code, administrative or export access to Compass, an administrator on your identity provider so teams and groups can be mapped, and access to the cloud accounts or clusters where Backstage will run. Agree these access requests and the approval path in the written scope, since delays in access are a common cause of schedule slippage.
Does a fixed-scope implementation reduce the recurring cost?
A fixed-scope implementation covers one-time work: scoping, configuring Backstage, converting catalog data, building agreed plugins and integrations, hardening and documenting the result, and handing it over. It does not remove recurring costs. Your hosting, database, and staff time still recur, and ongoing support, upgrades and continuous testing are available as a separate retainer. Ask for the scope to state clearly which items are delivered once and which need an ongoing arrangement, so you can compare the recurring side with your current Compass subscription on equal terms.
Does self-hosting Compass remove the subscription?
Compass is a cloud product, and this page does not treat it as self-hostable, so moving to Backstage is a change of platform rather than a change of hosting. Other commercial portals show why this distinction matters: some vendors offer self-managed editions that still require a vendor license key or license file. Before you compare costs, confirm with Atlassian and DX what your post-transition terms will be, and avoid assuming that any self-managed option removes the commercial license. Backstage itself carries no project license fee.
What security checks does a self-hosted Backstage portal need?
A self-hosted portal holds ownership data, service metadata and links to your repositories, so it needs the same access controls as other internal systems. Configure sign-in resolvers so every identity provider resolves to the same user, and do not offer guest access in production. Track the project's security policy: high and critical vulnerabilities are backported to releases from the last six months where feasible, which means your upgrade process must stay current. Include these controls, along with your evidence collection, in the written scope so they are delivered and documented rather than left as later tasks.
How DeployOpen scopes a fixed-price Backstage implementation
DeployOpen approaches the cost question for Atlassian Compass cost vs self-hosted Backstage by first writing down what your portal must do and who runs it. Engagements are fixed-scope, so the cost components, deliverables and timeline are agreed in writing before work starts.
How we scope
- Inventory your Compass components, teams, scorecards and integrations to define the migration boundary
- Confirm which Compass features your organization actually uses, such as scorecards and Jira links
- Agree in writing who will run the Backstage instance, PostgreSQL database and plugin upgrades afterward
How we build
- Deploy Backstage inside your own cloud accounts or data centers, with PostgreSQL as the production database
- Configure the Software Catalog, Software Templates and TechDocs against your identity provider and sign-in resolvers
- Test catalog imports, authentication and scorecard rules in a non-production environment before cutover
How we hand over
- Document the deployment, catalog-info.yaml conventions, plugin configuration and backup procedures for your team
- Walk your platform engineers through upgrade steps tied to the Backstage release line you adopt
- Deliver a written record of what was built, tested and left for your team to own
How we support
- Offer ongoing support, upgrades and continuous testing as a retainer after the fixed-scope work ends
- Plan periodic upgrades around the monthly main release line and the weekly next release line
- Agree support boundaries, response expectations and retainer scope in writing with your quote
