I want to build an internal developer portal. What's a good foundation for a software catalog and documentation that's not Backstage?

If you want “Backstage, but not Backstage”, I’d separate the problem into two pieces: the software catalog/data model and the documentation layer. That gives you more architectural freedom than adopting another all-in-one portal.

A good foundation

I’d build around:

• Catalog: a small service/catalog backed by PostgreSQL
• Source of truth: Git repositories + GitHub/GitLab APIs + Kubernetes/cloud discovery
• Metadata: YAML in repos plus API-ingested metadata
• Docs: Markdown/MDX in Git, rendered with Docusaurus or MkDocs
• Search: OpenSearch/Elasticsearch or PostgreSQL initially
• Relationships: explicit graph-ish relationships such as owns, depends_on, provides, consumes
• Portal UI: your own React/Next.js application over the catalog APIs
• Automation: GitHub Actions/GitLab CI for registration and validation

The key is to make the catalog API and schema the durable foundation rather than making the portal UI the center of the architecture.

Catalog model

I'd start surprisingly small:

kind: Service
metadata:
  name: payments-api
  description: Processes customer payments
  tags:
    - payments
    - production

spec:
  owner: payments-team
  lifecycle: production
  system: checkout

links:
  - type: repository
    url: ...
  - type: docs
    url: ...
  - type: dashboard
    url: ...

relations:
  - type: depends_on
    target: postgres-payments

Then have your catalog normalize metadata from multiple sources:

Git repos ───────┐
Kubernetes ──────┤
Cloud ───────────┼──> Catalog ingestion ──> PostgreSQL
CI/CD ───────────┤                         │
PagerDuty ───────┘                         ↓
                                      Catalog API
                                           │
                              ┌────────────┼────────────┐
                              ↓            ↓            ↓
                           Portal        Search        Docs

This is conceptually similar to what makes Backstage's catalog useful—centralized ownership, metadata and relationships—but without adopting Backstage's entity processor/plugin architecture.Backstage+1

Existing products worth considering

If you don't want to build the catalog itself, I'd look at these:

OpsLevel

opslevel.com is probably the most interesting non-Backstage foundation if you want a managed catalog + developer portal.

Its catalog can discover software from Git, Kubernetes, CI/CD and cloud sources, and it supports arbitrary component types and relationships. It also has centralized API documentation and automation/standards around catalog entities.OpsLevel+2

The interesting architectural property is that you're not forced to model everything as just "a service." You can represent other engineering objects as catalog components.

Port

Port is another managed IDP centered around a customizable software catalog. It's worth evaluating if you want the catalog to become a general engineering system of record rather than simply a service directory.

Cortex

Cortex is particularly oriented around service ownership, scorecards, standards and engineering health. I'd investigate it if the portal's primary job is helping teams understand and improve the state of their services.

Docusaurus/MkDocs + your own catalog

If your biggest requirement is documentation, this is the option I'd seriously consider.

Use:

• Docusaurus/MkDocs → documentation
• PostgreSQL → catalog
• Git → source of truth
• OpenAPI → API metadata
• Kubernetes → runtime metadata
• GitHub/GitLab → ownership/repository metadata
• React/Next.js → portal

You then get a portal that looks something like:

                    Engineering Portal
                           │
              ┌────────────┴────────────┐
              │                         │
        Software Catalog           Documentation
              │                         │
        ┌─────┼─────┐             Docusaurus
        │     │     │
      Teams Services APIs
        │     │     │
        └─────┼─────┘
              │
       Relationships
              │
     ┌────────┼─────────┐
     │        │         │
   GitHub   K8s      PagerDuty

That's a very different philosophy from Backstage: your catalog is a product/domain service, rather than a framework that happens to provide a catalog.

One thing I'd avoid

I wouldn't make documentation the authoritative source for catalog metadata.

For example, avoid:

README.md
  ↓
parse it
  ↓
figure out who owns the service

Instead:

Catalog
 ├── owner
 ├── lifecycle
 ├── service type
 ├── dependencies
 └── links
        ↓
