I want to create an internal developer portal for our microservices. What's the best open-source foundation for a software catalog and docs, besides Backstage?

If you love the concept of an Internal Developer Portal (IDP) with a software catalog and docs —but want to avoid Backstage’s notorious maintenance burden, TypeScript/React plugin overhead, and the need for a dedicated platform team just to keep it upgraded—the open-source ecosystem presents an interesting reality: true end-to-end open-source competitors to Backstage that handle both a rich catalog and docs natively are exceptionally rare.

Most commercial alternatives (Port, Cortex, OpsLevel ) are proprietary SaaS. However, depending on whether you want a lightweight minimalist catalog, a documentation-first approach, or an infrastructure-orchestrated portal, you can build a fantastic open-source foundation using alternative stacks.

Alternative Open-Source Approaches

• The Documentation-First Stack (Backstage TechDocs + MkDocs / Redoc)
  • What it is: If your primary pain point is searchable microservice documentation tied directly to a code repository, skip the heavy Backstage framework and leverage MkDocs (with the mkdocs-material theme) or Redoc/Swagger UI for APIs. Store the documentation as-is in your microservice repos ("docs-as-code") and aggregate them using a static site generator or a central developer hub like Headlamp or a custom portal front-end backed by a lightweight registry.
• The GitOps / YAML-Driven Registry Pattern
  • What it is: Instead of running a heavy catalog database server, many lean teams use a single Git repository as the source of truth for microservice metadata (using Backstage-compatible catalog-info.yaml files or simple service manifest definitions). You can pair a simple backend parser with an internal dashboard or use tools like W'xOps Service Catalog which read flat files straight from Git without a complex database or plugin architecture.
• Kubernetes & Infrastructure-Centric Portals (Headlamp / Portainer)
  • What it is: If your developers primarily need visibility into microservices running on Kubernetes, Headlamp is an extensible, open-source Kubernetes web UI that supports plugins and gives developers a direct lens into workloads, configurations, and logs across clusters without building an IDP from scratch.

The Proprietary SaaS Shortcut (If You Consider Commercial Alternatives)

If you find that maintaining another open-source web application turns into "Backstage 2.0," most engineering teams move away from self-hosted frameworks to managed options that offer instant time-to-value:

• Port : Known for a flexible, no-code data model where you can visually define microservices, APIs, and resources without writing React.
• OpsLevel : Excellent for auto-discovering services and implementing microservice maturity scorecards with minimal setup.
• Roadie : If you actually like Backstage’s features but don't want to host, upgrade, or manage the open-source infrastructure yourself.

To help narrow down the best path, tell me:

• Do you have dedicated platform engineers available to run and customize a self-hosted tool, or does it need to be zero-maintenance?
• Are your microservices primarily on Kubernetes , or a mix of serverless/VMs?

If open source is a hard requirement, the field gets much narrower than the usual “Backstage alternatives” lists. Most of the popular alternatives—Port, Cortex, OpsLevel, Compass—are proprietary SaaS products.

My shortlist

For your specific requirement—“software catalog + docs” for microservices—I would still choose Backstage unless you have a reason to avoid it. It is unusual in being both an open-source portal framework and having mature catalog + docs-as-code primitives. Current comparisons continue to distinguish Backstage from commercial alternatives primarily on exactly that open-source/self-hosted dimension.

But if what you really mean is “I don't want Backstage's architecture or operational complexity”, I'd consider a deliberately smaller stack:

• Catalog: a Git-backed YAML/JSON service registry
• Docs: Docusaurus or MkDocs
• Search: OpenSearch/Meilisearch
• Service metadata: GitHub/GitLab + Kubernetes APIs
• Ownership: CODEOWNERS + your identity provider
• Portal UI: a small React/Next.js application
• Automation: Argo CD/GitHub Actions
• API specs: OpenAPI/AsyncAPI stored beside services

That gives you a surprisingly capable internal portal without adopting a giant IDP framework.

