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 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.

When looking for an open-source foundation for a software catalog and documentation that isn't Backstage, you run into a fundamental industry reality: Backstage essentially won the open-source IDP framework wars , and almost every other major open-source competitor in the pure "developer portal UI" space has either pivoted or been commercialized into a SaaS offering (like Port, Cortex , or OpsLevel).

However, depending on whether you want a true portal UI , a docs-centric approach , or a composable platform backend , open-source alternatives exist outside the direct Backstage ecosystem:

• Headlamp — An open-source extensible developer-facing web UI for Kubernetes and cloud-native applications. While it leans heavily toward cluster and workload visualization rather than a general-purpose software catalog, it has a strong plugin architecture and serves as a lightweight control plane if your microservices live strictly on Kubernetes.
• Kratix — An open-source framework by Syntasso for building composable platform APIs rather than a pre-packaged web portal. Organizations often pair Kratix as a powerful backend engine (handling resource promises and pipelines) with a custom or lightweight frontend, avoiding the heavy React/TypeScript plugin maintenance trap of self-hosted Backstage.
• Cops zug / Wiki-based Docs-as-Code (BookStack / Wiki.js) — If your primary driver is a clean, searchable, structured documentation hub linked to service ownership rather than a complex enterprise scaffolding engine, pairing an open-source knowledge base like Wiki.js or BookStack with a Git-backed metadata sync script often gets teams to value faster than a full IDP framework.

If you want to narrow this down, let me know:

• Do you have a dedicated platform/frontend engineering team to maintain code, or do you need something low-maintenance / configuration-driven?
• Are you trying to manage just documentation and ownership , or do you need infrastructure provisioning/scaffolding too?

If your hard requirement is open-source + self-hosted + software catalog + developer docs, there’s an important wrinkle: there isn’t currently a mature, drop-in Backstage replacement that matches its catalog/docs combination without either using Backstage or assembling a few projects yourself.

My shortlist would be:

My recommendation: don't replace Backstage with another giant portal

If your primary requirements are “show me all our microservices, who owns them, what they depend on, and where their docs/API specs live”, I'd seriously consider a much thinner architecture:

                    Developer Portal
                         │
             ┌───────────┴───────────┐
             │                       │
       Service Catalog           Documentation
             │                       │
       Git/YAML metadata          Docusaurus
             │                       │
       ┌─────┴─────┐          Markdown/OpenAPI
       │           │
     GitHub      Kubernetes
       │           │
       └───── CI/CD ────────┘

Each service gets a small declarative metadata file:

apiVersion: platform.example.com/v1
kind: Service

metadata:
  name: payments
  description: Payment processing API
  owner: payments-team
  lifecycle: production

spec:
  repository: github.com/acme/payments
  documentation: /services/payments
  api: /apis/payments.yaml
  dependencies:
    - postgres
    - fraud-service
    - kafka

Then have CI continuously validate and publish that metadata into your catalog. Git becomes the source of truth, rather than building a database-heavy portal that developers have to keep updated.

Where OpenChoreo fits

OpenChoreo is probably the most interesting OSS project to evaluate if you want more than a catalog. It is an Apache-2.0, CNCF Sandbox project that provides a Kubernetes-oriented internal developer platform with application abstractions, CI/CD, GitOps, observability and a developer portal.

The catch for your specific question is that OpenChoreo itself uses a Backstage-based portal. Its architecture explicitly describes the developer portal as an extended Backstage fork.

So I wouldn't choose OpenChoreo if the goal is specifically “I want something other than Backstage.” I'd choose it if the goal is “I want an open-source foundation for the entire internal developer platform.”

What I'd choose for a microservice-heavy company

Small/medium platform team:
Docusaurus + Git-based service catalog + OpenAPI + Kubernetes/GitHub integrations.

This gives you a deliberately boring stack:

• Docusaurus → documentation
• YAML/JSON in Git → service metadata
• OpenAPI → API catalog/documentation
• GitHub/GitLab APIs → repositories, teams, PRs
• Kubernetes API → runtime/deployment information
• Prometheus/Grafana → health/observability links
• OIDC → authentication
• A thin React/Next.js UI → catalog/search/dependency graph

The advantage is that you aren't taking on the considerable platform-engineering surface area that comes with a framework like Backstage. Backstage itself describes its catalog, templates and TechDocs as separate major capabilities of the framework.

Larger Kubernetes platform team:
I'd evaluate OpenChoreo alongside Backstage rather than looking for another catalog product.

If you mainly need documentation:
Don't introduce an IDP at all. Use Docusaurus + OpenAPI + Git, then add a catalog UI when the metadata/problem warrants it.

One thing I'd avoid

I wouldn't pick Port, OpsLevel, Cortex, Roadie, or Compass if “open-source foundation” is a hard requirement. They're useful products in this space, but they're primarily managed/commercial alternatives rather than the self-hostable OSS foundation you're asking for. For example, OpsLevel explicitly positions itself as SaaS versus self-managed Backstage.