Documentation references catalog entity

Documentation can explain what a service does; the catalog should answer what exists, who owns it, what it depends on, and where its operational resources are.

My architecture choice

If you're building this in-house, I'd use:

PostgreSQL + Git-backed YAML/JSON metadata + Docusaurus + OpenAPI + GitHub/GitLab/Kubernetes ingestion + a thin TypeScript API + Next.js UI.

I'd deliberately keep the first catalog schema to perhaps 10–15 fields and 5–6 relationship types. You can add sophistication once engineers actually use it.

If you want to buy rather than build, I'd evaluate OpsLevel, Port and Cortex against the same schema and ingestion requirements. I would not choose Roadie for this particular requirement because Roadie is explicitly a managed Backstage platform and its catalog is Backstage-compatible.roadie.io+1

The most important design decision isn't actually the portal technology: make the catalog API/schema independent of whichever UI you put on top of it. That gives you the option to replace the portal later without rebuilding your engineering metadata.

If you want to skip the heavy TypeScript/React maintenance overhead of Backstage but still need a pristine software catalog and documentation hub, you have some fantastic lightweight, commercial, and open-source foundations to choose from.reddit.com+1

Here are the best alternatives broken down by category:

1. The Flexible/Custom Data Model Route (SaaS)

• Port : Highly recommended if you want Backstage's flexibility without writing plugins. Port uses a completely customizable data model where you define your own entities (services, APIs, resources) via blueprints and map data in via GitHub Actions or CI/CD pipelines. It has a stellar UI, native scorecards, and action orchestration.qovery.com
• Atlassian Compass : If your engineering stack already heavily relies on Jira, Confluence, and Bitbucket, Atlassian Compass acts as a native developer hub. It provides a component catalog, tracks scorecards/health, and maps ownership directly to your existing Atlassian ecosystem.qovery.com

2. The Scorecard & Maturity Focus (SaaS)

• Cortex : Excellent if your main goal for a catalog is driving quality, automated testing, security compliance, and production readiness. Cortex features robust service catalogs paired with powerful scorecards and initiatives that gamify developer standards.qovery.com
• OpsLevel : Another brilliant lightweight alternative focused strictly on service maturity, microservice ownership, and defining "golden paths" without requiring a dedicated internal frontend engineering team to maintain it.qovery.com

3. The Docs-First & GitOps Approach (Open Source / Lightweight)

• MkDocs Material + Backstage-free GitOps : If your core requirement is robust technical documentation tied directly to a simple registry, a "Docs-as-Code" approach is often bulletproof. Using MkDocs with the Material theme , coupled with a simple service registry file (like a centralized services.yaml in a root infrastructure repo rendered via TechDocs alternatives or a small internal portal frontend), bypasses heavy frameworks entirely.
• CodiMD / Outline + Custom Portals : For teams that want a gorgeous, Notion-style internal wiki that doubles as technical documentation alongside a lightweight service directory, Outline is an open-source (source-available) knowledge base with a great API that integrates nicely into custom setups.

To help narrow down the best path, tell me:

• Are you looking for a fully managed SaaS or an open-source/self-hosted tool?
• How important are automated scorecards and quality checks versus just a static directory and docs?

Yes. If you specifically want to avoid Backstage as the foundation, I’d look at the problem as two layers:

1. Software catalog — services, APIs, libraries, teams, owners, dependencies, environments, lifecycle, links.
2. Documentation — docs-as-code, API/reference docs, runbooks, architecture docs, ADRs, search.

For 2026, the main non-Backstage foundations I’d investigate are Port, OpsLevel, and Cortex. They differ quite a bit in philosophy.Roadie+1

My architectural preference

If you're building an internal portal rather than simply buying an IDP, I'd seriously consider Port as the catalog layer + Docusaurus or GitBook as the documentation layer, rather than making the portal itself own all your documentation.

The important architectural decision is to make the catalog the source of metadata, not the source of prose.