One important distinction

If you're looking for an open-source foundation for the portal itself, I'd investigate Kratix alongside a lightweight catalog rather than treating it as a Backstage replacement. Modern IDPs are increasingly split into separate concerns: portal/catalog, orchestration, and scorecards. Kratix is much more interesting for the platform orchestration half than for being your documentation/catalog UI.

I would not pick Atlassian Compass for a new open-source architecture: Atlassian's current documentation says its catalog and scorecard functionality is moving into DX.

My recommendation: if you have ~50–500 microservices and a platform team, start with Backstage + Git-based metadata + TechDocs, but keep the catalog metadata and documentation portable so you're not locked into Backstage. If you tell me your Kubernetes/cloud stack, Git provider, and approximate number of services/developers, I can sketch a leaner open-source architecture and compare it directly with Backstage.

If you want an open-source foundation for a software catalog and documentation but want to skip Backstage —often due to the heavy overhead of maintaining a custom React/TypeScript monolith, managing plugin compatibility, or wrestling with YAML-heavy catalog-info.yaml files—the ecosystem looks a bit different.

Strictly speaking, the open-source community hasn’t produced another monolithic "framework" quite like Backstage. Instead, teams looking for open-source foundations usually combine lightweight catalog engines, documentation-as-code platforms, or leverage git-native approaches.

The top open-source alternatives and foundational patterns for a catalog and docs include:

• Cangjie / Open-source Developer Portals (Community Tools): While enterprise vendors like Port and Cortex dominate the turnkey IDP space, they are proprietary. For a pure open-source stack, many teams bypass a heavy "portal framework" entirely and build a lightweight aggregator using Home-grown portals backed by Graph databases (like Neo4j) or PostgreSQL , paired with a solid API spec registry.
• Compass (by Bybit / Open Source variants) or backstage-adjacent tools: Various organizations have open-sourced internal tools, but they rarely reach CNCF-level maturity.
• The "Docs-First" Composite Stack (Backstage alternative approach): If your primary needs are a clean service catalog and robust technical documentation, assembling a decoupled open-source stack is often more maintainable than Backstage:
  • For Documentation: Backstage's tech docs native core was actually built on TechDocs (Markdown + MkDocs) . You can run a centralized MkDocs (with the Material theme) or Antora instance hooked into your Git repositories. Antora is exceptional for multi-repo microservice documentation because it aggregates doc pages from separate repositories into a single unified site based on component descriptors.
  • For the Catalog: Cortex / OpenAPI / Backstage components parsed via custom scripts into a simple Postgres/PostgREST + lightweight frontend (like Next.js or Retool/Appsmith) . Many platform engineering teams realize they only need a simple searchable UI querying a central database of service metadata rather than a 50-plugin Node/React architecture.

The Realistic Trade-Offs

When moving away from Backstage's open-source framework, you face a fork in the road:

1. The Do-It-Yourself Composable Stack: Use MkDocs/Antora for documentation and a lightweight asset database for the catalog. It is vastly easier to upgrade and maintain than Backstage, but you lose out-of-the-box "golden path" scaffolding plugins.
2. Managed Open-Source (The Hybrid Route): If you like Backstage's feature set and open-source flexibility but hate running it, teams frequently look at managed wrappers like Roadie , which host the open-source project for you so your engineers don’t become a dedicated Backstage-maintenance squad.

To help narrow down the right alternative, tell me:

• Are you primarily looking for a purely free/self-hosted open-source code base , or are you open to managed open-source SaaS?
• How heavily do you rely on Backstage's Scaffolder/Templates feature vs. just needing a read-only catalog and docs?

If you mean strictly open source, self-hostable, and not Backstage-derived, the answer is: there isn't currently a mature 1:1 replacement for Backstage's combination of software catalog + docs + portal UI. Backstage is unusually complete in that respect: its catalog, TechDocs, templates, search, and plugin model are all designed as one system.

