We have "sprawl" in our microservices architecture. What is the best service catalog tool for tracking ownership and dependencies of hundreds of services?

Tackling microservice sprawl requires moving beyond static wikis or spreadsheets into an Internal Developer Portal (IDP) with a robust service catalog. When managing hundreds of services, the "best" tool depends entirely on your team's maintenance bandwidth and whether you prefer an open-source framework or a managed, plug-and-play SaaS platform.

The leading contenders for tracking ownership and dependency mapping are categorized below by their core strengths:

1. Spotify Backstage (The Open-Source Standard)

• Best for: Organizations with dedicated platform engineering capacity who want ultimate customization and zero licensing costs.
• Strengths: Back-ended by a massive open-source community, Backstage natively handles service catalogs, software templates (scaffolding), and tech docs. Its plugin architecture lets you pull in data from GitHub, Kubernetes, PagerDuty, and CI/CD pipelines.
• Trade-offs: It is a framework, not an out-of-the-box product. It requires a dedicated internal team to host, build, and maintain plugins over time.

2. Port (The Highly Customizable SaaS)

• Best for: Teams that want a fully managed, highly adaptable catalog without writing TypeScript plugins or hosting infrastructure.
• Strengths: Port is completely no-code/low-code at its core. You can model your data entities (services, micro-frontends, APIs, resources) however you want, map out relationships and dependencies visually, and build powerful self-service actions for developers.
• Trade-offs: Requires initial design effort to map your domain model correctly, though it completely bypasses the maintenance tax of open-source frameworks.

3. Cortex (The Engineering Leadership & Scorecard Lens)

• Best for: Organizations focused heavily on production-readiness, establishing microservice maturity scorecards, and tracking compliance.
• Strengths: Cortex excels at tracking service ownership and automated scorecards (e.g., grading services A-F based on security, documentation, and logging). Its "initiatives" feature lets leadership set organization-wide goals and track real-time compliance across hundreds of services.
• Trade-offs: Premium pricing tier; tailored heavily toward organizational governance and operational intelligence.

4. OpsLevel (The Fast-Time-to-Value Choice)

• Best for: Teams that want a clean, polished service catalog and maturity model up and running in weeks rather than quarters.
• Strengths: OpsLevel prides itself on fast onboarding (often set up in under 45 days) and automated catalog creation that pulls real-time metadata straight from your Git repositories. It strikes a practical balance between enforcing standards and avoiding administrative overhead.
• Trade-offs: Less malleable for deeply eccentric, non-standard enterprise workflows compared to Port or Backstage.

Quick Decision Matrix

• Choose Backstage if you have platform engineers to spare and want a free, infinitely extensible tool.
• Choose Port if you need a blank canvas to model complex custom dependencies and self-service flows immediately.
• Choose Cortex or OpsLevel if your primary pain point is enforcing quality standards, scorecards, and getting quick visibility for engineering leadership.

To help narrow down the ideal choice, tell me:

• Do you have a dedicated platform/infra team to maintain an open-source tool, or do you need a fully managed SaaS?
• What are your primary data sources for dependencies and ownership (GitHub/GitLab, Kubernetes, AWS)?

For hundreds of microservices, my default recommendation would be OpsLevel if your primary problem is service sprawl + accurate ownership + dependency visibility.

My shortlist

Why I'd pick OpsLevel for your situation: it is specifically designed around a living microservice catalog, with ownership, dependencies, repos, teams, runbooks, and operational metadata. It can ingest services and dependencies from your existing systems rather than relying entirely on developers manually maintaining a spreadsheet/catalog.

Its dependency model also gives you both dependencies and dependents, plus an interactive dependency graph—useful when you're trying to answer questions like "If we change/kill this service, what breaks?"

When I'd choose Backstage instead

Choose Backstage if you have a strong platform-engineering team and want to build the catalog into a broader internal developer portal. Its Software Catalog is explicitly designed to scale from tens to thousands of components, tracks ownership and metadata, and has a large plugin ecosystem.

The downside is that Backstage is a framework/platform, not just a turnkey catalog. You'll likely spend substantially more effort integrating it, defining metadata conventions, and keeping the catalog accurate.

Cortex is worth evaluating too

Cortex is particularly interesting if your biggest concern is that the catalog will become stale. Its current approach automatically maps services, dependencies, and ownership and uses signals from systems such as GitHub, identity providers, and PagerDuty to keep ownership current.