For example:

                    Developer Portal
                           │
             ┌─────────────┴─────────────┐
             │                           │
       Software Catalog             Documentation
             │                           │
          Port/API                 Docusaurus/GitBook
             │                           │
     ┌───────┼────────┐          ┌───────┼────────┐
     │       │        │          │       │        │
   GitHub   K8s     Datadog    Markdown  OpenAPI  ADRs
     │       │        │
     └───────┴────────┘
             │
       Service metadata
       ownership
       dependencies
       lifecycle
       links
       health

Then a service page might effectively be:

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

  repository: github.com/acme/payments
  documentation: docs.acme.com/services/payments
  api: docs.acme.com/apis/payments

  dependencies:
    - postgres-payments
    - stripe
    - kafka-payments

  operational:
    dashboard: datadog/...
    alerts: pagerduty/...
    deployment: argocd/...

  metadata:
    tier: critical
    language: go
    runtime: kubernetes

That gives you a stable metadata graph while allowing the documentation system to evolve independently.

Port vs. OpsLevel

I'd investigate these two first.

Port is particularly interesting if your goal is to build a portal tailored to your organization. Its model is deliberately flexible: you define the entities and relationships you care about, then connect integrations and workflows around them.Roadie+1

OpsLevel is more opinionated around the operational lifecycle of software. Its catalog can ingest services from Git, Kubernetes, CI/CD and cloud systems, and it emphasizes ownership, relationships, standards, checks and scorecards.OpsLevel+1

So, roughly:

• “I want a programmable database/graph for everything engineering owns.” → Port
• “I want a catalog that actively tells teams whether their services meet our standards.” → OpsLevel
• “I want service maturity, scorecards and engineering governance to be first-class.” → Cortex

One thing I wouldn't do is make the portal a giant wiki. Keep documentation in Git and render/link it through the catalog. The catalog should answer “what is this, who owns it, what does it depend on, and where do I go next?”; the documentation system should answer “how does it work?”

If you tell me your stack (e.g. GitHub + Kubernetes + AWS + Terraform + Datadog + Slack) and roughly how many engineers/services you have, I can sketch a concrete non-Backstage architecture and data model for the portal.

For example:

                    Developer Portal
                           │
             ┌─────────────┴─────────────┐
             │                           │
       Software Catalog             Documentation
             │                           │
          Port/API                 Docusaurus/GitBook
             │                           │
     ┌───────┼────────┐          ┌───────┼────────┐
     │       │        │          │       │        │
   GitHub   K8s     Datadog    Markdown  OpenAPI  ADRs
     │       │        │
     └───────┴────────┘
             │
       Service metadata
       ownership
       dependencies
       lifecycle
       links
       health

Then a service page might effectively be:

Commercial no-code and managed alternatives like Port, Cortex, and Roadie offer turnkey software catalogs and integrated documentation without the heavy maintenance burden of self-hosting Backstage .northflank.com+2

Building an internal developer portal (IDP) outside of Backstage means choosing whether you want a managed open-source experience, a fully hosted no-code platform, or an ecosystem built directly into tools you already use (like Datadog or GitHub).reddit.com+2

Top Alternatives to Backstage

Breakdown of Non-Backstage Foundations

• Port: Operates as a completely customizable, schema-driven software catalog. Instead of writing TypeScript and maintaining a React frontend like Backstage, you define your entity types via a visual builder or API, ingest data using lightweight exporters, and map self-service actions to your existing CI/CD pipelines.northflank.com+1
• Cortex: Focuses heavily on service reliability, technical ownership, and scorecards. If your main goal for a catalog is defining gold standards (e.g., "every production service must have PagerDuty, a security review, and 80% test coverage"), Cortex handles this out of the box much faster than assembling Backstage plugins.qovery.com+2
• Roadie (Managed Backstage): If you like the Backstage model (YAML files in git, TechDocs) but don't want your engineering team spending 20% of their time maintaining Node.js plugins, upgrades, and hosting, Roadie runs the exact same open-source software as a managed cloud service.

