Which open-source alternative to OpsLevel fits your team
For most teams leaving OpsLevel, Backstage is the main open-source replacement, because it covers the service catalog, ownership tracking and documentation that a catalog product provides, and it runs entirely in your own infrastructure. Other options fit narrower needs, such as a team that wants a hosted integration layer or a team already committed to a different commercial vendor. The right choice depends less on feature lists and more on whether you can staff a platform team to build and run the portal yourself. Teams usually start looking after a renewal notice, a pricing or licensing change, a data residency review, or a growing sense that their service metadata is locked inside one vendor's tool.
The self-hosted route with OpsLevel deserves a close look before you decide. OpsLevel documents a self-hosted edition installed through Replicated, which requires a license file from OpsLevel and runs on a Kubernetes cluster (preferred) or a VM. Push-based integrations need the instance to be reachable over the internet, which may conflict with a private network or air-gapped design. Self-hosting also does not remove the subscription, because the self-managed edition still depends on the vendor's license file. Ask OpsLevel which parts of the stack, such as the Replicated installer and the integrations you rely on, need outbound or inbound connectivity, and confirm the license terms in writing before you compare costs.
Once you have those answers, map your current OpsLevel usage to what Backstage provides: services as Component entities, ownership as Group and User entities, and documentation through TechDocs. Identify the maturity checks and scorecards you depend on, since those usually need plugins or custom work in Backstage. Then compare the recurring license cost against the one-time and ongoing engineering effort of running Backstage. Ask any implementation partner for a fixed-scope written plan that names the integrations, the identity provider connection and the hosting target, so the comparison rests on your environment rather than on assumptions.
Open-source options that replace OpsLevel's catalog and scorecards
OpsLevel combines a service catalog, ownership data and maturity checks in one hosted or licensed product. The options below cover the open-source route first, then two commercial products that serve as reference points. Each card names what the option is, where it fits and the main trade-off you take on.
Backstage as the core catalog
Backstage is an Apache-2.0 framework from Spotify that you run in your own infrastructure. Its Software Catalog stores services, APIs, systems, groups and users as YAML descriptors, usually named catalog-info.yaml, so ownership lives next to the code. It fits teams that want to own the catalog data model and avoid a vendor subscription for the catalog itself. The trade-off is that Backstage is a framework, not a finished product: your team designs the entity model, the UI and the operating process.
CNCF governance and project maturity
Backstage was accepted to the CNCF in 2020 and moved to the Incubating maturity level in 2022. For a regulated buyer, that governance record matters when you assess long-term project health and contributor diversity. Check the CNCF project page and the release cadence against your own upgrade process. Governance status does not replace your own review of the plugins you install, because many plugins are maintained separately from the core project.
Ownership and team data from your identity provider
OpsLevel ownership usually depends on how teams are mapped in its own tooling. In Backstage, Group and User entities can be synchronized from your identity provider, so team membership follows the source of truth. Confirm which identity provider connector and entity provider you will use, how nested groups map to your org structure, and who owns the sync job. Stale ownership is the most common cause of a catalog that nobody trusts.
Maturity checks and scorecards as custom work
OpsLevel's maturity checks are a core part of its product. Backstage does not ship an equivalent scorecard out of the box, so you will need to choose a scorecard plugin, write custom checks against catalog metadata, or build a rules engine that reads your CI and repository data. Document each check, its owner and its data source before migration. Expect this to be the largest design task in the project.
TechDocs for service documentation
TechDocs lets engineers keep Markdown files next to their code, and Backstage builds the documentation sites with MkDocs, including MkDocs plugins. This keeps service docs under version control and reviewable in the same pull request as the code. Confirm how your build pipeline publishes the sites, where storage lives and how access follows your catalog permissions. Teams with docs spread across wikis will need a content migration plan.
Port's self-hostable integrations (commercial reference)
Port is a commercial developer portal, and its Ocean data integrations can be hosted by Port or self-hosted in your infrastructure with Helm or Docker. Self-hosting the integrations keeps data collection inside your network, but the portal itself is still a Port subscription. Compare Port's per-integration hosting model against a Backstage plugin set you operate yourself. Ask Port which parts of the stack remain vendor-hosted.
Cortex self-managed license (commercial reference)
Cortex documents a self-managed deployment into your own Kubernetes cluster through a Helm chart, backed by PostgreSQL. The deployment requires a JWT license key and access token from the Cortex account team, so running it yourself does not remove the subscription. Use it as a benchmark for scorecard features and deployment effort. Ask the vendor what the license covers, how renewals are handled and what happens to your catalog data if you leave.
How OpsLevel capabilities map to Backstage and plugins
This table maps the main OpsLevel capabilities to their Backstage equivalents and flags where a plugin or custom work is needed. Read the Backstage column as the built-in or core option, and treat any gap as a point to confirm in your own environment before committing to a migration plan.
| OpsLevel capability | Backstage equivalent | Status and what to confirm |
|---|---|---|
| Service catalog entries | Component, API, System and Domain entities in catalog-info.yaml files stored next to each repository | Core feature. Confirm your catalog-info.yaml conventions and how Location entities will register existing repositories at scale. |
| Ownership and teams | Group and User entities, with ownership set through the spec owner field and populated from your identity provider | Core feature. Confirm which identity provider connector your Backstage instance supports and how group membership will sync. |
| API documentation | API entities carrying OpenAPI, AsyncAPI, GraphQL or gRPC definitions | Core feature. Confirm that each definition format your teams use is validated and rendered as expected in your Backstage version. |
| Service documentation | TechDocs, which builds MkDocs sites from Markdown kept beside the code | Core feature. Confirm the MkDocs plugins your documentation needs and where the build runs in your infrastructure. |
| Self-service actions | Software Templates that scaffold repositories and resources from a defined form | Core feature. Rebuilding existing OpsLevel-driven workflows as templates is custom work. Confirm which external systems each template must call. |
| Maturity checks and scorecards | Not a core feature. Typically handled by community plugins or custom scoring against catalog metadata | Gap. Confirm plugin availability and maintenance status in your environment, and budget for custom checks where no plugin fits. |
| Integrations with CI, cloud and incident tools | Plugins and catalog processors, depending on the source system | Gap for some tools. Confirm each integration you rely on exists as a maintained plugin or needs custom development. |
| Licensing and self-hosting | Apache-2.0 framework that runs in your own infrastructure with no vendor license file | Core difference. OpsLevel's self-hosted edition still requires a license file from OpsLevel, so self-hosting does not remove that dependency. |
How to move OpsLevel service data into catalog-info.yaml
The first step is to confirm with OpsLevel which export options and data fields your account can produce before you plan the migration. Ask your OpsLevel account contact whether service, team and ownership data can be exported in bulk, in what format, and whether the export covers service names, descriptions, repository links, tags, lifecycle stages, dependencies and team ownership. Record the answers in writing, because the mapping work depends on them. Then build a field mapping table that connects each OpsLevel attribute to a Backstage field. A service typically becomes a Component entity, and the owning team becomes a Group entity referenced from the component's spec.owner field. Dependencies map to spec.dependsOn, and API definitions map to API entities that can carry OpenAPI, AsyncAPI, GraphQL or gRPC definitions. Treat this mapping as a decision document that your platform team signs off, not as a one-off script.
Once the mapping is agreed, generate one catalog-info.yaml descriptor per repository, placed at the root of each repository so it lives beside the code it describes. The descriptor format is documented in the Backstage descriptor reference, which lists the kinds Component, API, Resource, System, Domain, Group, User, Template and Location. Use a Location entity to point Backstage at the files, either a single root file that references the others or a repository discovery configuration, so the catalog picks up every descriptor without manual registration. Groups and Users should come from your identity provider rather than the export, which keeps ownership aligned with your directory. Expect the descriptor to carry metadata, ownership and relationships only. It does not carry OpsLevel scorecard or maturity check results, so those checks must be rebuilt separately, and you should say so explicitly in the migration plan.
Pulling team and ownership data from your identity provider
Ownership data is the part of a service catalog that goes stale fastest, and in Backstage it should come from your identity provider rather than from hand-edited YAML. Backstage ingests Group and User entities from an identity provider through its catalog processors and provider plugins, so teams and their members stay aligned with your directory. Before you migrate, confirm which identity provider you use (for example, Microsoft Entra ID, Okta, Google or an LDAP directory), whether a Backstage provider plugin exists for it, and which plugin version your Backstage release line supports. Provider plugins change between releases, so check the plugin's own documentation against the Backstage version you deploy, and confirm how often the ingestion schedule resyncs.
Once Group and User entities exist, Component entities should point at them through the owner field in each catalog-info.yaml file, using the group's entity reference (for example, group:default/payments-team). Use the same group names that OpsLevel's team data maps to, so ownership questions still have one answer after cutover. Decide early whether system and owner on Components will be enforced by a review step or left optional, because an unowned Component is the common failure mode after a migration. Also confirm how your directory represents nested teams, since a flat group list will not match a hierarchy that OpsLevel currently reflects.
Plan for the cases the directory does not cover well: shared services owned by no single team, contractors who need access to a group without belonging to it, and teams that were renamed in the directory but not in their repositories. Test one team end to end before bulk migration: confirm the group appears in the catalog, its members resolve, and a sample Component shows the correct owner on its page. Ask your identity provider administrator who will maintain the group membership source after launch, because that person becomes the real owner of your catalog's ownership data.
Which option fits your situation
When a regulator, customer contract or internal policy requires catalog data to stay inside your own cloud account, data center or air-gapped network, Backstage is a natural fit because you run the entire application yourself. Ownership metadata, service descriptors and TechDocs sites remain in infrastructure you control, and no vendor needs an inbound connection to read them.
- Hosting boundary: Confirm whether the OpsLevel self-hosted edition, which is installed through Replicated and reachable over the internet for push-based integrations, meets your network policy before you compare it with Backstage.
- Build and run path: Plan for a Backstage deployment in your Kubernetes or VM estate, a database, identity provider integration and a container pipeline for upgrades.
- Catalog sources: Map which
catalog-info.yamlfiles, identity provider groups and API definitions must be read from inside your network. - Documentation: TechDocs builds MkDocs sites from Markdown next to the code, so your docs pipeline stays inside your build environment.
- Vendor access: Ask OpsLevel which telemetry and support access its self-hosted edition requires, and document the answer for your assessor.
Before committing, confirm the residency requirement in writing with your compliance lead and check it against the exact deployment model each option uses.
A renewal, a pricing change or a licensing update often triggers the search. The fair comparison sets the subscription against the engineering time needed to run Backstage, including a team to maintain the platform, plugins and upgrades. Backstage itself is Apache-2.0 licensed, so the software carries no license fee, but the labor and infrastructure are real recurring costs.
- Subscription side: Ask OpsLevel what a self-hosted edition still costs, since it requires a license file from the vendor and does not remove the subscription.
- Backstage side: Count platform engineers, infrastructure, database operations, plugin maintenance and the upgrade cadence. Backstage's main release line ships monthly, so budget time for regular upgrades.
- One-time work: Migration of catalog data, rebuilding checks and onboarding teams are mostly one-time costs.
- Recurring work: Upgrades, plugin updates, security patching and support rotations continue for as long as you run the portal.
- Quote request: Ask any implementation partner for a fixed-scope written proposal that separates migration, hardening and ongoing support.
If the numbers are close, the decision often rests on whether your platform team has spare capacity to own the portal long term.
Teams that need bespoke maturity rules, unusual ownership logic or integrations with internal systems usually gain the most from Backstage, because its plugin ecosystem and entity model are designed to be extended. You can encode your own standards in code and version them with the rest of your platform configuration. The trade-off is that the extensions are yours to build and maintain.
- Entity model: Backstage supports the Component, API, Resource, System, Domain, Group, User, Template and Location kinds, which cover most service ownership questions.
- API definitions: API entities can carry OpenAPI, AsyncAPI, GraphQL or gRPC definitions for contract visibility.
- Scorecard logic: Maturity checks that go beyond what existing plugins provide will need custom code or a third-party plugin, so confirm the gap before you commit.
- Test coverage: Add automated tests for rule changes so a plugin upgrade does not silently break your checks.
- Ownership of code: Decide who maintains custom plugins after the initial build.
Ask for a written inventory of the OpsLevel rules you actually use, then match each one to a built-in feature, a plugin or custom work.
Some organizations want the operational model of a vendor product but installed in their own environment. OpsLevel's self-hosted edition, installed through Replicated, and Cortex's Helm-based self-managed deployment both fit that pattern. These options keep the data in your cluster while keeping vendor support and product updates, but they still depend on a license from the vendor.
- License dependency: OpsLevel requires a license file, and Cortex requires a JWT license key and access token from its account team. Self-hosting does not remove either subscription.
- Infrastructure needs: OpsLevel documents a minimum of 16 CPU, 16 GB of memory and 120 Gi of disk for production, plus room for at least 20 pods.
- Network posture: OpsLevel's push-based integrations require the instance to be reachable over the internet, which may conflict with a strict network policy.
- Upgrade ownership: Confirm who applies vendor releases and how long your team must stay on a supported version.
- Exit path: Ask how catalog data can be exported, so a later move to Backstage stays practical.
Before choosing this path, request the current licensing and self-hosting terms in writing from the vendor.
What OpsLevel's license and Backstage's engineering time each cost
This table separates the cost of keeping OpsLevel, including its license file, from the cost of running Backstage in your own infrastructure. Read each row for who is paid, whether the cost is one-time or recurring, and what pushes it up or down. Ask OpsLevel and any Backstage implementation partner to price each row against your own scope before comparing totals.
| Cost component | Who is paid or who carries it | One-time or recurring | What drives the cost |
|---|---|---|---|
| OpsLevel subscription and license file | OpsLevel, under your commercial agreement | Recurring | Licensed scope, number of services and users, and renewal terms. Confirm with OpsLevel whether self-hosting changes the fee. |
| Cluster and infrastructure for self-hosted OpsLevel | Your cloud or data center budget | Recurring | OpsLevel documents minimums of 16 CPU, 16 GB memory, capacity for 20 pods and 120 Gi disk for production. Confirm these figures against the current self-hosted documentation. |
| Backstage hosting | Your cloud or data center budget | Recurring | Kubernetes or VM footprint, database, search index, and the number of environments you run for staging and production. |
| Backstage initial implementation | Your engineers, or a partner under a written fixed scope | One-time | Number of catalog kinds you model, authentication setup, and how much custom frontend work the portal needs. |
| Catalog migration and catalog-info.yaml authoring | Your platform team or a partner | One-time, with ongoing upkeep | Count of services, quality of existing ownership data, and whether you script the conversion from OpsLevel exports. |
| Identity provider integration for teams and ownership | Your identity or platform team | One-time, with periodic review | Group structure in your identity provider, and how often teams are reorganized. |
| Plugin development and maintenance | Your engineers or a partner | One-time build, recurring maintenance | Scorecard or maturity features that have no suitable plugin, and the number of plugins you depend on. |
| Upgrades | Your engineers or a retainer partner | Recurring | Backstage ships a main release line monthly and a next release line weekly on Tuesdays, per its versioning policy. Your upgrade cadence and plugin compatibility set the effort. |
| Support and internal skills | Your staff, a community, or a support retainer | Recurring | Depth of TypeScript and Kubernetes skills on your team, and whether you need response commitments written into a contract. |
What you give up when leaving OpsLevel and how to work around it
Moving from OpsLevel to Backstage replaces a maintained product with a framework your team assembles and runs. The cards below cover the capabilities you lose or must rebuild, and the workarounds that teams usually choose. Each one needs an owner and a decision before cutover.
Vendor-maintained scorecards and maturity UI
OpsLevel ships scorecards, rubrics and a maturity view as part of the product. In Backstage, the equivalent usually comes from a community or custom scorecard plugin, or from a scheduled job that computes check results from catalog data and publishes them to a dashboard. Decide which checks must exist on day one, then confirm that the plugin you pick supports the check types you need and still receives updates. Expect your own team to maintain rule logic as standards change.
Vendor support and escalation path
With OpsLevel, a support contract gives you a defined escalation route when the catalog or integrations break. Open-source Backstage has no single vendor to call, so incident response depends on your platform team, community channels and any third-party support you contract separately. A DeployOpen retainer can add ongoing support and upgrades, but it is a services agreement with its own written scope, not a vendor warranty. Ask any provider which response commitments are written into the contract.
Out-of-box integrations that need plugins
OpsLevel connects to many source control, incident, and cloud systems with prebuilt sync. Backstage provides the catalog and a plugin ecosystem, but each integration you relied on must be checked for a maintained plugin, or built as a scheduled import from its API. Make an inventory of every integration that writes ownership or status data, and label each one as existing plugin, custom build, or dropped. Test authentication and rate limits in staging before the switch.
Internal ownership of upgrades
Backstage releases on a fixed cadence: its main release line ships monthly, and the next release line ships weekly on Tuesdays, according to the project's versioning policy. Your team must track those releases, test plugin compatibility, and apply breaking changes to your own catalog code. Plan a recurring upgrade window and name the person who owns it. Without that owner, the portal drifts behind its dependencies.
Ownership data and identity sync
OpsLevel ownership often reflects team data curated inside the tool. In Backstage, Group and User entities should come from your identity provider through a sync or ingestion job, so ownership stays accurate after people change teams. Confirm how group membership maps to your directory, who approves changes to team structure, and how orphaned services get reassigned. Without this step, ownership fields go stale within a few reorganizations.
How the migration from OpsLevel to Backstage runs
The sequence moves ownership, service metadata and documentation out of OpsLevel in verified stages, so that Backstage becomes the system of record before the OpsLevel subscription ends. The order below is typical, and the exact timing depends on the inventory and must be confirmed in the written scope.
Inventory services, teams and scorecards
Export the list of services, components, systems, teams and scorecard rules from OpsLevel, then record which of them are actively used and which are stale. DeployOpen works with your platform team on this inventory, and the team lead signs off on the scope of entities to migrate. The step is done when every in-scope entity and every scorecard check has a named owner and a documented disposition: migrate, rebuild as a plugin or retire.
Map entities to catalog-info.yaml
Translate each OpsLevel service into a Backstage descriptor, usually a catalog-info.yaml file stored in the owning repository, using kinds such as Component, API, System, Group and Resource. Where a service exposes an API, attach its OpenAPI, AsyncAPI, GraphQL or gRPC definition to an API entity. The step closes when a sample of descriptors validates and renders in a test Backstage instance with the expected relationships.
Connect the identity provider for ownership
Configure Backstage to import Users and Groups from your identity provider so that the owner field on each entity refers to real teams rather than free text. Confirm the connector and sync approach for your provider in the Backstage documentation and in your own environment, and agree who maintains group membership going forward. The step is done when team ownership in the catalog matches the directory and a spot check of several teams shows correct members.
Pilot TechDocs on a few services
Pick a small set of services with active documentation, keep their Markdown next to the code, and build the sites with TechDocs using MkDocs and the plugins your teams already rely on. Check that navigation, search and links behave as expected and that owners can change their docs through their normal review process. The pilot closes when the selected services publish from their repositories and the owning teams confirm the output is usable.
Run Backstage in parallel with OpsLevel
Keep OpsLevel running while Backstage holds the migrated catalog, and compare ownership, service records and scorecard results for the same services. Track each mismatch, fix the descriptor or the source data, and repeat the comparison until the differences are explained. The step is complete when the open discrepancy list is empty or every remaining item has an agreed owner and resolution.
Cut over ownership and documentation
Make Backstage the system of record for ownership and documentation, update the links that engineers and on-call tools use, and redirect teams from OpsLevel pages to the Backstage catalog. Communicate the change to service owners and confirm that their workflows, including any push-based integrations, still function. The cutover is verified when the agreed owners sign off and no required process still depends on OpsLevel.
Decommission OpsLevel at contract end
Before the OpsLevel contract ends, export any records you need to retain for audit or history, confirm that no integration still writes to OpsLevel, and remove access for users and integrations. Check the vendor's terms for data return and deletion, and ask for the export format in writing. The step is done when the export is stored under your retention policy, access is revoked and the subscription is closed.
Questions buyers ask before replacing OpsLevel
What does it cost to move off OpsLevel to Backstage?
The cost is mostly people time, plus infrastructure, and it splits into one-time and recurring parts. The one-time work covers exporting service data, writing or generating catalog-info.yaml files, wiring identity provider groups, rebuilding maturity checks as scripts or plugins, and migrating documentation. The recurring work covers hosting the Backstage instance, its PostgreSQL database, plugin maintenance and upgrades. No supplied source gives a price for either path, so ask any implementation partner for a quote built from a written scope. Drivers that push the number up include the count of services, how many custom OpsLevel checks you rely on, and how many integrations feed the catalog. Ask for each cost line to be listed separately, including who pays for infrastructure and who owns plugin maintenance after handover.
How long does an OpsLevel to Backstage migration take?
The timeline depends on how much of your catalog data is already structured, how many teams need onboarding, and how many maturity rules must be rebuilt. A migration with clean ownership data and few custom checks is far shorter than one where service ownership lives in spreadsheets and wiki pages. Plan it in phases: first stand up a Backstage instance, then import services that already have owners, then move TechDocs, then retire OpsLevel checks one group at a time. No supplied source gives a duration for this work, so treat any timeline as something to agree in writing. Ask a vendor to show the phases, the dependencies on your identity provider and the acceptance tests for each phase.
Can our own team migrate from OpsLevel without outside help?
A team with Kubernetes, CI and identity provider experience can run a Backstage migration in-house, but the work is more than installing software. Backstage is a framework, so you own the app, its plugins, the authentication setup and the upgrade process. Teams without someone who can write TypeScript or maintain plugins usually need either an outside partner or a dedicated platform engineer. A practical test is whether one person can answer, for every component, who owns it, how it is deployed and how it is backed up. If not, scope a fixed engagement first. DeployOpen plans, implements, customizes, hardens, backs up, upgrades and documents self-hosted open-source platforms inside your own infrastructure, and most engagements are fixed-scope with agreed deliverables.
Does self-hosting OpsLevel remove the subscription?
No. OpsLevel's self-hosted edition runs through Replicated and requires a license file from OpsLevel, so you still pay for the software. Self-hosting changes where the data and workload live, not the commercial relationship. The documentation also states that the instance must be reachable over the internet for push-based integrations, which matters if your security policy restricts inbound traffic. Its minimum specifications are 16 CPU, 16 GB of memory, capacity for at least 20 pods, and 24 Gi of disk for pilots or 120 Gi for production. Before you decide, compare the licensing fee and these infrastructure requirements against the running cost of a Backstage instance in your own cluster, and ask OpsLevel to confirm the license terms in writing.
What does Backstage need to stay upgraded?
Backstage requires ongoing upgrade work because it is a framework you run yourself. Its 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 versioning policy. Your instance does not upgrade itself, so someone must schedule upgrades, read changelogs, update plugins that lag behind core packages and run tests. Budget this as a recurring cost, either as internal engineer time or as a retainer. Ask any provider how they will track release lines, how long they keep a supported version, and how plugin breakage is tested before rollout.
What do engineers and platform owners need to contribute?
Engineers contribute ownership data and documentation, and platform owners contribute the governance and integration decisions. Each service needs a catalog-info.yaml descriptor with a kind, an owner and a lifecycle, and API entities can carry OpenAPI, AsyncAPI, GraphQL or gRPC definitions. Teams must keep Markdown next to their code for TechDocs, which builds sites with MkDocs. Platform owners must decide who can edit the catalog, how groups and users sync from your identity provider, and which checks count as a maturity standard. Expect review cycles with each team to correct ownership and to agree on the checks that replace OpsLevel rules. Confirm these responsibilities in the scope before work begins, so engineering time is planned rather than discovered mid-project.
Official Backstage and OpsLevel documentation to read first
Read the Backstage documentation in a specific order before you write any migration tooling, because the choices you make about catalog layout and release tracking are hard to reverse later. Start with the Backstage GitHub repository to confirm the framework's Apache-2.0 license and its core features: the Software Catalog, Software Templates, TechDocs and the plugin ecosystem. Then read the CNCF project page for Backstage to confirm its governance status and maturity level, which your procurement and architecture reviewers will ask about. Both sources are the natural starting point for an internal review, and neither requires a vendor conversation.
Next, read the descriptor format documentation before converting any OpsLevel service record. This page defines the catalog-info.yaml fields, the entity kinds such as Component, API, System, Group and User, and how API entities reference OpenAPI or AsyncAPI definitions. Map each OpsLevel service to a Component, then decide which team ownership and lifecycle values must be present before a repository is onboarded. Also read the Backstage versioning policy, because the main release line ships monthly and the next line ships weekly. Pick the release line your platform team will follow and schedule upgrades against it.
Finally, read the TechDocs documentation to plan how existing OpsLevel documentation links will move into Markdown kept next to the code, built with MkDocs. Then review OpsLevel's self-hosted documentation so you can state exactly what the licensed alternative requires: a license file from OpsLevel, a Kubernetes cluster or VM, internet reachability for push-based integrations, and the published minimum sizing. Confirm current figures and license terms with OpsLevel directly, since documentation changes. Use the results to build a side-by-side cost model covering licensing, infrastructure, and your own engineering time.
How DeployOpen scopes, migrates and supports the Backstage replacement
DeployOpen is a Chainscore Labs company that plans, implements, integrates, hardens, documents and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For an OpsLevel exit, we start from a written scope covering your catalog, ownership data and maturity checks, then build Backstage in your environment.
How we scope
- Inventory of OpsLevel services, owners, checks and integrations that must move to Backstage
- Written scope listing catalog kinds, identity provider sources, TechDocs sites and deliverables
- Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts
- Confirmation of which maturity checks become plugins, custom scripts or are retired
How we build
- Backstage deployed in your own infrastructure, with catalog-info.yaml files generated or reviewed per repository
- Ownership and team data loaded from your identity provider rather than maintained by hand
- TechDocs pipelines wired to existing Markdown documentation next to the code
- Security testing of the portal, its integrations and its access controls before go-live
How we hand over
- Documentation of the deployment, configuration, catalog conventions and plugin decisions
- Runbooks for upgrades, backups and restores of the Backstage instance and its database
- Evidence packs describing controls and configuration to support your own compliance assessments
- Knowledge transfer sessions so your platform team can maintain the portal independently
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after handover
- Backstage release tracking so your team knows which upgrades affect plugins and templates
- Support scope and response expectations are defined in the retainer agreement, not assumed
- Quotes follow from the written scope, and DeployOpen does not publish a price list