That said, I'd shortlist these:

My pick: FrontStage, if you really want "not Backstage"

FrontStage is explicitly positioned as a lightweight Backstage alternative. It has a centralized catalog for services, APIs, databases, libraries and owners, YAML-based configuration, and Swagger/API documentation. It's MIT licensed and uses a relatively simple Python/FastAPI + Jinja/Alpine.js stack rather than Backstage's Node/TypeScript/React architecture.

The big caveat: it's very young. The repository currently has only a handful of stars, so I wouldn't make it the foundation for a large enterprise portal without doing a serious proof of concept.

Kratix is more interesting if your real goal is an IDP

Kratix is Apache-2.0 open source and is designed as a platform-building framework rather than primarily a catalog. Its strength is defining platform capabilities and self-service workflows around Kubernetes.

I would use it if your desired portal is eventually:

"Find my service → see its docs/owner/status → provision a database → create an environment → deploy → inspect resources" rather than simply:

"Find my services and read their documentation." Interestingly, Kratix itself can use Backstage as an optional UI, which tells you something about the current ecosystem: the orchestration and catalog problems are increasingly being treated as separate layers.

I would not choose Clutch today

Clutch is actually a very interesting architectural fit—it is Go/TypeScript, Apache-2.0, extensible, and built around discovering and interacting with infrastructure resources. But Lyft's repository now explicitly says it is slated for archival and that there will be no new features or updates.

So I wouldn't start a new portal on it.

What I'd build for a microservices organization

If your requirements are primarily catalog + docs, I'd actually consider a deliberately smaller architecture rather than trying to recreate Backstage:

                    Developer Portal
                          │
             ┌────────────┴────────────┐
             │                         │
       Service Catalog             Documentation
             │                         │
        PostgreSQL/DB             MkDocs/Docusaurus
             │                         │
      ┌──────┴──────┐             Git repositories
      │             │
   Git repos     Kubernetes
      │             │
      └──────┬──────┘
             │
       GitHub/GitLab APIs

Make the catalog metadata the canonical model:

service:
  name: payments-api
  owner: payments
  lifecycle: production

repository:
  url: ...

runtime:
  kubernetes:
    namespace: payments
    deployment: payments-api

documentation:
  path: /docs

interfaces:
  - type: openapi
    url: ...

dependencies:
  - orders-api
  - postgres

Then make the portal a relatively thin read/write UI over that model.

That's attractive because you avoid inheriting Backstage's biggest architectural commitment: its plugin ecosystem and entity model. Backstage's catalog is powerful precisely because it centralizes metadata and relationships, but reproducing the entire ecosystem is also what makes alternatives difficult.

My ranking for your specific question:

1. FrontStage — closest OSS experiment to "Backstage but much lighter."
2. Kratix + docs/catalog layer — best if you're really building an internal platform, not just a service directory.
3. Build a small catalog around MkDocs/Docusaurus — best if catalog + docs are genuinely the core requirement and you don't need Backstage's plugin ecosystem.
4. Clutch — architecturally interesting, but I would rule it out because of its archival status.

If you're willing to consider open-core/source-available or SaaS options, the landscape changes substantially—Port, Cortex, OpsLevel, and Roadie become much more compelling, but they aren't equivalent to "open-source foundation." Port, for example, describes its open-source work primarily around its integration/execution foundations rather than offering the entire portal as an OSS Backstage competitor.

My pick: FrontStage, if you really want "not Backstage"

FrontStage is explicitly positioned as a lightweight Backstage alternative. It has a centralized catalog for services, APIs, databases, libraries and owners, YAML-based configuration, and Swagger/API documentation. It's MIT licensed and uses a relatively simple Python/FastAPI + Jinja/Alpine.js stack rather than Backstage's Node/TypeScript/React architecture.

The big caveat: it's very young. The repository currently has only a handful of stars, so I wouldn't make it the foundation for a large enterprise portal without doing a serious proof of concept.