What I'd actually implement

Don't make the catalog just a directory. For a sprawl problem, I'd require every service to have:

• Owner team — preferably a team, not an individual
• Tier/criticality
• Repository
• Production environments
• Upstream and downstream dependencies
• API/event interfaces
• On-call/contact
• Runbook
• Business domain
• Lifecycle — active, deprecated, candidate for retirement
• Last deployment / activity
• Operational health
• Data classification, if relevant

Then add automated checks for things like "every production service has an owner", "every Tier-1 service has an on-call", and "deprecated services have no remaining consumers." This turns the catalog from documentation into a mechanism for actually reducing sprawl.

Bottom line: I'd start with OpsLevel for a few-hundred-service organization unless you specifically want to build/customize your own developer portal, in which case Backstage is the stronger foundation. Cortex would be my third evaluation, especially if automatic ownership and keeping the catalog continuously accurate are top priorities.

When I'd choose Backstage instead

Choose Backstage if you have a strong platform-engineering team and want to build the catalog into a broader internal developer portal. Its Software Catalog is explicitly designed to scale from tens to thousands of components, tracks ownership and metadata, and has a large plugin ecosystem.

The downside is that Backstage is a framework/platform, not just a turnkey catalog. You'll likely spend substantially more effort integrating it, defining metadata conventions, and keeping the catalog accurate.

Cortex is worth evaluating too

Cortex is particularly interesting if your biggest concern is that the catalog will become stale. Its current approach automatically maps services, dependencies, and ownership and uses signals from systems such as GitHub, identity providers, and PagerDuty to keep ownership current.

For a microservices environment with hundreds of services, I would not choose a catalog based only on “can it list services?” The hard problem is keeping ownership, dependencies, and operational metadata continuously accurate. The best tools pull from Git, Kubernetes, CI/CD, cloud resources, incident systems, and identity providers rather than relying on developers to update a directory manually.

My shortlist:

Kubernetes Guru We The Flywheel## My recommendation by situation

If your main pain is “we don't know who owns what”

Pick OpsLevel or Cortex.

You want:

• Every service mapped to a team
• Owner escalation paths
• Dependency graphs
• Production-readiness checks
• Reports like: - “Services with no owner”
• “Critical services without SLOs”
• “Teams with unsupported services”

These products are designed around service ownership and operational maturity rather than just documentation.

If you have a strong platform engineering team

Pick Backstage.

It is a great foundation if you want to build a company-specific internal developer portal with:

• Custom entity types
• Deep integrations
• Golden paths/templates
• Internal workflows

The cost is engineering effort: Backstage is a framework, not a finished catalog appliance.

If you need something working quickly

Evaluate Port.

It tends to fit organizations that want a usable catalog and workflows without investing heavily in building and maintaining the portal layer.

What I would require in a tool for “microservice sprawl”

Regardless of vendor, I would insist on:

• Automatic discovery

• GitHub/GitLab repositories

• Kubernetes workloads

• Terraform/cloud resources

• CI/CD pipelines

• Observability systems

• Ownership as code

• A service should declare its owner in metadata near the code, not in a spreadsheet.

• Dependency mapping

• API calls

• Event streams

• Databases

• Queues

• Upstream/downstream relationships

• Lifecycle management

• Experimental → production → deprecated → retired

• Service scorecards

• Documentation present

• On-call configured

• Security scans passing

• SLOs defined

• Backup/recovery tested

A practical default choice

For a company with hundreds of services and an existing sprawl problem, my evaluation order would be:

1. OpsLevel — best first look for service ownership + dependency cleanup.
2. Cortex — best if engineering governance and standards are the priority.
3. Backstage — best if you have the platform team to build and maintain it.
4. Port — best if speed of deployment matters.

A common mistake is treating the catalog as documentation. It should become an operational inventory: if a service is deployed, it should appear automatically; if ownership changes, the catalog should detect it; if dependencies break, teams should know. That is what prevents the catalog from becoming another abandoned system.

If you share your stack (Kubernetes or not, GitHub vs GitLab, cloud provider, approximate number of teams/services), I can narrow this to a more specific recommendation.

When microservices sprawl hits "hundreds of services," tribal knowledge breaks down, ownership becomes ambiguous, and dependency mapping turns into a guessing game. Tackling this requires an Internal Developer Portal (IDP) with a robust service catalog at its core.

