OpsLevel vs Backstage

In Backstage, ownership is declared in catalog-info.yaml files that sit in each repository, so the record of who owns a component lives next to the code it describes. A descriptor declares an entity with a kind such as Component, API, Resource, System, Domain, Group, User, Template or Location, and fields such as spec.owner link a component to the team that runs it. API entities can carry an OpenAPI, AsyncAPI, GraphQL or gRPC definition, so the interface contract is catalogued with the service. The Backstage catalog then ingests these files through Location entities or registered URLs. Before you plan a migration, confirm the exact kinds and fields your Backstage version expects in the descriptor format documentation.

The main tradeoff is where edits happen. Descriptors are reviewed in pull requests, versioned in Git, and changed by the teams that own the code, which suits organizations that already enforce code review and want ownership changes to be auditable through commit history. The cost is that someone must keep descriptors present and correct in every repository, and a missing or stale file leaves a gap until a platform team notices. A managed catalog like OpsLevel centralizes ownership and service records in the product, usually edited through its interface, API or integrations. That reduces repository-level work but moves the source of truth into a vendor system. Confirm OpsLevel's current model, including how it maps services to repositories and where its ownership data can be exported, against its current documentation before deciding which records need to be rebuilt as descriptors.

Plan for the descriptor model as ongoing work, not a one-time import. Decide early whether ownership changes will be made by pull request in each repository, by a platform team through a generated or templated file, or by a combination, and assign who answers for descriptor drift. Validate descriptors in continuous integration so malformed files fail a build instead of silently dropping an entity. Set a sign-in and resolver policy so owner references resolve to real groups, since a catalog that cannot match spec.owner to a known Group produces ownership gaps that look like missing teams. The effort to maintain these files scales with repository count and how often teams reorganize, so measure both before committing.

Keeping Backstage current is a recurring operating cost that a self-hosted team carries itself, so the first decision is who owns the upgrade calendar. 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 the Backstage versioning policy. A team that wants to stay on the main line needs a named owner who reviews each monthly release, reads its notes for breaking changes to plugins and the app-config.yaml keys in use, and schedules a staging upgrade before production. Backstage also expects you to track its plugin packages, which can move at a different pace than the core, so plan time for dependency bumps in your custom plugins as well.

Security fixes add a second clock. The versioning 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. That backport window only helps a team that is already on a supported release, so falling more than six months behind can leave you with a fix you cannot pick up without a larger jump. The runtime also has to keep pace: Backstage supports exactly two adjacent even-numbered Node.js releases, and as of Backstage 1.46.0 these are Node.js 22 and 24. Confirm the currently supported Node.js pair on the versioning policy page before you build your container image, and budget a separate check whenever Node.js moves.

OpsLevel moves this work to the vendor on its multi-tenant SaaS, so upgrades to the service are not on your calendar. A self-hosted OpsLevel edition is different, because it is installed through Replicated and the upgrade path is governed by the license and the vendor's release process, so confirm with OpsLevel how and when that edition is updated in your cluster. For a self-hosted Backstage portal, the Backstage guidance on keeping Backstage updated describes the upgrade steps to plan around. As a reference point only, the Backstage releases page listed v1.55.3 as the latest release, with 1.56.0 in the next line. Check that page on the day you plan, since the current version will have moved on.

Start with the network model, because it decides which edition and hosting path are even possible. OpsLevel's self-hosted edition, installed through Replicated, needs a license file from OpsLevel and expects the instance to be reachable over the internet for push-based integrations. If your catalog sources sit on isolated or tightly controlled networks, confirm with OpsLevel in writing whether that reachability requirement can be met, and what changes if it cannot. Backstage has no license dependency, so the same question for it is about where you will host the portal and its PostgreSQL database, and how your identity and source systems reach it. Also confirm the identity providers your engineers already use. Backstage ships with 19 built-in authentication providers, but the authentication documentation advises configuring sign-in resolvers so every provider resolves to one identity, and against guest access in production. Map each provider to a single user record before you choose a product, because that mapping is the work most often underestimated.

Next, count your services, teams and ownership records, and decide whether existing rubric checks must carry over. Pull the numbers from your current OpsLevel tenant rather than estimating them, and note how many services have no owner today. Ask whether rubric results need to survive the move as historical data or only as current state. OpsLevel's rubrics and checks do not map one-to-one onto Backstage, so a migration that promises identical scoring needs a check-by-check review that the platform team signs off on. Then assess your internal staff. Name the people who will own the platform group, the plugin upgrades and the Backstage release cadence, which the versioning policy describes as a monthly main line plus a weekly next line. If the answer is one part-time engineer, that is a finding in itself, and it should shape the choice more than the feature list does.

Finally, ask for the cost of the self-hosted license and the infrastructure in your own environment, as separate line items. For the OpsLevel self-hosted edition, request the subscription terms for the license file, the Replicated arrangement, and the minimum of 16 CPU and 16 GB of memory that the self-hosted documentation lists, along with the storage figure for production. For Backstage, the license is zero, so the cost is the infrastructure, the build and plugin maintenance, and the people who run them. Ask each vendor, and each implementation partner, to state recurring and one-time costs separately, and to show what drives them up, such as seat count, service count, environment count and upgrade effort. Do not accept a single annual figure without that breakdown. A written scope with named deliverables is the only reliable basis for comparing the two quotes.