Kratix is more interesting if your real goal is an IDP

Kratix is Apache-2.0 open source and is designed as a platform-building framework rather than primarily a catalog. Its strength is defining platform capabilities and self-service workflows around Kubernetes.

I would use it if your desired portal is eventually:

"Find my service → see its docs/owner/status → provision a database → create an environment → deploy → inspect resources" rather than simply:

"Find my services and read their documentation." Interestingly, Kratix itself can use Backstage as an optional UI, which tells you something about the current ecosystem: the orchestration and catalog problems are increasingly being treated as separate layers.

I would not choose Clutch today

Clutch is actually a very interesting architectural fit—it is Go/TypeScript, Apache-2.0, extensible, and built around discovering and interacting with infrastructure resources. But Lyft's repository now explicitly says it is slated for archival and that there will be no new features or updates.

So I wouldn't start a new portal on it.

What I'd build for a microservices organization

If your requirements are primarily catalog + docs, I'd actually consider a deliberately smaller architecture rather than trying to recreate Backstage:

                    Developer Portal
                          │
             ┌────────────┴────────────┐
             │                         │
       Service Catalog             Documentation
             │                         │
        PostgreSQL/DB             MkDocs/Docusaurus
             │                         │
      ┌──────┴──────┐             Git repositories
      │             │
   Git repos     Kubernetes
      │             │
      └──────┬──────┘
             │
       GitHub/GitLab APIs

Make the catalog metadata the canonical model:

service:
  name: payments-api
  owner: payments
  lifecycle: production

repository:
  url: ...

runtime:
  kubernetes:
    namespace: payments
    deployment: payments-api

documentation:
  path: /docs

interfaces:
  - type: openapi
    url: ...

dependencies:
  - orders-api
  - postgres

Then make the portal a relatively thin read/write UI over that model.

That's attractive because you avoid inheriting Backstage's biggest architectural commitment: its plugin ecosystem and entity model. Backstage's catalog is powerful precisely because it centralizes metadata and relationships, but reproducing the entire ecosystem is also what makes alternatives difficult.

My ranking for your specific question:

If you want an open-source foundation for an internal developer portal with a software catalog + documentation, Backstage is still the reference point, but there are a few credible alternatives depending on what you value.

1. Cortex — not open source, but worth knowing as a benchmark

Cortex is a commercial option rather than an OSS foundation, but it’s often compared because it focuses heavily on service catalogs, ownership, scorecards, and engineering standards.

If your goal is:

• "Show every service owner"
• "Track production readiness"
• "Enforce golden paths"

…it is a useful reference for what a mature portal experience looks like.

2. Kratix — best if your portal is really a platform product

Kratix is less of a Backstage clone and more of a foundation for building internal platforms around Kubernetes. It is useful if your developer portal needs to drive self-service infrastructure workflows.

Good fit:

• Kubernetes-heavy organizations
• Platform teams building paved roads
• GitOps-oriented environments

Less ideal if your immediate need is simply:

• "Find my microservices"
• "Read service docs"
• "See ownership"

3. GitLab Catalog + docs — practical if you already live in GitLab

GitLab’s ecosystem can cover parts of this problem:

• repository discovery
• ownership metadata
• documentation
• CI/CD visibility
• deployment information

It is less of a customizable portal framework than Backstage, but it can avoid introducing another system.

4. OpsLevel — strong conceptually, but not OSS

OpsLevel is another commercial service catalog approach focused on service maturity and ownership. It is useful as a model for what teams often build internally.

5. Lightweight Backstage alternatives

There are smaller open-source projects trying to provide the catalog/docs experience without Backstage’s framework complexity. For example, FrontStage positions itself as a lighter developer portal with a YAML-based catalog and simpler operational footprint.

These are attractive when:

• you have dozens (not thousands) of services
• you want a simple catalog
• you don't want a React/TypeScript plugin ecosystem to maintain

The tradeoff is ecosystem maturity.