There is no single "best" tool for every organization, but the top contenders are categorized below by what they do best:

Top Service Catalog & Internal Developer Portals

• Backstage (Open Source) — Created by Spotify, Backstage is the open-source industry standard framework. It features a centralized software catalog, software templates, and tech docs.
  • Best for: Teams with dedicated platform engineering capacity who want deep, fully customized integrations and zero licensing fees.
  • The catch: It requires ongoing maintenance, and you build/maintain the plugins yourself. (Managed alternatives like Roadie offer Backstage without the infrastructure headache.)
• Port — A highly customizable, no-code commercial developer portal. Port lets you model your software catalog dynamically using blueprints to map complex relations (services, APIs, data stores, resources) and build self-service actions on top.
  • Best for: Fast setup, clean UIs, and teams that want a powerful data model without writing custom React plugins for an open-source framework.
• Cortex — A commercial platform laser-focused on service ownership, scorecards, and defining production readiness standards. Cortex excels at turning dependency data and ownership into actionable quality scores.
  • Best for: Enforcing governance, establishing strict maturity metrics, and driving accountability across sprawling engineering orgs.
• OpsLevel — Known for a frictionless microservice catalog coupled with powerful maturity checks. OpsLevel makes it easy to ingest service metadata via config-as-code or APIs, assign clear team ownership, and automatically suggest missing metadata.
  • Best for: Quick time-to-value, intuitive service ownership mapping, and automated service governance.
• Atlassian Compass — Atlassian’s native developer experience platform. Atlassian Compass acts as a decentralized catalog that connects your components with Jira issues, Confluence pages, and Bitbucket/GitHub pipelines.
  • Best for: Organizations already heavily embedded in the Atlassian ecosystem.

How to Choose Based on Your Sprawl

1. If you have spare engineering bandwidth and want total control: Go with Backstage (or Roadie if you want it managed).
2. If you need to untangle complex relationships fast with a visual/no-code approach: Port is exceptional at mapping non-standard dependencies.
3. If your primary pain is lack of standards and accountability (orphan services): Cortex or OpsLevel will help you score, shame, and gamify your way back to clean architecture.

To help narrow down the ideal fit, tell me:

• What is your primary CI/CD and Git provider (GitHub, GitLab, Bitbucket)?
• Do you have a dedicated platform team available to manage a self-hosted tool, or do you need a fully managed SaaS solution?

For hundreds of microservices with sprawl, my top pick would be OpsLevel.

My ranking

Why OpsLevel: its catalog is specifically designed around microservices and can ingest services, dependencies, repositories, teams, and infrastructure. It also provides dependency graphs, ownership, runbooks, and automated catalog enrichment—important when you have hundreds of services and can't realistically maintain everything by hand.

Cortex is probably the closest competitor. Its catalog automatically builds/maintains dependency graphs and has automated ownership recommendations, which is particularly attractive if your biggest problem is "we don't even know who owns half this stuff."

Backstage is the choice I'd make if you're willing to invest in building/operating the platform yourself. Its Software Catalog is open source, scales to thousands of components, tracks ownership and relationships, and has a huge plugin ecosystem.

For your specific "sprawl" problem

I'd evaluate them in this order:

1. OpsLevel — fastest path from "we have 500 services and nobody knows what owns what" to a usable system of record.
2. Cortex — particularly compelling if automated ownership and dependency discovery are priorities.
3. Backstage — best long-term control/customization, but expect meaningful platform-team ownership.
4. Port — worth a serious look if you want a highly customizable catalog/developer portal; it aggregates data from Kubernetes, Terraform, GitHub, Jenkins, etc.

One important architectural point: don't make the catalog itself another manually maintained spreadsheet. Whatever you choose should discover/enrich services from Git, Kubernetes, CI/CD, cloud/observability systems, and identity data, with humans only resolving ambiguity. That's the difference between a catalog that stays accurate and one that becomes another piece of sprawl.

If you tell me roughly how many services you have, whether you're on Kubernetes, and GitHub vs. GitLab, I can narrow this down to OpsLevel vs. Cortex vs. Backstage and give you a practical selection matrix.

Here are top web results for exploring this topic:

roadie.io·https://roadie.io/blog/backstage-microservices-strategies/Backstage Microservices Strategies: Taming Sprawl with a Service ...Backstage Microservices Strategies: Taming Sprawl with a Service Catalog. David Tuite. • February 12th, 2026. backstage. Backstage Microservices Strategies. When a 3 AM incident cascades through your Harness·https://www.harness.io What Is a Software Catalog ? A Guide for Modern DevOps Teams Managing Microservices Sprawl With a Software Catalog. When you manage hundreds of microservices across many CD setups, it's hard to see what's going on. New Relic·https://newrelic.com 5 Best Distributed Tracing Tools to Debug Microservices Faster Distributed tracing tools help you see how a single request flows across all your microservices, closing the visibility gap left by logs and metrics. Choosing the right tool is about balancing time to Google·https://toolbox.google.com**Microservices** Dataset - Google We have "sprawl" in our microservices architecture. What is the best service catalog tool for tracking ownership and dependencies of hundreds of services? AI search data [Dataset]. https://parse.gl/pr[](https://last9.io/blog/microservices-monitoring-tools/) Last9·https://last9.io**Top** 7 Microservices Monitoring Tools to Consider in 2025 - Last9 Here's why microservices need their own monitoring approach: Distributed Complexity: With dozens or hundreds of services, you need tools that map dependencies and communication patterns; Ephemeral Ins vFunction·https://vfunction.com Take control of your microservices with vFunction Challenges managing growing microservices. At what point do microservices become too difficult to manage—20, 100, 500, or more? Without strong governance, teams face escalating challenges in documenti OpsLevel·https://www.opslevel.com Why You Need A Microservice Catalog - OpsLevel ... you'll find that you'll get to the point where you've caused an entirely new organizational scaling issue. After interviewing well over a hundred folks in companies with microservices architecture LogicMonitor·https://www.logicmonitor.com**Microservices Monitoring** Strategies and Best Practices - LogicMonitor Infrastructure Observability Overview. Full visibility across your entire hybrid estate to eliminate tool sprawl. ... The role of distributed tracing in microservices monitoring. Distributed tracing p Port.io·https://www.port.io Software Catalog - The Center of the Developer Portal - Port.io Service catalogs and API catalogs. In some cases, mostly as a result of API sprawl, companies use internal API catalogs, so that developers know which APIs exist, what their quality is and avoid their Checkmk·https://checkmk.com How to Choose the Best Monitoring Tools for Your Use Case ... tool sprawl increases both administrative overhead and total cost of ownership (TCO). ... you choose the right monitoring and observability architecture for your ...

For hundreds of microservices where the main problem is ownership + dependency sprawl, I’d shortlist Backstage, Port, and Cortex—but my default recommendation would be Backstage if you have a capable platform team, or Port if you want faster time-to-value.

My pick: Port for most teams

Port Microservice Catalog is particularly well suited to the sprawl problem. It can pull information from Kubernetes, Terraform, GitHub, Jenkins, etc., centralize it into a catalog, synchronize team ownership, and automatically relate components to build dependency relationships.

That's important because the catalog itself shouldn't become another manually maintained source of truth. For hundreds of services, I'd want ownership and dependencies populated from your existing systems wherever possible.

When I'd choose Backstage instead

Backstage Software Catalog is the strongest choice if you want an open-source, highly customizable developer portal and have platform engineers available to maintain it. Its catalog explicitly models owners and relationships such as dependsOn, consumesApi, and providesApi, and is designed to scale from tens to thousands of services.

The catch is that you're taking on more of the integration and platform-maintenance burden.

When Cortex makes more sense

Cortex Catalog is compelling if your goal isn't merely "where is service X and who owns it?" but also "which services meet our engineering standards?" Cortex combines the catalog/dependency graph with ownership automation and scorecards. Its dependency graph is designed to stay current and expose change blast radius.

What I'd implement

Regardless of the product, I'd make the catalog model roughly:

Service → Team → APIs → Dependencies → Infrastructure → On-call → Lifecycle

And enforce a few rules:

1. Every service has exactly one accountable owner.
2. Dependencies are discovered automatically from Git/Kubernetes/API/service-mesh/observability data where possible.
3. Ownership comes from your identity/team system, rather than people typing arbitrary team names.
4. Give every service a lifecycle: experimental → production → deprecated.
5. Add scorecards for things like owner present, documentation, SLO, on-call, security scanning, and dependency freshness.
6. Make the catalog the place engineers look up architecture—not another ticketing process they have to maintain.