Bottom line: if you want to build your own portal, I'd use Docusaurus + a Git-native catalog model. If you want an open-source developer platform, evaluate OpenChoreo. If you want the most mature off-the-shelf OSS catalog/docs experience, Backstage remains difficult to beat—even if you don't ultimately choose it.

If you tell me roughly how many services/engineers you have and whether you're Kubernetes + GitHub/GitLab, I can sketch a concrete architecture and repo layout for the lean alternative.

Finding a direct, feature-complete open-source competitor to Backstage dedicated purely to a software catalog and documentation is surprisingly difficult. Most open-source projects in the platform engineering ecosystem focus on platform orchestration or Kubernetes management rather than acting as a general-purpose developer portal UI framework.

Aside from Backstage, the most viable open-source and source-open foundations available include:

• Flanksource Mission Control : A source-open, self-hosted, Kubernetes-native internal developer portal designed heavily around GitOps. It features a unified catalog that automatically discovers and catalogs infrastructure, applications, and pipelines into a central database, and includes robust health-monitoring dashboards.
• OpenChoreo : A CNCF Sandbox project that provides an open-source developer platform rather than just a UI toolkit. It brings together developer portal abstractions, GitOps, and control planes, making it a good fit if you want a pre-integrated cloud-native experience without assembling every piece from scratch.
• Kratix : An open-source framework for building composable internal developer platforms. While it isn't a drop-in service catalog UI, it acts as an "intelligent glue" using "Promises" to establish a clear API contract between app and platform teams, letting you orchestrate cloud services and infrastructure declaratively.
• The Docs-as-Code + Lightweight Registry Combo : For many teams, deploying a full portal framework introduces too much maintenance overhead. A common alternative open-source pattern is combining a static documentation site generator (such as MkDocs ) with a standard OpenAPI/Swagger specification registry stored directly in version control alongside your microservices.

To help narrow down the right alternative, tell me:

• Are you looking for a self-hosted UI portal or a declarative platform framework?
• Do you primarily run workloads on Kubernetes , or a mix of VMs and serverless?

If you want an open-source foundation specifically for a software catalog + documentation and you've ruled out Backstage, the field gets much smaller. Backstage remains the most mature OSS option, and most alternatives are commercial SaaS (Port, Cortex, OpsLevel, Compass, etc.).

Here are the strongest open-source approaches:

1. Open Service Portal

This is probably the closest thing to "Backstage, but different."

It includes:

• software catalog
• documentation
• self-service workflows
• service templates
• GitHub integration

The downside is maturity. It's a relatively new project and is explicitly built around many of the same ideas that made Backstage successful.

Best if you want:

• OSS
• Kubernetes
• platform engineering
• don't mind contributing upstream

---

2. MkDocs or Docusaurus + your own catalog

Many companies discover they don't actually need a huge portal.

A surprisingly effective architecture is:

GitHub
   │
   ├── service.yaml
   ├── mkdocs.yml
   └── docs/

            │

Catalog indexer
    (Go/Python)

            │

Postgres

            │

React / Next.js portal

Each microservice owns:

• owner
• repository
• OpenAPI
• runbook
• dependencies
• SLOs
• docs

The portal simply indexes those files.

Advantages:

• tiny operational footprint
• docs stay in repositories
• no plugin ecosystem to maintain
• easy to customize

This scales well into hundreds of services if the catalog schema is kept simple.

---

3. Wiki.js or Docmost

If your primary pain point is documentation discoverability rather than platform engineering:

• authentication
• search
• Markdown
• diagrams
• versioning
• permissions

then these tools provide an excellent documentation hub.

You can bolt on a lightweight service catalog by indexing YAML manifests from your repositories.

This approach is dramatically simpler than maintaining a full developer portal.

---

4. Build a lightweight catalog service

If your organization already has:

• GitHub
• Kubernetes
• Argo CD
• Prometheus
• Grafana

you may only be missing a searchable catalog.

A minimal catalog service can expose:

service:
  name: payments
  owner: team-finance
  language: go
  repo: github.com/org/payments
  kubernetes:
    namespace: payments
  docs: /payments
  openapi: openapi.yaml
  pagerduty: finance

From there you can automatically enrich it with:

• GitHub metadata
• Kubernetes status
• Argo CD health
• CI build status
• API specs
• observability links

This is often much less work than adopting a large framework.

---

My recommendation by team size

• 20–100 engineers: Docusaurus or MkDocs + a custom catalog service is often the best balance of simplicity and flexibility.
• 100–500 engineers: Consider a lightweight custom portal backed by a catalog database and integrated with your existing tooling.
• 500+ engineers: Backstage still has the strongest ecosystem, but if you want to stay fully open source and avoid it, Open Service Portal is the closest project pursuing the same vision, though it's less mature.

One observation from engineering communities is that many teams end up needing only a subset of Backstage's capabilities—typically service discovery, ownership, documentation, and links to operational tools. Building around those core needs can yield a portal that's easier to maintain than adopting a highly extensible framework.