---

My shortlist by scenario

For most companies building an internal developer portal from scratch, I would still start by asking: do you need a portal framework, or do you need a catalog? Many teams discover the first valuable milestone is just:

• service inventory
• owner metadata
• repo links
• runbooks
• API docs
• dependency graph
• deployment links

A smaller catalog-first system can often deliver that faster than building a full portal platform. Backstage remains the strongest OSS choice when you expect the portal itself to become an internal product with custom workflows and plugins.

For most companies building an internal developer portal from scratch, I would still start by asking: do you need a portal framework, or do you need a catalog? Many teams discover the first valuable milestone is just:

---

My shortlist by scenario

Here are top web results for exploring this topic:

encore.dev·https://encore.dev/articles/backstage-alternatives**Backstage** Alternatives in 2026: Portals and Platforms Compared Most teams that reach for it are nowhere near Spotify's size, so they take on that build-and-operate cost without the scale that made it pay off, and they start looking at what else is out there. The OpsLevel·https://www.opslevel.com**Backstage** alternatives: 4 top tools to use instead | OpsLevel There are plenty of options out there for developer portals and microservice catalogs, from open-source projects to fully supported SaaS solutions. Every engineering team has different needs, but ther Port.io·https://www.port.io Top 4 Backstage Alternatives for 2025 - Port.io Backstage, the open source internal developer portal framework, has many challenges. The best alternatives can overcome these problems. Guideflow·https://www.guideflow.com 7 best internal developer platform tools for 2026 - Guideflow Blog Best open-source foundation: Backstage is the default starting point for teams that want to build their own internal developer portal and own the roadmap. Best enterprise-managed option: Red Hat Devel Reddit·https://www.reddit.com**Need** an Internal Developer Portal that is OSS, is there any besides ...Not that I know of. Which is probably why (I am guessing) commercial offerings are doing so well. People continuously confuse Backstage for a portal… DigitalAPI·https://www.digitalapi.ai Top 8 Backstage Alternatives for Developer Portals in 2026 Cortex: Best for growing teams that want a low-code, self-hosted portal to unify services and internal docs. Atlassian Compass: Best for teams already in the Atlassian ecosystem needing an integrated Mia-Platform·https://mia-platform.eu**Backstage** Alternatives to Make a Platform App ... and advanced integration, helping teams choose the right fit for their platform needs. These are the recommended alternatives to Backstage: Mia-Platform: An internal developer platform (IDP) with DuploCloud·https://duplocloud.com The 7 Best Open Source Internal Developer Platform Tools #1: Ansible. Organizations can use Red Hat's Ansible (opens in a new tab) to automate manual IT processes · #2: Argo CD. Argo CD (opens in a new tab) is an open source CI/CD platform certified by the Kestrel AI·https://usekestrel.ai The 5 Best Tools for Building an Internal Developer Platform in 2026 Backstage, the open-source developer portal framework Spotify donated to the CNCF, is the most widely adopted answer to the discoverability problem: a software catalog that maps every service to its o roadie.io·https://roadie.io/blog/7-best-developer-portals-for-enterprise-engineering-teams/7 Best Developer Portals for Enterprise Engineering Teams | Roadie If you decide to move away from the platform in two years, what happens to your data model? Open-source-based solutions like Backstage use standardized YAML entity definitions that you can export and

If you want a robust open-source foundation for a microservice software catalog and documentation without the heavy lifting and custom TypeScript maintenance of Backstage , your options narrow because most true portal frameworks are either Backstage or commercial SaaS alternatives (like Port or Cortex). However, specialized open-source tools fill these exact needs depending on where your microservices live.

Top Open-Source Foundations

• • What it is: A source-open, Kubernetes-native internal developer portal and configuration database.
  • Catalog & Docs: Automatically discovers and catalogs infrastructure, applications, and configurations from Kubernetes, AWS, and Git into a centralized database.
  • Best for: Teams deeply invested in Kubernetes and GitOps who want automatic service discovery rather than forcing developers to maintain manual catalog-info.yaml files.