Bottom line: For a few hundred services, I'd choose Port unless you specifically want to invest in building a highly customized developer portal, in which case Backstage is the better long-term foundation. If service maturity/governance is as important as discovery, Cortex deserves a serious evaluation.

When microservice sprawl hits hundreds of services, spreadsheets stop working, wikis drift into obsolescence, and nobody knows who owns that failing downstream API at 3:00 AM.

The industry standard for solving this is the Internal Developer Portal (IDP) with a robust software catalog . Choosing the "best" tool depends heavily on your team's size, budget, and whether you want to build/maintain a framework or buy a turnkey SaaS product.

The leading contenders break down by their core strengths:

1. The Open-Source Heavyweight: Backstage

Originally built and open-sourced by Spotify, Backstage is the de facto standard open-source framework for service catalogs.

• Best for: Large organizations (200+ engineers) with dedicated platform engineering capacity who want total ownership of their portal's architecture and roadmap.
• Strengths: An unmatched plugin ecosystem , powerful software templates ("golden paths"), and a centralized catalog that maps owners, documentation (TechDocs), and dependencies.
• The Catch: Backstage is a framework , not a turnkey product . It requires ongoing maintenance, TypeScript/React knowledge, and dedicated engineering hours to keep plugins updated. (Alternative: Use a managed version like Roadie if you want Backstage without the operational burden).

“We tried backstage. Without a team of people excited about writing Node.js it's basically just a mess of unreliable data and poor integrations...”

2. The Flexible, Productized Alternative:

Port is a fully managed, highly customizable commercial portal designed to act as an engineering knowledge graph.

• Best for: Teams wanting a powerful, highly customizable catalog and self-service action hub fast, without managing open-source infrastructure.
• Strengths: Unlike rigid YAML structures, Port uses a flexible data model ("blueprints") that lets you map services, cloud resources, and complex inter-service dependencies into a clean graph . It has a generous free tier for evaluation.
• The Catch: It is a proprietary SaaS tool (no self-hosted/air-gapped option), and pricing scales per seat.

3. The Governance & Scorecard Champions: Cortex or

Both Cortex and OpsLevel are commercial SaaS platforms laser-focused on service ownership, catalog accuracy, and operational maturity.

• Best for: Engineering leadership who need to aggressively enforce production readiness, security standards, and documentation compliance across hundreds of microservices.
• Strengths: Automated service detection, robust integration with observability/CI/CD tools (Datadog, PagerDuty, GitHub), and powerful Scorecards that grade services from F to A based on custom operational checks . OpsLevel is particularly praised for fast time-to-value (weeks instead of quarters).
• The Catch: Less structurally flexible for wild custom UI modifications compared to Backstage or Port , and carries commercial SaaS subscription costs.

4. The Ecosystem Native:

• Best for: Teams already deeply embedded in the Jira, Confluence, and Bitbucket ecosystem.
• Strengths: Tight native tracking of component ownership and connecting Jira issues directly to software services.
• The Catch: Its integration and extensibility ecosystem outside of Atlassian tools is much smaller, and the data model is more rigid.

Quick Decision Matrix

• Choose Backstage (or Roadie) if you have the engineering headcount to build a custom developer experience and want open-source portability.
• Choose Port if you want deep, flexible data modeling and robust self-service actions up and running in weeks.
• Choose Cortex or OpsLevel if your primary pain is defining engineering standards, tracking service health, and forcing accountability on microservice owners.

To help narrow this down, could you share:

• How large is your engineering organization (number of developers/teams)?
• Do you have dedicated platform engineers available to maintain an open-source tool like Backstage?
• Are you looking strictly for SaaS , or do you have self-hosting/compliance constraints?

When a microservices architecture suffers from "sprawl" (hundreds of undocumented services, ambiguous ownership, and hidden upstream/downstream dependencies), moving to an Internal Developer Portal (IDP) with a robust software catalog is the standard industry remedy.

The "best" tool depends entirely on your engineering team's capacity to build and maintain open-source software versus buying a managed SaaS solution.

To better understand how these modern internal developer portals and catalogs tackle architecture sprawl, watch this helpful comparison overview:

8:49 Humanitec vs Port.io vs Backstage: Best IDP in 2026?2 months ago YouTube · 200OK Solutions

The leading options categorized by organizational fit include:

1. Spotify Backstage (Best Open-Source Standard)