To help narrow down the right foundation, tell me:

• Do you prefer an open-source/managed SaaS or a fully commercial no-code platform?
• What tools are you already using for CI/CD and observability (e.g., GitHub, GitLab, Datadog)?

Yes. If you want the catalog + docs foundation without taking on Backstage, I’d shortlist these:

Option	Best fit	Catalog	Docs	Main trade-off
Port	Most teams wanting a ready-made portal	Excellent, highly customizable	Good, typically integrates with existing docs	SaaS/vendor dependency
Cortex	Catalog + engineering standards	Excellent	Good, but less docs-centric	More opinionated around scorecards/maturity
OpsLevel	Service ownership + operational maturity	Excellent	Good	Less of a general-purpose docs platform
Build your own around Git + OpenAPI + MkDocs/Docusaurus	Teams wanting maximum control	You own it	Excellent	You have to build the portal UX/search/integrations

My default recommendation: Port

getport.io is probably the strongest "I want Backstage's catalog concept, but I don't want to operate Backstage" choice.

The important distinction is that you're not just buying a prettier service directory. Port gives you a configurable model for things like:

• services
• APIs
• databases
• environments
• teams
• domains
• cloud resources
• ownership
• dependencies
• scorecards
• self-service actions

That makes it a good system of metadata for the portal, while Git remains the source of truth for code and documentation.

Recent comparisons also put Port, Cortex, and OpsLevel in the managed-portal category, versus Backstage's open-source/framework model.Qovery+1

For documentation, I'd keep it separate

I wouldn't make the portal itself your documentation authoring system.

A nice architecture is:

                    ┌─────────────────────┐
                    │   Developer Portal   │
                    │                     │
                    │ Catalog + Search    │
                    │ Ownership           │
                    │ Dependencies        │
                    │ Scorecards          │
                    │ Self-service        │
                    └──────────┬──────────┘
                               │
          ┌────────────────────┼────────────────────┐
          ▼                    ▼                    ▼
      Git repos            Docs sites           APIs/specs
      source code          MkDocs/Docusaurus    OpenAPI
          │                    │                    │
          └────────────────────┼────────────────────┘
                               ▼
                         CI / automation

For docs, I'd strongly consider MkDocs if your engineers primarily write Markdown and you want a straightforward docs-as-code model, or Docusaurus if you want a richer documentation/product-site experience.

The key idea is that the catalog points to documentation rather than owning it. Backstage's own TechDocs follows a similar docs-as-code philosophy: Markdown lives alongside code and is generated into a documentation site.Backstage+1

If you want open source

I'd actually consider not choosing another Backstage-like monolith at all.

Build a relatively thin catalog service around a canonical schema such as:

kind: Service
metadata:
  name: payments-api
  owner: payments
  lifecycle: production
  tags:
    - critical

spec:
  repository: github.com/acme/payments
  documentation: https://docs.acme.internal/payments
  api: https://api.acme.internal/openapi.yaml

relations:
  dependsOn:
    - postgres-payments
    - kafka-payments
  consumes:
    - fraud-api

Then populate it automatically from GitHub/GitLab, Kubernetes, Terraform, PagerDuty, Datadog, CI/CD, etc.

That's an important architectural decision: don't make developers maintain a second database manually. Your catalog should be a projection of systems that already know the truth.

What I'd choose

• 50–500 engineers, small platform team: Port + MkDocs/Docusaurus
• 500+ engineers, heavy emphasis on engineering standards: Cortex or OpsLevel + existing docs platform
• Strong desire for open source/control: build a thin catalog service rather than recreating all of Backstage
• You want orchestration/provisioning as well as a catalog: look at Humanitec or Kratix rather than treating the portal as the entire platform

One thing I'd avoid is starting by designing the portal UI. Start by defining the catalog data model and ownership relationships. Once you have Service → Team → Repository → API → Dependencies → Docs → Runtime, the UI becomes considerably easier.