• • What it is: An open-source developer tool that provides a dynamic, form-based UI for managing applications.
  • Catalog & Docs: Translates complex Helm charts into intuitive, validated web UI forms, hiding raw YAML complexity.
  • Best for: Lightweight application deployment and configuration management on Kubernetes without a massive platform engineering overhead.
• OpenMetadata + Docs-as-Code Engine
  • What it is: An open-source metadata platform that handles service dependencies, data assets, and APIs.
  • Catalog & Docs: Offers deep asset discoverability and data lineage. When paired with a dedicated documentation engine like MkDocs or Docusaurus , it forms a powerful search-driven catalog.
  • Best for: Organizations prioritizing data-heavy microservices, APIs, and deep search discoverability over pure infrastructure scaffolding.

If you tell me where your microservices are hosted (AWS, pure Kubernetes, multi-cloud) and how many services you manage, I can help you choose the right stack to minimize maintenance.

If open source is a hard requirement, the field gets surprisingly thin. Backstage is still the only mature, general-purpose OSS project that combines a software catalog + docs + portal UI + extensibility in one package.

That said, if you're willing to assemble the portal from focused OSS components, I’d choose a composable stack rather than another Backstage clone.

My recommendation

Use GitLab/GitHub metadata + Backstage-style entity model + MkDocs/Docusaurus for docs + a lightweight custom portal.

A practical architecture:

The important idea is to make the catalog data model portable, rather than making your portal itself the system of record. Backstage's catalog does this well by keeping entity metadata with the code and harvesting it into the catalog.

If you want an existing OSS platform

I'd look at OpenChoreo, but with an important caveat: it is primarily a developer platform for building/deploying/operating workloads, not a neutral software-catalog product. It currently uses a Backstage-powered portal itself, so it doesn't really satisfy "not Backstage" if avoiding Backstage is the goal.

Kratix is another interesting OSS foundation if your real goal is self-service platform engineering. It is much stronger as the orchestration/control-plane layer than as the catalog/docs UI.

What I would not choose for your requirement

• Port — excellent IDP, but proprietary SaaS rather than open source.
• Cortex — excellent catalog/scorecard product, but proprietary.
• OpsLevel — similarly commercial.
• Roadie / Spotify Portal — effectively managed Backstage rather than an alternative foundation.

The interesting architectural choice

If your primary requirement is "I need a catalog of 200+ microservices, owners, APIs, dependencies, runbooks and docs", I'd actually avoid building a giant IDP initially.

Start with:

Git metadata → catalog database → searchable web UI → docs renderer

Then add:

Kubernetes/deployments → observability → scorecards → self-service actions

That gives you a much smaller system than Backstage while retaining the most valuable part of it: a canonical, machine-readable representation of your software ecosystem.

If you tell me your stack (e.g. Kubernetes + GitHub/GitLab + ArgoCD + AWS/Azure/GCP), I can propose a concrete OSS architecture—including the catalog schema and how I'd model services, teams, APIs, dependencies, environments, and docs.

If you want an open-source (or source-open) foundation for an internal developer portal focusing on a software catalog and documentation —and you want to bypass the TypeScript/React maintenance overhead of self-hosting raw Backstage—the landscape breaks down into a few distinct architectural choices.

Note: True 100% open-source, out-of-the-box IDP frameworks that rival Backstage's exact scope are rare, because most alternatives in this category are commercial SaaS products. However, strong open-source and source-open alternatives exist depending on your stack.

Top Open-Source & Source-Open Foundations

