Skip to content

Feature Proposal: Platform Engineering Software/Product Catalogue in GitLab

Everyone can contribute. Help move this issue forward while earning points, leveling up and collecting rewards.

Release notes

Propose an evolution of GitLab to provide a Software/Product Catalogue for platform engineering, extending beyond the existing CI/CD Catalog, offering a centralized, governed, discoverable catalogue of reusable internal platform products and services — enabling improved approval workflows, streamlined consumption by non-developers, and elevating GitLab to the central platform for multicloud/hybrid deployments, enterprise scale usage, and AI-driven knowledge and automation capabilities.

Problem to solve

While GitLab currently offers the CI/CD Catalog — enabling discovery, versioning and reuse of pipeline components — there is a growing need in platform engineering and DevSecOps contexts for a broader catalogue: internal services, infrastructure modules (IaC), platform APIs, runtime components, corporate libraries, etc. Moreover, many end-users (managers, business teams, infra operators) do not engage with code or pipelines and need simpler, visual interfaces for requesting, approving or consuming platform products. Without a unified catalogue experience, organizations often rely on external tools (e.g., ServiceNow, spreadsheets) for approvals, provisioning and visibility — leading to silos, duplication, limited governance and a fragmented user experience. Given GitLab already has many of the building blocks (versioning, CI/CD, policies, self-managed + SaaS modes), it is uniquely positioned to become the central platform for internal product discovery, request, approval, consumption and governance — yet a full “software/product catalogue for platform engineering” is not clearly exposed today. Additionally, with the increasing use of AI and large-language-models (LLMs) in enterprise settings — to encode workflows, surface knowledge, assist end-users by natural-language interfaces — GitLab could serve as the knowledge and automation hub for the organization: integrating catalogue of products + workflows + AI assistants, which would bring tremendous value for corporations managing complex, multi-cloud, hybrid environments.

Proposal

I suggest GitLab evolve the concept of catalogue to include a Software/Product Catalogue for Platform Engineering with the following capabilities:

  • A centralized catalogue dashboard or namespace listing “platform-products” such as reusable Terraform modules, internal platform services/APIs, standard container images, corporate libraries, infrastructure templates etc.
  • Rich metadata and taxonomy for each catalogue item: product name, version, owner, tags/category (e.g., “infrastructure”, “API”, “library”, “internal service”), status (active, deprecated), support level, dependencies.
  • Integration with the existing CI/CD Catalogue – catalogue items can link to pipeline components or modules and be consumed directly in pipelines.
  • Self-service discovery and consumption: end-users (non-developers) can browse the catalogue, request usage, track status, and see who owns a product without needing to open code or MR.
  • Approval workflows / routing built-in: support for defining request → approval → provisioning flows within the catalogue UI (e.g., business manager approves → infra operator initiates → DevOps executes) eliminating external ticketing systems for many use-cases.
  • Differentiated licensing or access levels: allow users who only consume or approve products in the catalogue (and do not author pipelines or code) to have a more lightweight license or access tier, expanding platform reach.
  • Governance, auditing & metrics: every catalogue action (publish, version update, request, approval, deprecation) generates an audit event; dashboards to measure product adoption, reuse rates, versions in use, requests approved, etc.
  • Provisioning self-service: authorized catalogue consumers may select a product (e.g., Terraform module or service) via UI, select parameters, trigger an automated pipeline or provisioner behind the scenes, with audit trail and approvals.
  • AI/LLM integration: with catalogue + metadata + workflows centrally in GitLab, the platform could integrate AI assistants (natural-language search, recommendation of products, auto-creation of workflows, chat assist for non-technical users) leveraging GitLab’s existing AI features (“GitLab Duo” etc). If possible, I’d like to know whether this feature is already on GitLab’s public roadmap — and at what stage. If not, I believe it should be considered for future roadmap.

Intended users

  • Platform Engineers — building and maintaining reusable platform products for internal consumption.
  • Software Developers — discovering and consuming platform products rather than reinventing them.
  • Infrastructure Operators / Systems Administrators — provisioning, managing and governing platform products.
  • Application Development Directors / Managers — approving or requesting platform products, driving reuse and platform efficiency.
  • Compliance / Audit Managers — tracking product governance, audit trails, reuse and policy adherence.
  • Business/Non-Technical Stakeholders — who need to browse, request or approve platform products via a simple interface without coding.

Feature Usage Metrics

Suggested success indicators:

  • Number of catalogue items (products) published (e.g., count of items/versions).
  • Number of requests submitted and approved via catalogue UI (by non-developer users).
  • Reuse rate: percentage of new projects consuming catalogue products versus building from scratch.
  • Average lead time: time between request and product availability.
  • Number or percentage of non-developer users (approval, business, infra) actively using the catalogue.
  • Reduction in duplicate artifacts or manual provisioning processes (qualitatively or quantitatively).
  • Number of audit events captured per catalogue item (publish, request, approve, deprecate) and number of obsolete versions detected.
  • User satisfaction: survey metrics on discovery/consumption experience of platform products.
  • AI assist metrics (optional): number of AI queries answered by catalogue assistant, number of recommendation clicks, reduction in time to find or request a product.

Does this feature require an audit event?

Yes — because this involves publishing and consuming platform products, managing versions, approvals and provisioning workflows, an audit event per major action (e.g., item published, version deprecated, request approved, provisioning triggered) is appropriate for traceability, compliance and governance.

Edited by 🤖 GitLab Bot 🤖