If you tell me roughly your team size, GitHub vs GitLab, Kubernetes/no Kubernetes, and whether you need self-service provisioning, I can propose a concrete architecture and compare Port vs Cortex vs a lightweight custom stack for your situation.

                    ┌─────────────────────┐
                    │   Developer Portal   │
                    │                     │
                    │ Catalog + Search    │
                    │ Ownership           │
                    │ Dependencies        │
                    │ Scorecards          │
                    │ Self-service        │
                    └──────────┬──────────┘
                               │
          ┌────────────────────┼────────────────────┐
          ▼                    ▼                    ▼
      Git repos            Docs sites           APIs/specs
      source code          MkDocs/Docusaurus    OpenAPI
          │                    │                    │
          └────────────────────┼────────────────────┘
                               ▼
                         CI / automation

For docs, I'd strongly consider MkDocs if your engineers primarily write Markdown and you want a straightforward docs-as-code model, or Docusaurus if you want a richer documentation/product-site experience.

The key idea is that the catalog points to documentation rather than owning it. Backstage's own TechDocs follows a similar docs-as-code philosophy: Markdown lives alongside code and is generated into a documentation site.Backstage+1

If you want open source

I'd actually consider not choosing another Backstage-like monolith at all.

Build a relatively thin catalog service around a canonical schema such as:

kind: Service
metadata:
  name: payments-api
  owner: payments
  lifecycle: production
  tags:
    - critical

spec:
  repository: github.com/acme/payments
  documentation: https://docs.acme.internal/payments
  api: https://api.acme.internal/openapi.yaml

relations:
  dependsOn:
    - postgres-payments
    - kafka-payments
  consumes:
    - fraud-api

Then populate it automatically from GitHub/GitLab, Kubernetes, Terraform, PagerDuty, Datadog, CI/CD, etc.

That's an important architectural decision: don't make developers maintain a second database manually. Your catalog should be a projection of systems that already know the truth.

What I'd choose

• 50–500 engineers, small platform team: Port + MkDocs/Docusaurus
• 500+ engineers, heavy emphasis on engineering standards: Cortex or OpsLevel + existing docs platform
• Strong desire for open source/control: build a thin catalog service rather than recreating all of Backstage
• You want orchestration/provisioning as well as a catalog: look at Humanitec or Kratix rather than treating the portal as the entire platform

One thing I'd avoid is starting by designing the portal UI. Start by defining the catalog data model and ownership relationships. Once you have Service → Team → Repository → API → Dependencies → Docs → Runtime, the UI becomes considerably easier.

If you tell me roughly your team size, GitHub vs GitLab, Kubernetes/no Kubernetes, and whether you need self-service provisioning, I can propose a concrete architecture and compare Port vs Cortex vs a lightweight custom stack for your situation.

If you want to skip the TypeScript/Node.js maintenance overhead, plugin hell, and heavy lifting of running Backstage, several strong contenders serve as a solid foundation for a software catalog and documentation.reddit.com+2

The best alternatives split into dedicated commercial/managed developer portals (low-maintenance, high-power data models) and lightweight open-source or native tool stacks.qovery.com+1

1. Dedicated SaaS Developer Portals (Low Maintenance)

• Port — A software catalog powerhouse that replaces Backstage's rigid YAML-in-Git setup with a fully customizable, data-driven entity model. You define your own blueprints (services, micro-frontends, resources, domains) and populate them via API, GitHub Actions, or Kubernetes operators. It features a great UI, self-service actions, and software scorecards out of the box without needing to write custom React/Node plugins.qovery.com+1
• Cortex — Excellent if your primary goal for an IDP centers around service quality, technical ownership, and scorecards. It features a robust catalog, brilliant action plugins, native documentation/catalog syncing, and automated scorecards that grade your services on security, reliability, and best practices.qovery.com+1
• OpsLevel — Highly focused on service maturity, ownership, and operational readiness. It provides a clean, fast service catalog and a powerful rules engine for checking service maturity (e.g., "does this service have an owner, a PagerDuty alias, and a passing CI build?").qovery.com+1