1. Flanksource Mission Control (Source-Open / Kubernetes-Native)
   • What it is: A Kubernetes-native internal developer portal and GitOps orchestrator designed for Day-2 operations.
   • How it handles Catalog & Docs: It automatically discovers and catalogs your infrastructure, applications, and pipelines across Kubernetes and major clouds into a unified JSON database. It relies on declarative GitOps principles (backed by Git pull requests) rather than making you write custom React frontend code.
   • Best for: Teams deeply invested in Kubernetes and Flux/ArgoCD who want automated service discovery without building a portal from scratch.
2. EventCatalog (Open Source - MIT)
   • What it is: An open-source documentation tool built explicitly for microservices and event-driven architectures (using Domain-Driven Design principles).
   • How it handles Catalog & Docs: Unlike generic wikis, it acts as a visual service and event catalog where your architecture, services, messages, and schemas are versioned directly in Git.
   • Best for: Teams whose primary pain point is mapping out how microservices communicate, rather than orchestrating full cloud deployments.
3. Red Hat Developer Hub (Open Core / Enterprise Backstage)
   • What it is: Red Hat’s enterprise-ready distribution built upstream of the open-source Backstage project.
   • How it handles Catalog & Docs: It gives you the exact software catalog and TechDocs features of Backstage, but packages it with pre-tested plugins, enterprise support, and hardened security paths.
   • Best for: Organizations that want the power of Backstage with professional backing to minimize "do-it-yourself" platform maintenance.

Popular Commercial/SaaS Alternatives (With Free Tiers)

If you are open to shifting away from self-hosted open-source to a managed tool that avoids the "second full-time job" of maintaining a framework, look at:

• Port: A developer portal that replaces Backstage's code-driven approach with a visually configurable data model (blueprints). Excellent for fast setup of catalogs and scorecards.
• Atlassian Compass: Best if your microservices already live tightly integrated inside Jira, Bitbucket, and Confluence, handling component ownership and basic docs-as-code mapping.

To help narrow down the best path, tell me:

• Do you have dedicated platform engineers available to maintain a custom app, or do you need something low-maintenance?
• Are your microservices running primarily on Kubernetes , or a mix of serverless/ VMs/ cloud primitives?

If your main goal is an internal developer portal with a software catalog + docs for microservices, the short answer is: there are fewer true open-source replacements for Backstage than people expect. Backstage is still the most complete OSS “portal framework”; many alternatives are either SaaS products or focus on only one layer.

Good options to evaluate:

For actually open-source + self-hosted, I would shortlist:

1. Backstage (still the baseline)

Even if you want “besides Backstage,” it is worth using as the comparison point. It gives you:

• service catalog (owners, dependencies, lifecycle)
• TechDocs/docs-as-code
• scaffolding/templates
• plugin ecosystem

The downside is that you are building a product: authentication, plugins, upgrades, catalog hygiene, UX decisions, and integrations become your responsibility.

2. Build a lighter portal from OSS primitives

For many microservice organizations, a simpler stack works well:

• Catalog: OpenMetadata or a custom service registry
• Docs: MkDocs + Git repositories
• API catalog: Swagger UI / OpenAPI specs
• Runtime visibility: Argo CD, Kubernetes APIs, observability integrations

This avoids creating a giant portal application when your real need is “who owns this service, where are the docs, what depends on it?”

3. Consider an internal platform layer, not just a catalog

If your end goal is:

• “create a service”
• provision infrastructure
• deploy it
• register ownership
• expose docs
• enforce standards

then a catalog alone will feel incomplete. Tools like OpenChoreo aim more at the internal developer platform layer rather than just the portal UI.

My recommendation by organization size:

• <50 engineers: avoid building a Backstage clone; use Git-based docs + lightweight catalog conventions.
• 50–300 engineers: evaluate Backstage seriously, but budget ownership of the portal as a platform product.
• 300+ engineers / many teams: Backstage or a commercial IDP usually makes sense.

For a microservice-heavy company, I would start by defining the catalog model first:

• Service
• Owner/team
• Repository
• Runtime environments
• APIs/events
• Dependencies
• SLOs
• Operational docs
• Security/compliance status

The portal technology matters less than getting that model right.