• What it is: The open-source (CNCF incubating) gold standard created by Spotify. It uses a "software catalog as code" approach where metadata lives alongside your repositories in YAML files.
• Best for: Large engineering organizations (1000+ engineers) that have the bandwidth (2–4 dedicated platform engineers) to customize and maintain an internal tool.
• Strengths: Massively extensible plugin ecosystem (200+ plugins), completely free license, and deep community adoption.
• Trade-offs: High maintenance overhead; requires maintaining Node.js/TypeScript plugins and managing ongoing version migrations. Managed commercial wrappers like Roadie exist if you want Backstage without the hosting pain.

2. Port (Best Managed, Highly Customizable SaaS)

• What it is: A fully managed, no-code/low-code SaaS internal developer portal built around customizable data models called Blueprints.
• Best for: Mid-market to enterprise teams (200–2,000 engineers) that want fast time-to-value without writing custom portal code.
• Strengths: Incredibly flexible data model (track microservices, cloud buckets, PagerDuty schedules, and APIs seamlessly), robust self-service actions, and a generous free tier for evaluation.
• Trade-offs: Because it is a closed SaaS platform, complex customization happens within their visual configuration layer rather than through arbitrary source code.

3. Cortex or OpsLevel (Best for Enforcing Standards & Scorecards)

• What it is: Opinionated commercial SaaS platforms that treat service catalogs, ownership, and operational maturity scorecards as first-class citizens.
• Best for: Teams whose primary pain point isn't just a list of services, but actively forcing hundreds of microservices to comply with security, documentation, and reliability standards.
• Strengths: Incredible automated scorecards (continuously grading services on whether they have runbooks, active on-call rotations, or pass security scans) and rapid time-to-value via pre-built integrations.
• Trade-offs: Can get expensive at scale compared to open-source alternatives, and features a more rigid data model than Port.

To help narrow down the ideal tool for your situation, tell me:

• What is your approximate engineering headcount?
• Do you have a dedicated platform engineering team available to run a self-hosted tool?
• Is your primary goal pure inventory/dependency tracking or enforcing compliance scorecards?

For hundreds of microservices, my default recommendation would be OpsLevel if your primary problem is sprawl: keeping an accurate inventory, ownership, dependencies, and service health without creating a second platform your team has to maintain.

My shortlist

Why I'd pick OpsLevel: its catalog is explicitly designed around a living inventory of services, owners, dependencies, repositories, teams, and operational metadata. It can sync services and dependencies rather than relying entirely on developers to manually maintain catalog entries. www.opslevel.com Its dependency view also gives you both upstream dependencies and downstream dependents, including an interactive graph.

Backstage is my choice if you have a strong platform-engineering team and want to own/customize the system yourself. Its Software Catalog is explicitly designed to scale from dozens to thousands of services and tracks ownership, relationships, and metadata. backstage.io The catch is that you're adopting a framework, not just buying a catalog; the plugin/customization model can become another thing your platform team owns.

What I'd optimize for in your situation

Don't choose based primarily on the catalog UI. For "sprawl," the crucial capability is automatic reconciliation of the catalog with reality.

I'd require:

1. Owner/team mapping from Git/GitHub/GitLab/your identity system.
2. Automatic dependency discovery from Kubernetes, APIs, service configs, or telemetry—not just manually entered YAML.
3. Reverse dependency queries: "What breaks if this service goes down?"
4. Orphan detection: services with no accountable owner.
5. Lifecycle status: production, deprecated, experimental, etc.
6. Criticality/tier: so 500 services don't all look equally important.
7. Links to operational context: PagerDuty, Datadog, runbooks, CI/CD, repositories.
8. An API/config-as-code interface, so the catalog can become part of your engineering workflows.

That last point is particularly important: a catalog that requires every team to remember to update metadata will eventually become another source of sprawl. OpsLevel, for example, explicitly supports syncing services, dependencies, repos, and teams and provides automated catalog maintenance.

Bottom line:

• Want the fastest path to a trustworthy catalog → OpsLevel.
• Want maximum control and have platform engineers to operate it → Backstage.
• Want a polished SaaS IDP with lots of workflow flexibility → Port.

For a few hundred services specifically, I'd start with OpsLevel vs. Backstage, and I'd make dependency discovery accuracy and catalog maintenance effort the deciding criteria rather than feature count.