2. Ecosystem-Native & Integrated Catalogs

• Compass by Atlassian — If you are already deeply embedded in Jira, Confluence, and Bitbucket, Compass acts as Atlassian's native developer portal. It handles the component catalog, tracks scorecards, and maps out dependencies between services with deep Jira/Confluence context baked right in.qovery.com+1
• [Calamari / Lightweight Custom Stack (Not recommended unless DIY is required)] — Some teams ditch Backstage's framework entirely and instead use a headless setup: a graph database or PostgreSQL instance combined with an internal Retool or Internal app, syncing data via GitHub webhooks. However, buying a managed platform like Port usually pays for itself immediately compared to maintaining a DIY UI layer.

To help narrow down the best fit, tell me:

• Are you looking for an open-source tool or open to SaaS/commercial platforms?
• How important are self-service actions (like scaffolding a new repo via the portal) versus just a read-only catalog and docs?

Yes. If you want a software catalog + documentation foundation without Backstage, I’d shortlist Port, Cortex, and OpsLevel, with Port probably the closest fit if you want to build an extensible internal developer portal rather than just buy an engineering scorecard product.

My shortlist

The important distinction is that Port/Cortex/OpsLevel are portal/catalog products, while something like Kratix is platform infrastructure. Current industry comparisons make this same distinction: portals primarily surface your existing infrastructure, whereas orchestration platforms actually provision/run it.encore.dev

🥇 I'd start with Port

Port documentation

Port's interesting property is that the catalog is essentially a flexible data model, rather than a rigid collection of predefined service types. You can model things like:

Service
 ├── owner
 ├── repository
 ├── API
 ├── dependencies
 ├── Kubernetes workload
 ├── environment
 ├── AWS resources
 ├── documentation
 ├── dashboards
 ├── incidents
 └── maturity score

It also has ingestion paths for Git, CI/CD, Kubernetes, AWS and Terraform, plus APIs for feeding your own systems.docs.port.io

That makes it attractive if your real goal is:

"I want one canonical graph of everything our engineering teams own."

rather than:

"I want a prettier homepage for our developer documentation."

🥈 Cortex

I'd favor Cortex if your primary problem is service ownership, standards and engineering maturity.

It's particularly good when you want the catalog to answer questions such as:

• Who owns this service?
• Is it production-ready?
• Does it have an on-call rotation?
• Does it have an SLO?
• Is it meeting our security requirements?
• Which services violate our standards?

Current comparisons consistently position Cortex around service catalogs, ownership and engineering scorecards.stackbriefly.com

🥉 OpsLevel

OpsLevel is another strong choice if you want catalog + automated service maturity to be the center of the portal.

I'd put it ahead of Port when your platform team's primary deliverable is something like:

"Every production service should meet these 25 requirements, and I want to continuously know which ones don't."

Rather than:

"I want developers to interact with the platform through a highly customizable portal."

What I'd actually build

I wouldn't make documentation the database.

I'd separate the concerns:

                 Developer Portal
                        │
        ┌───────────────┼────────────────┐
        │               │                │
   Service Catalog   Documentation    Self-Service
        │               │                │
        ▼               ▼                ▼
   Port/Cortex       Git + MDX       CI/CD / Terraform
        │               │                │
        └───────────────┼────────────────┘
                        ▼
               Your engineering graph

The catalog should contain metadata and relationships:

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

  repository: github://acme/payments-api
  docs: docs/payments-api

  depends_on:
    - postgres-payments
    - kafka-payments

  runs_on:
    - kubernetes/payments-prod

  provides:
    - payments-api-v2

  links:
    - datadog
    - grafana
    - pagerduty

Then keep actual documentation in Git, preferably Markdown/MDX, and make the portal the discovery/navigation layer.

That avoids turning your portal into another proprietary wiki.

One other option I'd seriously consider

