Does self-hosting OpsLevel cost less than running Backstage?
Self-hosting OpsLevel does not remove the subscription. OpsLevel's self-hosted edition is installed through Replicated and needs a license file from OpsLevel, so the saving from moving to Backstage is the OpsLevel subscription line minus the internal and external effort to build, run and maintain a Backstage portal. Backstage itself is Apache-2.0 licensed and has no paid edition from the project, so its licensing line is zero, but that does not make it free to operate. Your OpsLevel subscription figure must come from your own quote, and the per-developer rate, term and any self-hosting surcharge should be read from that document rather than assumed.
OOn the OpsLevel side, the recurring costs are the license, the infrastructure and the people who keep the instance current. OpsLevel's self-hosted documentation lists minimum specifications of 16 CPU and 16 GB of memory, capacity for at least 20 pods, and 24 Gi of disk for pilots or 120 Gi for production. Ask OpsLevel which of these figures apply to your expected catalog size and integrations, and whether the instance must be reachable over the internet for push-based integrations, because that affects your network and hosting costs. On the Backstage side, the costs are hosting, a database such as PostgreSQL, the engineering time to build and customize the catalog, templates and TechDocs, plugin maintenance, and the upgrade work that comes from a monthly main release line and a weekly next release line. Support for Backstage typically comes from internal staff or a services partner, so price that effort explicitly.
Cost direction depends on your team's size, existing skills and current work. A platform team that already runs Kubernetes, maintains CI pipelines and has Backstage experience will carry far less build effort than one starting from scratch. A small organization with few services may find the subscription cheaper than the engineering time it would spend on a portal. Before you decide, ask your OpsLevel account team for a written quote covering the self-managed edition, and compare it with a costed Backstage plan that lists who builds, who runs and who patches the portal each month. The outcome is a clear answer for your organization, not a general rule.
Which cost components sit on each side
This table lists the cost components on the OpsLevel side and the Backstage side, with who is paid for each and whether it is one-time or recurring. Read it as a checklist for a quote request: the OpsLevel subscription and the Backstage operating work recur, while migration and initial build are mostly one-time. No amounts are shown because the supplied facts give none, so confirm each figure with the vendor or your own team.
| Cost component | OpsLevel (commercial, self-hosted edition) | Backstage (open source, self-hosted) |
|---|---|---|
| Software license | Per-developer subscription; the self-hosted edition still requires a license file from OpsLevel, so self-hosting does not remove the subscription. Recurring, paid to OpsLevel. | Apache-2.0 license with no paid edition from the project itself. No license fee, but the open-source license does not cover your hosting or staffing. |
| Infrastructure and hosting | Kubernetes cluster (preferred) or VM meeting a documented minimum of 16 CPU and 16 GB of memory. Recurring, paid to your cloud or data center provider. | Kubernetes or VM capacity sized to your catalog, plugins and traffic, plus PostgreSQL in production. Recurring, paid to your cloud or data center provider. |
| Replicated and network reachability | Installed through Replicated; the instance must be reachable over the internet for push-based integrations. Confirm any Replicated fees and network exposure with OpsLevel and your security team. | Not required. Integrations can run inside your network, so no internet-facing endpoint is needed for the portal itself. |
| Initial implementation | Installation, integrations and ownership setup, often through OpsLevel or a partner. One-time, paid for by you for services and internal time. | Build of the app, catalog model, authentication sign-in resolvers and TechDocs pipeline. One-time, paid to your engineers or a fixed-scope implementation partner such as DeployOpen. |
| Migration of data and rubrics | Export through the OpsLevel CLI or GraphQL API, then phased cutover. One-time, mostly internal time. | Conversion of catalog data into catalog-info.yaml files and rebuilding maturity checks. One-time, mostly internal time, and it grows with the number of services. |
| Operations and upgrades | Vendor-delivered updates to the self-hosted edition, applied on your schedule. Recurring, partly included in the subscription; confirm what support covers. | Monthly main release line and weekly next line, Node.js upgrades, and plugin updates. Recurring, paid in engineer hours or a retainer. |
| Plugin and integration maintenance | Integrations are vendor-maintained. Recurring cost is limited to configuration changes and review of new versions. | Community and custom plugins must be tested and kept current with Backstage releases. Recurring, paid in engineer hours and sensitive to plugin count. |
| Support and internal skills | Vendor support under the subscription terms. Confirm response commitments in writing before relying on them. | Internal skills in TypeScript, Node.js, Kubernetes and PostgreSQL, or a support retainer. Recurring, and the largest cost driver when staff turn over. |
What moves the comparison up or down
Most of the cost gap between OpsLevel and self-hosted Backstage comes from a few variables: how many people use the portal, how big the catalog is, which edition you license, and who maintains the platform afterward. Check each one against your own environment before comparing quotes with build estimates.
Users and developer counts
OpsLevel's subscription is priced per developer, so the number of people who log in and the number of engineers who need catalog access both feed the recurring line. Backstage has no per-seat fee, but a larger audience raises hosting load, authentication volume and support requests. Ask OpsLevel for its per-developer terms in writing and whether read-only consumers are counted. Estimate your own active users rather than total headcount.
Services and catalog entities
The number of services, APIs, resources, systems and teams sets the size of the catalog. In Backstage, each of these is a descriptor file, conventionally named catalog-info.yaml, that someone must author, review and keep current. Count the entities you would need to migrate and how many already have owners. Stale ownership data is the main hidden cost in either direction.
OpsLevel edition and cluster sizing
The self-hosted OpsLevel edition is licensed, installs through Replicated, and needs a license file from OpsLevel. Its documented minimum is 16 CPU and 16 GB of memory, room for at least 20 pods, and 24 Gi of disk for pilots or 120 Gi for production. Confirm with the vendor whether the license fee changes with the self-hosted edition, and budget for the cluster capacity it consumes as a recurring infrastructure line.
Integrations and plugins
Each integration you rely on adds either a vendor connector or a Backstage plugin to build and maintain. Count the source systems you need, such as Git hosts, CI, cloud accounts, incident tools and Kubernetes clusters, and mark which ones require custom code. Backstage plugins come from the community and from your team, so each one carries upgrade and testing work that the vendor otherwise absorbs.
Upgrade cadence and security fixes
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 vulnerabilities are backported to releases from the last six months when feasible. Someone on your team must track these releases and apply them, and that effort recurs. Ask how OpsLevel schedules its own upgrades for self-hosted customers and who performs them.
Platform skills already on staff
The largest variable in the Backstage column is labor. Building the portal, writing plugins, maintaining TypeScript and Node.js code, and handling authentication sign-in resolvers requires engineers who already know these tools. If your platform team has this experience, the internal cost is mostly time. If not, you will pay for hiring, training or an implementation partner, and that spend should be scoped and priced separately from the subscription.
How to build the comparison with your own numbers
This sequence turns OpsLevel's contract and the self-hosted Backstage estimate into one three-year view with one-time and recurring lines. Each step produces a figure you can check against written quotes and your own cluster capacity.
Collect the current OpsLevel contract and seat count
Pull the signed order form, renewal date, licensed seat count, active developer count and any add-ons from your finance and procurement records. Confirm with OpsLevel whether the self-hosted edition is priced on the same basis as the SaaS subscription and whether it requires a license file that renews on its own schedule. Done when you have one sheet listing every recurring OpsLevel line with its source document.
Size the self-hosted minimums against your cluster
Compare OpsLevel's documented minimums of 16 CPU, 16 GB of memory, capacity for at least 20 pods and disk of 24 Gi for a pilot or 120 Gi for production with the headroom your platform team already has. If the capacity is not there, the gap becomes a line for new nodes or a managed cluster. Done when you know whether the self-hosted edition fits existing capacity or adds infrastructure cost.
List the Backstage components you will run
Write down each component your Backstage instance needs: the PostgreSQL database, the caching layer you choose from the options in the architecture overview, the authentication providers your identity estate requires from the 19 built-in options, and the TechDocs build pipeline that turns Markdown into MkDocs sites. Mark which components you already operate and which are new. Done when every component has an owner and a hosting location.
Assign internal and partner hours to each phase
For each phase (evaluation, catalog import, authentication and sign-in resolvers, plugin selection, TechDocs rollout, and cutover), estimate the internal engineering hours and the hours you would buy from an implementation partner. Ask any partner for a fixed-scope written proposal that lists deliverables and exclusions, so the hours map to agreed work. Done when each phase has a named owner and a hours figure marked as internal or external.
Separate one-time costs from recurring costs
Split the sheet into two columns. One-time lines include the discovery work, catalog migration, plugin integration, hardening and initial training. Recurring lines include OpsLevel subscription fees, cluster compute, database storage, backups, on-call time and ongoing plugin maintenance. Done when every line sits in exactly one column and each recurring line states its unit (per seat, per node, per month, or per engineer hour).
Build a three-year view with a planned upgrade cycle
Project both options over three years. Include at least one planned Backstage upgrade cycle, covering release tracking, dependency updates, Node.js version alignment, testing of plugins and the time to backport or apply security fixes. Per the Backstage versioning policy, high and critical vulnerabilities are backported to releases from the last six months where feasible, so plan for staying within that window. Done when the upgrade line is visible in every year and the OpsLevel line reflects your renewal assumptions.
Request written, itemized quotes before deciding
Ask OpsLevel for a written quote that itemizes the subscription or self-hosted license, support tier, and any required infrastructure, and confirm the license file terms in writing. Ask implementation partners for a fixed-scope proposal with deliverables, timelines and exclusions. Replace your estimates with quoted figures wherever they exist and note the source of each number. Done when the three-year comparison contains only quoted or internally measured values, with open items listed.
Where Backstage costs more than the subscription
The open-source route raises total cost in four situations: a small team with no platform engineers, a portal that needs many custom plugins, an audit regime that demands vendor-backed evidence, and a catalog whose maturity rubrics must be rebuilt from scratch. Backstage is an Apache-2.0 framework with no paid edition from the project itself, so the savings you see on a subscription line are replaced by staff time, hosting and whatever commercial services your team chooses to buy around it. If you have no one who can own a Kubernetes deployment, a PostgreSQL database and a TypeScript codebase, the subscription may be the cheaper option even at a higher license fee. Ask whether the people who will run Backstage are already on your payroll and how many hours per month they can realistically give it.
Backstage also carries recurring work that does not appear on any invoice. The versioning policy describes a main release line that ships monthly and a next release line that ships weekly, and high and critical vulnerabilities are backported only to releases from the last 6 months where feasible. Keeping pace means scheduled upgrades of Backstage itself, its Node.js runtime (the project supports two adjacent even-numbered releases), and every community or custom plugin you depend on. Each custom plugin you write is code you maintain indefinitely, and each one you adopt from the community is a dependency with its own release cycle. Budget for this as a standing role, not a project, and read the Backstage versioning policy before estimating it.
Audit requirements can also shift the balance. A self-hosted Backstage instance puts the controls, logging and access reviews for the portal on your team, and an external assessor will ask for evidence of them. Your authentication configuration is part of that evidence: the Backstage authentication documentation advises sign-in resolvers that map every provider to the same identity and disabling guest access in production. Finally, if your current catalog depends on OpsLevel maturity rubrics, those checks will need to be rebuilt as Backstage facts and checks, and that translation is effort you should cost before the decision. Ask a Backstage implementation partner for a written scope that lists each rubric, plugin and control, and compare it with the subscription renewal quote line by line.
What to ask for in OpsLevel and partner quotes
Ask OpsLevel, in writing, for the subscription terms that match the edition you intend to run. For SaaS, confirm the per-developer pricing basis, how developer seats are counted, what is included in the base tier, and what triggers an increase at renewal. For the self-hosted edition, confirm the license scope: which environments the license file covers (production, staging, pilot), whether it is tied to a single instance or cluster, how renewals are issued, and what support and upgrade access comes with it. The OpsLevel self-hosting documentation states that the self-hosted edition requires a license file from OpsLevel, so the license is a recurring line item even though you run the infrastructure yourself. Confirm whether that cost is quoted separately from any hosting or Replicated charges.
Ask for the sizing requirement in the same document. OpsLevel's self-hosted documentation lists minimum specifications of 16 CPU and 16 GB of memory, capacity for at least 20 pods, and 24 Gi of disk for pilots or 120 Gi for production. Have your platform team translate those minimums into cloud or data center capacity, then ask the vendor to confirm in writing that the sizing applies to your expected catalog size and integration volume. Also confirm that the instance must be reachable over the internet for push-based integrations, because that affects your network controls and may conflict with an isolated network design.
For any implementation partner, including DeployOpen, ask for a fixed-scope written statement before any work starts. It should list the deliverables (for example, which integrations, catalog migration steps, templates and handover documents), the acceptance criteria for each, the timelines, the responsibilities of each party, and what is excluded. DeployOpen does not publish a price list. A quote follows from that written scope, so the more precisely you define systems, environments and data volumes, the more comparable the quotes will be. Ask each bidder to separate one-time implementation work from recurring support, upgrades and testing retainers, and to name who holds the OpsLevel and hosting relationships. Compare every quote against the same written scope.
When the numbers favor the switch and when they do not
The cost comparison only tips one way once you know your renewal timing, network rules, team skills and how much platform work you can staff. The cases below show which conditions favor moving to self-hosted Backstage and which favor keeping OpsLevel, and what to verify before deciding.
Renewal date sets the timing
Moving only makes financial sense if you can run both systems in parallel long enough to validate ownership data. If your OpsLevel renewal is months away, use that window to build the Backstage catalog and compare results. If the renewal is imminent, ask OpsLevel for a short extension or a per-developer price for the overlap period. Ask whether the license price changes with headcount, since the seat count will drive the recurring line in your comparison.
Restricted or isolated network
The OpsLevel self-hosted edition is 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 environment cannot allow that inbound path, self-hosted Backstage is usually the simpler fit because it runs entirely inside your network. Confirm with OpsLevel which integrations depend on push traffic and whether any of them can run pull-based.
Existing Backstage skills in-house
If your engineers already run Backstage for catalog, TechDocs or plugins, the marginal cost of adding ownership and service data is mostly catalog authoring and plugin work, not a new platform. In that case the subscription is the largest avoidable line. Check that at least one or two people can own upgrades, since Backstage is a framework you build and maintain yourself rather than a finished product.
Catalog already in descriptor files
Backstage reads YAML descriptors conventionally named catalog-info.yaml, with kinds such as Component, API, System and Group. If your service metadata already lives in similar files, conversion is a scripted exercise rather than a manual rebuild. If your ownership data sits mostly in spreadsheets or in OpsLevel alone, the migration effort rises and the savings take longer to appear.
No dedicated platform staff
Backstage needs someone to track monthly releases, Node.js version support, security backports and plugin compatibility. Without that capacity, a self-hosted portal can cost more in unplanned engineering time than the subscription it replaces. Treat this as a decision gate: either fund a named owner, or buy an implementation and support retainer from a partner. Ask any partner for the written scope, the upgrade cadence it covers and who carries the on-call duty.
Need for vendor-managed SaaS
If your priority is zero hosting work, a hosted OpsLevel subscription or another managed portal may remain the better choice. Self-hosting the commercial edition still requires an OpsLevel license file, so it does not remove the subscription or the vendor dependency. Choose the self-hosted Backstage path when the goal is to own the infrastructure, the data and the upgrade schedule, and when you can staff that ownership.
Confirm the figures with your own data before deciding
Before you decide, replace every assumption in this comparison with your own numbers. Start with the OpsLevel contract: pull the current order form or renewal quote, the per-developer rate, the billing term, and any clauses on seat true-ups, overage or price changes at renewal. Next, count the seats the contract actually bills for, which may differ from the engineers who push code or the people who log in. If you are considering the self-hosted edition, also confirm with OpsLevel which license file, Kubernetes footprint and support terms apply, since the license is still required and the minimum of 16 CPU and 16 GB of memory is a starting point, not a sizing decision.
Then build the Backstage side from your own inventory. List the clusters, virtual machines, database instances and backup targets that a self-hosted portal would use, along with their current unit costs. Estimate staff hours in the categories that tend to dominate: initial build and integration, plugin selection and upgrades, sign-in and identity configuration, TechDocs pipelines, on-call support and security patching. Keep one-time costs separate from recurring ones, and record who in your organization or in a partner's team would own each line. Where you need outside help, ask for the scope, deliverables and assumptions in writing, so that the quote can be compared line by line with the subscription.
Once you have those figures, run the model over at least two scenarios, such as current seat count and projected headcount growth, and check whether the break-even point still holds if the subscription price changes. For the operational detail behind these inputs, read the sibling pages on migrating from OpsLevel to Backstage and on self-hosted OpsLevel versus self-hosted Backstage, which cover the export steps, network requirements and maintenance work that these figures depend on.
How DeployOpen scopes a fixed-price Backstage implementation
DeployOpen plans, implements, customizes, integrates, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure. For a cost comparison like this one, we start from a written scope that sets out what your Backstage portal will cover, what it will replace and what your team will own afterward.
How we scope
- Inventory the OpsLevel services, teams, ownership fields and checks that the Backstage portal must replace.
- Agree which hosting model, cloud account or network zone the Backstage deployment will run in.
- Write down the plugins, authentication providers and integrations in scope, and those you will keep on OpsLevel for now.
How we build
- Set up Backstage with PostgreSQL, Software Catalog descriptors and TechDocs against your agreed architecture.
- Configure sign-in resolvers so every identity provider maps to one user, and leave guest access disabled.
- Test catalog accuracy, ownership mapping and security settings before any team depends on the new portal.
How we hand over
- Document the deployment, configuration, upgrade steps and the catalog-info.yaml conventions your teams will follow.
- Walk your platform engineers through routine operation, including how Backstage release lines and Node.js support are tracked.
- Deliver the written runbooks and evidence your internal compliance reviewers need for the new system.
How we support
- Offer ongoing support, upgrades and continuous testing as a retainer after the fixed-scope project closes.
- Plan upgrades around Backstage's monthly main release line and its security backport policy.
- Ask any provider, including us, for a written scope with deliverables and timelines before work starts.
