Atlassian Compass vs Backstage: when each option fits
The decision in front of you is whether to accept the move from Atlassian Compass to DX or to run your own portal, and that choice should be made before you export anything. Compass suits a team that wants a managed cloud service, has a modest catalog, does not need its data held in a specific location, and has no platform team willing to operate software. In that case the cost of staying with a vendor-run product can be lower than the cost of running a framework yourself, provided the DX terms, pricing and data handling are acceptable to your procurement and security reviewers. Confirm the DX pricing and migration timeline directly with Atlassian, because the outline for this decision does not supply a figure you can rely on.
Self-hosted Backstage fits a different profile. It is an Apache-2.0 framework with no paid edition from the project itself, so the license cost is zero while the hosting, database, upgrades, plugin work and staffing become your responsibility. It suits organizations that need the catalog in their own infrastructure, want ownership expressed as catalog-info.yaml files in version control, and are prepared to keep up with its release cadence. Backstage's main release line ships monthly and its next line ships weekly, so a team without capacity for regular upgrades should count that work before committing. Its authentication model also requires deliberate sign-in resolver configuration and no guest access in production.
Four factors should settle the choice. First, catalog size: a small set of components is easier to rebuild by hand than a large estate with years of history. Second, residency rules: if your regulator or internal policy requires catalog data to stay on your servers, the managed option may not qualify without contractual and technical review. Third, in-house platform capacity: name who will patch, back up and support the portal after launch. Fourth, Jira and Bitbucket dependence: list every integration your teams rely on today, then check which ones Backstage plugins cover and which you must rebuild. Settle these four answers before you request a quote for any option.
Which option fits which scenario
This table matches common buyer situations to the option that usually fits better, with the condition that drives each answer. Read each row against your own constraints, since a single condition can change the result. The main takeaway is that the choice depends on where your catalog lives today, where data may reside, and whether you have people to run a portal.
| Scenario | Better fit | Reason and condition |
|---|---|---|
| Existing Compass catalog built from compass.yml files | Backstage, if you accept a migration project | Descriptor files map to catalog-info.yaml entities with some restructuring. Confirm how many components and scorecards need manual rework before committing. |
| Data residency or air-gap requirement | Backstage | Backstage runs in your own infrastructure, so catalog data stays inside your network. Confirm that every plugin and identity provider you need works offline. |
| Small team with no platform engineers | Compass, or a hosted option, until staffing changes | Running Backstage means someone owns upgrades, hosting, PostgreSQL and plugin maintenance. If no one can take that on, a managed service may be the safer choice for now. |
| Heavy Jira and Bitbucket use | Compass for out-of-the-box links, Backstage with plugins for control | Compass ties into Atlassian products natively. Backstage supports Bitbucket authentication, but Jira views depend on plugins you select and maintain. |
| Need for custom plugins and internal tooling | Backstage | Backstage is built around a plugin ecosystem and lets your engineers write and host their own plugins. Confirm the plugin skills you have before scoping the work. |
| Strict control over upgrades and versions | Backstage | You choose when to adopt each release line and apply security backports. This requires a regular upgrade routine on your side. |
| Uncertain future of Compass after the DX transition | Backstage, or a decision deferred until DX terms are clear | Compass is being phased out in favor of DX, and the DX price is not yet known. Get written terms before assuming the current tooling will continue. |
How Backstage models your catalog in YAML
Backstage describes your software in descriptor files, usually named catalog-info.yaml, that sit in the same repository as the code they describe. Each file declares one entity, and the kinds the Backstage descriptor documentation defines are Component, API, Resource, System, Domain, Group, User, Template and Location. A service might be a Component with a spec.owner pointing at a Group, a spec.system linking it to a System, and a spec.providesApis entry naming an API. API entities can carry OpenAPI, AsyncAPI, GraphQL or gRPC definitions, so the contract for an interface lives next to the team that owns it. Because the catalog is read from files in Git, changes to ownership or relationships go through the same review process as code, and the history of who changed what is kept in version control.
Compass stores component definitions in a different way: components can be declared in compass.yml files in the repository or created and edited in the Compass interface, and ownership is set through the Compass model. Confirm with Atlassian how Compass currently exports component data, which fields it includes and how relationships and team links appear in that export, before you plan the conversion. Map each Compass component type to a Backstage kind and decide up front whether a component that has no repository should become a Resource, a System or a plain Component with an explicit owner. Those mapping decisions, not the YAML syntax, usually take the longest to agree on.
Before you write any descriptors, check how your identity provider's groups will map to Backstage Group and User entities, since every spec.owner value must resolve to an entity that exists in the catalog. An owner reference that points to a missing group leaves the component without a clear team, which breaks ownership reports and scorecard checks that depend on it. Pick a naming convention for entity names and namespaces, and run a small pilot with a handful of repositories to confirm that the catalog displays the relationships you expect before importing the full estate.
Where your catalog data lives and who controls the portal
Compass is a cloud service that Atlassian runs, so your catalog sits in Atlassian's environment and changes follow its schedule. Self-hosted Backstage moves those decisions into your own infrastructure, along with the work to operate them. The four cards below cover the decisions that differ most between the two models.
Where the catalog is stored
Compass is hosted by Atlassian, so your component records, team links and scorecard results live in Atlassian's cloud. Backstage runs in your own infrastructure, and the project documents PostgreSQL as its production database, with SQLite for development. Each backend plugin gets its own logical database through Knex. Ask where your Compass data is hosted and which regions are involved, then confirm which cluster, database and backups your Backstage instance will use before you commit to a data residency position.
Who signs users in
Backstage ships 19 built-in authentication providers, including GitHub, GitLab, Google, Azure, Okta, Auth0, Bitbucket and generic OIDC. You choose the provider that matches your identity system. The authentication documentation advises configuring sign-in resolvers so that every provider resolves to the same identity, and it advises against guest access in production. Plan this before the first user logs in, because identities that resolve inconsistently can create duplicate users and ownership gaps in the catalog.
How upgrades reach your portal
Backstage's main release line ships monthly, on the Tuesday before the third Wednesday of each month, and the next release line ships weekly on Tuesdays. The versioning policy says high and critical severity vulnerabilities will always be backported to releases from the last 6 months where feasible. Under Compass, Atlassian schedules changes to the service. Under Backstage, your team decides when to take each release, so you need an owner, a test environment and a staging path for upgrades.
Compliance evidence for the portal
If your auditors ask how catalog access, sign-in and change control are handled, you need evidence from your own systems: configuration in version control, sign-in logs, deployment records and upgrade history. DeployOpen can plan, implement and document controls for a self-hosted portal and prepare that evidence for an assessment. Independent auditors and certification bodies issue the attestations or reports, and DeployOpen does not. Compass evidence sits partly with Atlassian, so ask what Atlassian provides and what you must collect yourself.
Hosting models by team situation
Teams that already run Jira and Bitbucket in Atlassian's cloud, and that accept Compass as a hosted service, carry the least operational work. Atlassian operates the service, so your platform team's effort goes into catalog content, ownership records and scorecard design rather than infrastructure. The trade-off is that the portal's hosting, availability and roadmap sit with the vendor, and the phase-out toward DX means this model is already changing.
- Lowest day-to-day operations. Atlassian runs the hosting, so no database, cluster or upgrade calendar falls to your team.
- Native Jira and Bitbucket context. Ownership and repository links stay inside tools your engineers already use.
- Hosting location is set by the vendor. Ask where catalog data is stored and which regions apply before you commit.
- Roadmap risk. Confirm the successor product, its terms, and the export options that come with the DX transition.
Before choosing this model, check the current Compass terms and transition dates with your Atlassian account team.
Organizations whose policies require catalog data, ownership records or service metadata to stay in their own cloud account or data center need a self-hosted portal. Backstage runs there as a framework: you deploy the backend and frontend, connect PostgreSQL, and manage sign-in. Backstage is licensed under Apache-2.0 and has no paid edition from the project itself, so the software licence cost is zero, while hosting and staffing become your responsibility.
- Data stays where policy says. Catalog entities are YAML descriptor files in your repositories, and the database runs in the environment you select.
- PostgreSQL in production. Backstage uses PostgreSQL in production and SQLite only for development, so plan for a managed or highly available database.
- Caching choices. Redis, Memcache, Infinispan or in-memory caching are supported, and the choice depends on your deployment architecture.
- Authentication controls. Backstage ships 19 authentication providers. Its Backstage authentication documentation advises sign-in resolvers that map every provider to one identity and no guest access in production.
Confirm where your policy places logs, backups and identity data, because those can sit outside the portal database and need the same controls.
Some teams want the Backstage model without running the platform themselves, so they evaluate a vendor-managed Backstage service. The software remains open source, but the operator, hosting location and upgrade timing are set by that vendor. Your evaluation should focus on who holds the data, how quickly releases reach you, and whether you can leave with your catalog intact.
- Release cadence. Backstage's main release line ships monthly and the next line ships weekly, so ask how fast the vendor applies each release.
- Security backports. The versioning policy says high and critical vulnerabilities are backported to releases from the last 6 months where feasible, so ask whether the vendor tracks that window.
- Node.js support. Backstage supports two adjacent even-numbered Node.js releases, and the vendor should state which ones it runs.
- Exit path. Confirm that your catalog-info.yaml files remain in your repositories, so you can move to an instance you run yourself.
Compare the vendor's contract, data location and exit terms with the cost of operating Backstage in your own environment before signing.
Cortex and OpsLevel both offer self-managed deployments, which move hosting into your infrastructure but keep the commercial relationship. Cortex installs through a Helm chart into your own Kubernetes cluster and requires a JWT license key and access token from its account team, plus a PostgreSQL database. OpsLevel installs through Replicated and requires a license file. In both cases, the self-managed edition still requires a vendor license, so self-hosting does not remove the subscription.
- Subscription continues. Both vendors require a license key or license file for the self-managed edition, so you pay the vendor and carry the infrastructure.
- Cortex requirements. The Helm deployment runs on EKS, AKS, GKE or a locally installed Kubernetes distribution, with PostgreSQL as a dependency.
- OpsLevel footprint. The vendor documents minimum specifications of 16 CPU, 16 GB of memory, capacity for at least 20 pods, and 24 Gi of disk for pilots or 120 Gi for production.
- Network exposure. OpsLevel documents that the instance must be reachable over the internet for push-based integrations, which may conflict with a restricted network policy.
Ask each vendor for its license terms, support scope and the total cost of both the subscription and the infrastructure it requires.
What a Backstage portal costs to run
Does Backstage itself have a license fee?
No. Backstage is an open source framework released under the Apache License 2.0, and the project itself offers no paid edition, so the software carries no license fee. Costs come from the work around it: hosting, a database, plugin development, upgrades and the people who run the portal. Check with any vendor offering a hosted or supported Backstage distribution, because that service is priced separately and is not the project's own product. Backstage is a CNCF Incubating project, which describes its governance rather than its cost. Confirm the license terms of any third-party plugin you plan to adopt, since plugins are licensed individually.
What does Compass charge, and what changes after the DX transition?
Compass is a subscription product, so its recurring cost is the seat or subscription fee for the plan your organization holds, and that fee is the figure to confirm with Atlassian for your tenant. Atlassian is phasing Compass out in favor of DX, and DX pricing is not yet known to us, so ask Atlassian and DX in writing for the post-transition terms, including per-user basis, minimums, renewal dates and any data export costs. Do not assume the current plan will carry over unchanged. Your Compass cost today is the baseline any Backstage estimate has to beat over several years, not a one-time figure.
What are the main recurring costs of running Backstage?
The recurring costs are the parts you run every month, and they fall into four groups:
- Kubernetes hosting for the Backstage backend and frontend, sized to your own cluster and cloud account.
- A managed or self-run PostgreSQL database, which Backstage uses in production.
- Staff time for the platform team, upgrades, incident response and catalog maintenance.
- Plugin maintenance, because community and custom plugins change with each Backstage release.
Hosting and database costs depend on your cloud provider and sizing, so request a sizing estimate for your expected catalog size and number of integrations from whoever scopes the work.
What is the one-time cost of setting up a Backstage portal?
Setup is the main one-time cost: scoping, building the catalog import, configuring authentication, connecting integrations, creating the first software templates and TechDocs, and hardening the deployment. Authentication alone needs sign-in resolvers so every provider maps to the same identity, and production should not offer guest access. Build a fixed-scope written plan first, because the scope decides the effort. DeployOpen works on fixed-scope engagements, with scope, deliverables and timelines agreed in writing before work starts, so ask for that document and check that it lists each integration and plugin rather than a single lump sum.
How much does plugin development add to the bill?
Plugin work is often the most variable item. Backstage ships a large plugin ecosystem, but Jira, Bitbucket, scorecard and internal system integrations may need custom plugins or configuration, and each one has to be built, tested and kept working through upgrades. Costs rise with the number of integrations and with how closely your data model differs from the defaults. Ask the scoping partner to list each plugin as either existing, configured or custom, and to state who maintains each after handover. Note that the Compass scorecard rebuild is its own effort, covered on a separate page.
How much upgrade effort does the Backstage release cadence create?
Upgrades recur, and the release cadence sets their rhythm. The main release line ships monthly, on the Tuesday before the third Wednesday of each month, and the next line ships weekly on Tuesdays. The versioning policy says high and critical vulnerabilities will be backported to releases from the last 6 months where feasible, which means you should plan to stay reasonably current rather than skip versions for long periods. Node.js support also matters: Backstage supports exactly two adjacent even-numbered Node.js releases, and as of Backstage 1.46.0 those are Node.js 22 and 24. Each Node.js change can require a plugin update, so budget recurring time for upgrades. Ask for a documented upgrade procedure and an agreed upgrade cadence in any retainer.
Who staffs the platform team, and what does it cost?
The platform team is the largest recurring cost because it owns the portal after launch. Its size depends on catalog breadth, number of integrations, number of teams onboarded and how much self-service you offer through templates. Staff time is paid by your organization, whether as internal engineers or a partner retainer, so the decision is about who holds the work. Confirm the roles you need, such as a Backstage maintainer, a platform engineer for the cluster and a plugin owner, and whether a retainer for ongoing support, upgrades and testing covers part of that load. Request a written split of responsibilities so you know what your staff must still do.
What should we request in a quote for a Backstage portal?
Ask for a fixed-scope written proposal that separates one-time work from recurring work. It should list the catalog import, each integration and plugin, authentication setup, templates, TechDocs, hardening, backup and handover, along with the deliverables and timeline agreed in writing. For recurring items, request the hosting and database assumptions, the upgrade and support scope, the testing frequency and the response expectations, with any service levels stated explicitly. Ask who pays the cloud bill and the database, and what happens to the Compass export if the transition timeline moves. Ask DeployOpen or any other partner to state exactly which items are excluded.
How a move from Compass to Backstage proceeds
The sequence moves your catalog, ownership and scorecards into a self-hosted Backstage portal in an order that keeps every component accounted for before Compass access ends. Each step closes with a check you can verify, so the cutover is a decision based on evidence rather than a single switch-over date. The detailed steps are covered in the migration guide, and total timing depends on catalog size and scope.
Inventory components, owners and integrations
Start by listing every Compass component, its owning team, its repository and the integrations that feed it, such as Jira and Bitbucket links. Platform engineering leads this with input from team leads, because Compass data is often incomplete in places where teams created components in the UI. The step is done when every component has a named owner and a source location, and the team agrees on which components are in scope for the first import.
Convert component definitions to catalog-info.yaml
Convert the compass.yml files that already live in repositories and the components created only in the Compass UI into catalog-info.yaml descriptors, following the Backstage descriptor format. Engineers review the files in their own repositories, and the platform team writes the converter or import scripts for UI-only components. The step is done when the descriptors validate against the Backstage entity schema and load into a test instance without errors.
Map component types and relationships
Map Compass component types to Backstage kinds such as Component, API, Resource, System and Domain, and rebuild the dependency and ownership relationships between them. Decide where an API definition should be attached as an API entity, and confirm how each relationship is expressed in the descriptor files. The step is done when a sample of services shows the same dependencies in Backstage that teams recognize from Compass.
Re-create teams from your identity provider
Rebuild teams as Group and User entities sourced from your identity provider, not from hand-edited lists, so ownership stays current after the move. Configure sign-in resolvers so each provider login maps to the same identity, and turn off guest access before any shared use. The step is done when group membership in Backstage matches the identity provider, and each component's owner resolves to an existing group.
Rebuild scorecards as checks
Recreate the Compass scorecard criteria as Backstage checks, using the Tech Insights approach where facts are collected and rules evaluate them. Some criteria will need custom facts, and dashboards or alerts will need extra work that the scorecard model does not provide out of the box. The step is done when each scorecard criterion has a documented rule, and the team has agreed on which results count as passing.
Run parallel validation against Compass
Run Backstage alongside Compass for a set period and compare component counts, owners, relationships and scorecard results for the same services. Discrepancies should be traced back to the source descriptor or the rule, then fixed in the repository rather than patched in the portal. The step is done when the teams sign off that the two catalogs agree for the agreed scope, with every known difference documented.
Cut over before Compass access ends
Move users and automation to Backstage, point links and ownership references at the new portal, and export or archive what you need from Compass before its access ends. Confirm the export with Atlassian and your own records, since phase-out terms and dates should come from the vendor. The step is done when teams use Backstage as the system of record, an archived copy of the Compass data exists, and the Compass dependency is removed from runbooks.
What do teams ask before running Backstage?
How much effort and time does a self-hosted Backstage portal take?
The effort depends mostly on how many integrations you need, how many plugins you adopt, and how much of your existing catalog you migrate. Backstage itself is a framework, so you build and configure the portal rather than installing a finished product. The first working version is usually a catalog with ownership, a few integrations and a sign-in setup. Plugin work, scorecard rebuilds and the migration of existing components add time on top. No public figure in our sources sets a duration for your environment, so ask any provider, including us, to break the estimate into catalog, integrations, identity, hosting and migration, with each item tied to your own inventory of components and systems.
Can our internal team run Backstage without outside help?
Yes, many teams do, provided they have engineers who can own a TypeScript and Node.js codebase and a platform team willing to run it over time. Outside help is most useful for the first build, for the identity and catalog design, and for the upgrade process. Be realistic about the ongoing workload: Backstage is an open source project with a regular release cadence, so someone must keep your fork or application current. Ask yourself whether you have the people to cover that work on an ongoing basis, not only during the launch.
What skills and infrastructure does a Backstage portal require?
Plan for five areas:
- Kubernetes or another hosting target where you run the Backstage backend and frontend.
- PostgreSQL in production, since Backstage uses it for production and SQLite for development, with each backend plugin getting its own logical database through Knex.
- An identity provider for sign-in. Backstage ships 19 built-in authentication providers, and you need sign-in resolvers so each provider resolves to the same identity.
- TypeScript and Node.js skills to maintain the app and plugins. Backstage supports exactly two adjacent even-numbered Node.js releases, currently 22 and 24 as of Backstage 1.46.0.
- Named owners for each plugin you run, including the integrations you build for Jira, Bitbucket or other tools.
How do we handle Backstage Node.js and release upgrades?
Set a regular upgrade rhythm and assign it to a named owner. Backstage's main release line ships monthly, on the Tuesday before the third Wednesday of each month, and the next release line ships weekly on Tuesdays, according to its versioning policy. The policy says high and critical severity vulnerabilities will always be backported to releases from the last 6 months if feasible, and other security fixes may be backported. Your plan should cover choosing a release line, testing plugin compatibility, and moving Node.js versions when the supported set changes. Ask any implementation partner to document this process as part of the handover.
Can we rebuild our Compass scorecards in Backstage?
Yes, scorecards can be rebuilt in Backstage, but the work is manual and it is not a one-click import. Backstage's Tech Insights plugins evaluate facts with rule-based checks and can produce maturity rankings, so you can recreate criteria such as production readiness. Expect the rules, the facts they read, and the dashboards and alerts to need separate design. Start by listing each Compass scorecard criterion and the data source behind it, then decide which checks are automatic and which still need a person. Confirm the current plugin behavior against the Backstage documentation for your release line before committing to a design.
Does Backstage need a paid license or a vendor subscription?
Backstage is licensed under the Apache License 2.0 and has no paid edition from the project itself, so the software carries no license fee. Your recurring costs are the infrastructure, the database, the engineering time to build and maintain the portal, and any outside support you buy. This differs from commercial self-managed portals, which still need a vendor license key or license file. Ask any provider to separate software licensing, hosting, database operation and engineering time in the quote so you can compare the totals fairly.
What does a fixed-scope Backstage engagement cover?
A fixed-scope engagement covers the work agreed in writing before it starts, such as the planning, the implementation, the integrations, the hardening, the backup setup, the documentation and the handover to your team. DeployOpen plans, implements, customizes, integrates, hardens, backs up, upgrades and documents self-hosted platforms inside your own cloud accounts, data centers or air-gapped networks. Scope, deliverables and timelines are agreed in writing. Ongoing support, upgrades and continuous testing are available as retainers. DeployOpen does not publish a price list, and a quote follows from the written scope.
What should we check in a Backstage security setup?
Start with authentication, because Backstage's authentication documentation advises against offering guest access in production. Configure sign-in resolvers so every identity provider maps to the same user, and confirm that group membership drives catalog ownership. Protect the database and secrets, restrict who can change catalog descriptors, and review plugin permissions before release. Confirm your patch process against the versioning policy, since high and critical fixes are backported to recent releases where feasible. A security test of the deployed portal is a separate step you can scope with a provider.
Questions to settle before choosing
Start with the DX transition terms and timing because they set your deadline. Ask Atlassian in writing when Compass access ends for your tenant, what happens to the components, teams and scorecards you have defined, and whether any export is provided in a machine-readable form. Then ask DX what it will charge after the transition, on what unit (per user, per component or per team), and whether a price is fixed for a stated term. Compare those answers with the time your platform team needs to rebuild the catalog, since that is the window you actually have. If DX cannot give a price or a date, treat the transition as an open risk and plan the Backstage path in parallel rather than waiting for the answer.
Next, list the Jira and Bitbucket integrations your teams depend on today and check each one against what you will run yourself. Confirm which Compass links to Jira projects, Bitbucket repositories and pipelines are used for ownership, scorecard checks or deployment status, and which of those are read-only views versus automations that write back. Ask Atlassian which of these depend on Compass staying in its cloud, and ask your Backstage plugin candidates, such as the Jira and Bitbucket plugins, whether they cover the same data and which authentication method they need. Also confirm your Bitbucket hosting model, because Cloud and Data Center expose different APIs and tokens.
Settle residency and identity constraints before any design work. Confirm with Atlassian and DX where catalog data is stored and processed, and whether that meets your data residency rule. On the Backstage side, the authentication documentation expects every sign-in provider to resolve to one identity and advises against guest access in production, so confirm which identity provider is the source of truth for users and groups and whether it can supply the group membership that ownership depends on. Finally, assess your own platform engineering capacity: name the people who will upgrade Backstage on the monthly and weekly release lines, patch its Node.js runtime, operate PostgreSQL and own the plugins. If that team does not exist, get a written scope and quote from an implementation partner before you decide.
How DeployOpen helps you evaluate and implement Backstage
DeployOpen plans, implements, customizes, integrates, hardens, documents and supports self-hosted Backstage inside your own cloud accounts, data centers or air-gapped networks. We start with a written scope so you can compare Compass with a portal your team runs before any build work begins.
How we scope
- Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
- The written scope lists which Compass components, teams and scorecards move into the Backstage catalog.
- We confirm which identity provider, Jira and Bitbucket integrations and hosting environment the portal must use.
- Quotes follow from the written scope, so ask us to itemize the components before comparing against Compass pricing.
How we build
- We deploy Backstage in your environment with PostgreSQL, sign-in resolvers and catalog descriptor files you can review.
- Software Templates and TechDocs are configured to match the workflows your engineering teams already use.
- We test the catalog, authentication and integrations against the scope, and record the results as evidence.
- We document the configuration as code so changes go through your normal review and version control process.
How we hand over
- Handover includes architecture notes, runbooks, configuration files and the list of plugins and their owners.
- Your platform engineers run a walkthrough of catalog ownership, upgrades and how to add new entities.
- We agree in writing how backups, Node.js version support and Backstage release upgrades will be owned after handover.
- Your team keeps full control of the code and infrastructure, so there is no dependency on a DeployOpen-hosted instance.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers, scoped in writing.
- Retainers can cover tracking Backstage release lines and applying security fixes in your environment.
- Ask whether your support scope includes plugin maintenance, catalog hygiene and incident response for the portal.
- We prepare systems and evidence for compliance assessments, but independent auditors issue any audit reports or certifications.