If you're deliberately trying to avoid the entire Backstage model, GitLab can be surprisingly compelling if you're already heavily invested in GitLab. You get repositories, documentation, CI/CD, issues, permissions and developer workflows in one ecosystem instead of stitching together a portal around them.

But if you're not already a GitLab shop, I'd choose Port over adopting GitLab specifically for the portal.

My recommendation

For a greenfield internal portal, I'd evaluate them in this order:

Port → OpsLevel → Cortex

And I'd make the proof-of-concept deliberately small:

1. Automatically discover ~20 real services.
2. Establish ownership.
3. Link repos, APIs, dashboards, incidents and docs.
4. Model dependencies.
5. Add 3–5 engineering standards.
6. Implement one self-service workflow.
7. Have 5–10 developers use it for two weeks.

The key evaluation isn't "which portal has the most features?" It's "which one can become the trustworthy system of record for our software without requiring a permanent portal engineering team?" That's where the alternatives differ substantially from self-hosted Backstage.www.qovery.com

If you tell me your stack (GitHub/GitLab, Kubernetes, AWS/GCP/Azure, Terraform, Jira, Datadog, PagerDuty, etc.) and roughly how many engineers/services you have, I can narrow this to a specific architecture and catalog schema.

If you want the core benefits of an internal developer portal (IDP)—a centralized software catalog, structured documentation, and service ownership—without the massive maintenance overhead and TypeScript/React plugin-hell of Backstage, you have several great paths depending on your budget and philosophy.qovery.com+2

The best foundations break down into lightweight open-source alternatives, managed SaaS platforms, and GitOps-native approaches:

1. The Flexible SaaS/Low-Code Alternatives (Closest to Backstage's Power)

If you want a powerful software catalog and scorecards without having to host and maintain a massive internal Node.js/React monorepo codebase:usekestrel.ai+1

• Port: Highly recommended if you hate Backstage's rigid entity model. Port offers a completely customizable, no-code/low-code data model where you define your own blueprints (services, APIs, resources) and build self-service actions using simple configurations.qovery.com+2
• Cortex or OpsLevel: Both excel heavily at the software catalog paired with robust service maturity scorecards, ownership mapping, and technical health tracking. They shift the burden entirely to a managed SaaS platform.encore.dev+2
• Atlassian Compass: A solid choice if your engineering org is already heavily invested in Jira, Confluence, and Bitbucket. It acts as a decentralized catalog for components, team ownership, and DevOps metrics.qovery.com+1

2. The GitOps / Documentation-First Approach (Lightweight & Simple)

If your primary goals are clean documentation and an easy-to-read service registry that lives right next to your code without an enterprise platform:

• MkDocs (with mkdocs-material ) + Backstage YAML Specs: You can actually adopt the Backstage catalog-info.yaml spec inside your microservices for metadata/ownership, but instead of running Backstage, write a simple internal micro-service or CI job that parses those YAML files and statically generates a gorgeous, searchable documentation site using MkDocs Material.
• Cortex / Port + TechDocs alternative: Combine a lightweight documentation host (like GitBook, Confluence, or internal Docusaurus sites) linked directly from a lightweight service registry like Port or a custom internal database.

3. Managed Backstage (If you like Backstage features, but not hosting it)

• Roadie: If you actually like Backstage's ecosystem and plugins, Roadie is fully managed Backstage as a SaaS product. You get all the benefits of the open-source catalog and TechDocs without dedicating a platform engineer to upgrade and patch the core framework.qovery.com+2

To help narrow down the best foundation for your team, tell me:

• Do you prefer an open-source / self-hosted tool or a managed SaaS product?
• How large is your engineering organization (number of services / developers)?
• Is your documentation currently hosted in Markdown/GitHub/GitLab or a wiki like Confluence?

If you want an internal developer portal without Backstage, I’d start by separating the problem into two foundations:

1. Software catalog (system of record for engineering assets)
2. Documentation platform (docs-as-code + discoverability)

Backstage bundles these, but you can build a cleaner stack by composing smaller pieces.

Option 1: Port (closest "Backstage replacement" experience)

port.io is probably the closest alternative if your goal is "we need a catalog, ownership, scorecards, and self-service workflows without building a portal framework." It uses a metadata model where you define entities such as services, teams, environments, databases, and relationships.TeKanAid

A typical stack:

• Catalog: Port
• Docs: Markdown in Git repos + mkdocs.org ordocusaurus.io
• Identity: Okta / Entra ID / Google Workspace
• Automation: GitHub Actions, GitLab CI, Terraform, Kubernetes operators

Good fit:

• 50–1000 engineers
• Platform team wants adoption quickly
• You don't want to maintain a portal application

Tradeoff:

• You are adopting someone else's product model rather than owning the whole UI/data model.TeKanAid

Option 2: Build your own catalog around a graph database

If you want maximum control, I would consider making the catalog a data platform rather than a portal.

Example architecture:

GitHub/GitLab
      |
      v
Metadata collectors
      |
      v
Catalog database
      |
      +--> Developer UI
      |
      +--> Search
      |
      +--> Automation

Possible components:

• Metadata store: Neo4j, PostgreSQL, or a document store
• Search: OpenSearch or Elasticsearch
• UI: React / Next.js
• Docs: Git-backed Markdown
• Events: Kafka, NATS, or webhooks

Your catalog entities might look like:

Service
 ├── owner → Team
 ├── repo → GitHub repository
 ├── runs_on → Kubernetes namespace
 ├── depends_on → Database
 ├── has_docs → Documentation
 └── has_slo → Reliability target

This is attractive if your organization already treats metadata as infrastructure.

Option 3: Use a dedicated catalog product

A few alternatives focus more narrowly on service ownership and maturity:

• cortex.io — strong on service catalog + engineering scorecards. It is often chosen when leadership wants visibility into standards like ownership, documentation, SLOs, and production readiness.TeKanAid
• opslevel.com — similar space, with emphasis on service maturity and operational readiness.
• atlassian.com — useful if you already live heavily in Jira/Confluence.

Documentation foundations

For docs, I would avoid putting everything into a portal database. Keep docs close to code.

Good patterns:

Docs-as-code

Repository:

payment-service/
 ├── src/
 ├── catalog.yaml
 └── docs/
      ├── architecture.md
      ├── operations.md
      └── runbook.md

Build with:

• mkdocs.org + Material theme
• docusaurus.io
• gitbook.com

The important part is not the renderer; it is that:

• docs are versioned with code
• ownership is explicit
• CI checks that required docs exist

A foundation I would choose today

For most companies:

                    Developer Portal UI
                            |
              +-------------+-------------+
              |                           |
        Software Catalog              Docs Search
              |                           |
        Port / Cortex / custom       MkDocs/Docusaurus
              |
        GitHub + Kubernetes + Cloud metadata

For a very large engineering organization with strong platform engineering:

Git repositories
      |
Metadata pipeline
      |
Postgres + graph model
      |
Custom portal
      |
Docs-as-code system

The biggest mistake is starting with the portal UI. The hard part is creating a reliable engineering metadata model: what is a service, who owns it, what depends on it, where it runs, and what "healthy" means. Once that exists, the UI becomes much easier.IoT Digital Twin PLM

If you want a "Backstage but simpler" foundation, I’d shortlist:

1. Port — fastest path to adoption.
2. Cortex/OpsLevel — best if scorecards and governance matter.
3. Custom catalog + docs-as-code — best if you have a platform team and want long-term control.

For a very large engineering organization with strong platform engineering:

Git repositories
      |
Metadata pipeline
      |
Postgres + graph model
      |
Custom portal
      |
Docs-as-code system

The biggest mistake is starting with the portal UI. The hard part is creating a reliable engineering metadata model: what is a service, who owns it, what depends on it, where it runs, and what "healthy" means. Once that exists, the UI becomes much easier.

If you want a "Backstage but simpler" foundation, I’d shortlist:

For most companies: