[Sandbox] Apicurio Registry

[carlesarnal]

Project summary

A vendor-neutral, open-source API and Schema registry for governing schemas, API definitions, and AI agent artifacts in cloud-native environments.

Project description

Apicurio Registry is a runtime server system that stores, manages, and governs API definitions and data schemas across their entire lifecycle. It serves as both an API registry (for OpenAPI, AsyncAPI, GraphQL) and a schema registry (for Apache Avro, Protobuf, JSON Schema, and more), providing version management, compatibility enforcement, and content validation rules.

In cloud-native architectures built on microservices and event-driven patterns, schemas and API contracts must be managed centrally to ensure interoperability, enable independent service evolution, and enforce governance policies. Apicurio Registry fills this gap as the only fully open-source (Apache 2.0), multi-format schema and API registry in the ecosystem.

Key capabilities include: pluggable storage backends (PostgreSQL, Apache Kafka, GitOps, and KubernetesOps via ConfigMaps), a hierarchical rules engine for validity and compatibility governance, Confluent Schema Registry API compatibility (enabling drop-in replacement), serializer/deserializer libraries for Kafka, Pulsar, and NATS, a Kubernetes operator, client SDKs (Java, Go, TypeScript, Python), and a web-based UI.

Since version 3.1, Apicurio Registry also supports custom artifact types at deployment time and has become the first open-source registry to support AI agent artifacts — including A2A (Agent-to-Agent) Agent Cards, MCP (Model Context Protocol) prompt templates, and LLM model schemas — as first-class citizens, applying the same governance principles that have proven essential for APIs to the emerging AI agent ecosystem.

Org repo URL (provide if all repos under the org are in scope of the application)

N/A (not all repos under the org are in scope)

Project repo URL in scope of application

https://github.com/Apicurio/apicurio-registry

Additional repos in scope of the application

No response

Website URL

https://www.apicur.io/registry

Roadmap

Registry 3.x (view)

Roadmap context

Apicurio Registry 3.0 was released in 2024 as a major milestone, consolidating multiple storage-specific container images into a single artifact, redesigning the REST API, and introducing a hierarchical rules engine. The 3.1 release line followed with custom artifact types, API design editing (absorbing the former Apicurio Studio project), and AI agent artifact support.

The project's current roadmap focuses on:

• xRegistry specification alignment — Working toward compliance with the CNCF xRegistry specification (itself a CNCF Sandbox project), positioning Apicurio as a production-grade xRegistry implementation.
• AI agent ecosystem — Expanding support for agent discovery (A2A), context protocols (MCP), and LLM artifact governance, bringing the same versioning, validation, and compatibility guarantees to AI agents that the registry provides for APIs and schemas.
• Performance and scalability — Caching improvements, memory optimization, and OpenTelemetry tracing instrumentation.
• KubernetesOps storage — A new storage variant that uses Kubernetes ConfigMaps as the data source, enabling zero-dependency deployment using only native Kubernetes primitives. Integrates with ArgoCD and Flux for GitOps workflows where ConfigMaps are synced from Git repositories.
• Additional storage backends — MySQL support and continued GitOps backend maturation.
• SDK and tooling — Continued Kiota-based client SDK generation, VS Code extension, and CLI tooling.

Contributing guide

https://github.com/Apicurio/apicurio-registry/blob/main/CONTRIBUTING.md

Code of Conduct (CoC)

https://github.com/Apicurio/apicurio-registry/blob/main/CODE_OF_CONDUCT.md

Adopters

https://github.com/Apicurio/apicurio-registry/blob/main/ADOPTERS.md

Maintainers file

https://github.com/Apicurio/apicurio-registry/blob/main/pom.xml#L27-L69

Security policy file

https://github.com/Apicurio/apicurio-registry/blob/main/SECURITY.md

Standard or specification?

Apicurio Registry is a runtime implementation, not a specification. However, the project is actively working toward compliance with the CNCF xRegistry specification (a sibling CNCF Sandbox project). xRegistry defines a vendor-neutral document format and REST API for metadata registries. Apicurio aims to become a production-grade xRegistry implementation, complementing the specification with battle-tested runtime capabilities such as pluggable storage, content governance rules, serializer/deserializer libraries, and a web UI.

The project also implements the Confluent Schema Registry API (v7/v8) for drop-in compatibility with existing Kafka ecosystems.

Business product or service to project separation

Red Hat (now part of IBM for middleware engineering) produces a commercially supported distribution called "Red Hat build of Apicurio Registry." Apicurio Registry is also included as a component of IBM Event Streams. The relationship follows the standard upstream/downstream model common in the open-source ecosystem:

• The upstream Apicurio Registry project is maintained as an independent open-source project with its own identity, governance, release cadence, and community.
• Downstream products are built from upstream releases, with additional enterprise support, certification, and integration testing provided by the vendor.
• All development follows an upstream-first model — features and fixes are contributed to the open-source project before being incorporated into any commercial product.
• The project welcomes and actively encourages contributions from organizations and individuals outside of Red Hat/IBM. Contributors from companies such as Bloomberg, Amazon, Volvo, Axual, Riot Games, and others have contributed to the project.

Why CNCF?

We want to contribute Apicurio Registry to the CNCF for several reasons:

1. Neutral governance. As the middleware engineering team transitions from Red Hat to IBM, contributing to the CNCF provides a vendor-neutral home that ensures the project's long-term independence regardless of corporate organizational changes. This gives adopters confidence that the project is governed by the community, not by a single vendor.

2. Ecosystem alignment. The CNCF is the natural home for cloud-native infrastructure. Apicurio Registry already integrates closely with CNCF projects (Strimzi, CloudEvents, xRegistry) and operates in the same ecosystem as Kubernetes, Kafka, and event-driven architectures. Being part of the CNCF formalizes these relationships.

3. xRegistry convergence. With xRegistry now a CNCF Sandbox project defining the specification for metadata registries, having a production-grade implementation (Apicurio) in the same foundation creates a natural spec-to-implementation relationship — similar to the CloudEvents specification and its SDKs.

4. Increased adoption and visibility. CNCF membership increases project visibility and adoption, particularly among enterprises evaluating open-source registries as alternatives to vendor-locked solutions like Confluent Schema Registry (Confluent Community License) or cloud-provider-specific services (AWS Glue, Azure Schema Registry).

5. Community growth. CNCF provides the infrastructure, events, and community support to grow the contributor base beyond its current Red Hat/IBM core, which is essential for the project's long-term sustainability.

Benefit to the landscape

Apicurio Registry fills a clear gap in the CNCF landscape: there is currently no production-grade, multi-format schema and API registry among CNCF projects. While xRegistry defines the specification, it does not provide a runtime. Apicurio brings:

1. The only fully open-source (Apache 2.0) multi-format registry — supporting Avro, Protobuf, JSON Schema, OpenAPI, AsyncAPI, GraphQL, WSDL, XSD, and Kafka Connect schemas. Competing registries are either vendor-locked (Confluent Community License, AWS/Azure proprietary), single-format (Buf BSR is Protobuf-only), or limited in scope.

2. Complement to xRegistry — Apicurio can serve as the reference runtime implementation of the xRegistry specification, providing the production capabilities (storage, validation, compatibility enforcement, UI, serdes) that the spec alone cannot.

3. Bridge from APIs to AI agents — Apicurio is the first registry to support AI agent artifacts (A2A Agent Cards, MCP prompts) alongside traditional schemas, providing a unified governance layer for the emerging AI agent ecosystem.

4. Strimzi integration — Direct integration with the CNCF Strimzi project for Kafka-based schema registry use cases, including using Kafka (managed by Strimzi) as a storage backend.

5. Zero-dependency Kubernetes deployment — The KubernetesOps storage variant enables running a fully functional schema registry using only Kubernetes ConfigMaps as the data store — no database, no message broker, no Git server. This is the only schema registry that can run with zero external dependencies on Kubernetes.

6. Drop-in replacement for proprietary registries — Confluent Schema Registry API compatibility enables organizations to migrate from vendor-locked solutions to a truly open-source, CNCF-governed alternative.

Cloud native 'fit'

Apicurio Registry is fundamentally cloud-native in design and operation:

• Container-first deployment — Distributed as a single container image supporting all storage variants, configured via environment variables following the 12-factor app methodology.
• Kubernetes-native — Includes a Kubernetes operator for lifecycle management, and a KubernetesOps storage variant that uses ConfigMaps as the data store with zero external dependencies — no database, no message broker, no Git server required. The KubernetesOps backend uses the Kubernetes Watch API for real-time change detection and a blue-green switching pattern for zero-downtime updates.
• Pluggable storage — PostgreSQL for traditional deployments, Apache Kafka (KafkaSQL) for event-sourced architectures, GitOps for declarative infrastructure-as-code patterns, and KubernetesOps for managing artifacts as ConfigMaps with native ArgoCD/Flux integration.
• Microservices enablement — Provides the central schema governance layer that microservices architectures require for independent service evolution, contract testing, and data format interoperability.
• Event-driven architecture support — Serializer/deserializer libraries for Kafka, Pulsar, and NATS enable transparent schema enforcement in event streaming pipelines.
• Built on cloud-native technology — Implemented with Quarkus (the Kubernetes-native Java framework), supporting both JVM and native compilation.
• Observability — OpenTelemetry integration for distributed tracing, metrics export, and health endpoints.

Cloud native 'integration'

Apicurio Registry complements and integrates with several CNCF projects:

• Strimzi (CNCF Incubating) — Apicurio integrates natively with Strimzi-managed Kafka clusters in two ways: (1) as the schema registry for Kafka topics, configured via Strimzi's KafkaConnect custom resources, and (2) using the Strimzi-managed Kafka cluster as Apicurio's own storage backend (KafkaSQL mode).
• CloudEvents (CNCF Graduated) — Apicurio can be extended to support CloudEvents as an artifact type, and the registry's extensible architecture allows integration with CloudEvents-based event notification systems.
• xRegistry (CNCF Sandbox) — Apicurio is actively working toward xRegistry specification compliance, aiming to become a production-grade implementation of the xRegistry standard for metadata registries.
• Kubernetes (CNCF Graduated) — Apicurio provides a Kubernetes operator for automated deployment and lifecycle management. The KubernetesOps storage variant uses ConfigMaps as its data store via the Watch API, requiring zero external dependencies and enabling native integration with GitOps tools like ArgoCD and Flux.
• Argo CD / Flux (CNCF Graduated/Incubating) — The KubernetesOps storage variant is designed for GitOps workflows where ArgoCD or Flux syncs ConfigMaps containing schemas and API definitions from a Git repository. The registry automatically detects changes and serves the updated content with zero-downtime switching.
• gRPC (CNCF Incubating) — Apicurio manages Protocol Buffer schemas used in gRPC services, providing versioning and compatibility governance for .proto files.

Cloud native overlap

• xRegistry (CNCF Sandbox) — xRegistry defines a specification for metadata registries; Apicurio is a runtime implementation. These are complementary, not competing: xRegistry provides the standard API definition, while Apicurio provides the production runtime with storage, governance, UI, and serialization capabilities. The relationship is analogous to the OpenAPI specification and its implementations. Apicurio is actively working toward xRegistry compliance.
• Artifact Hub (CNCF Incubating) — Both are "registries," but for entirely different artifact types. Artifact Hub manages cloud-native deployment packages (Helm charts, OPA policies). Apicurio manages data schemas and API definitions. No functional overlap exists.

Similar projects

• Confluent Schema Registry (https://github.com/confluentinc/schema-registry) — Source-available under the Confluent Community License (not OSI-approved open source). Focused on Kafka ecosystems, supports Avro, Protobuf, and JSON Schema. Apicurio provides Confluent API compatibility while being fully Apache 2.0 licensed and supporting a wider range of artifact types.
• Karapace (https://github.com/Aiven-Open/karapace) — Open-source (Apache 2.0) Kafka schema registry by Aiven. Focused exclusively on Kafka with Confluent API compatibility. Narrower scope than Apicurio (no API definitions, no UI, no Kubernetes operator, no AI artifact support).
• xRegistry reference server (https://github.com/xregistry/server) — Reference implementation of the xRegistry spec. Focused on spec compliance rather than production features. Apicurio provides the battle-tested runtime with enterprise-grade storage, governance, and tooling.

Landscape

Yes, Apicurio Registry is already listed on the Cloud Native Landscape: https://landscape.cncf.io/?selected=apicurio-registry

Trademark and accounts

• If the project is accepted, I agree to donate all project trademarks and accounts to the CNCF

IP policy

• If the project is accepted, I agree the project will follow the CNCF IP Policy

Will the project require a license exception?

N/A. Apicurio Registry uses the Apache License 2.0, which is the CNCF's preferred license.

Project "Domain Technical Review"

We have completed the Day 0 portion of the General Technical Review questionnaire, which is maintained as a living document in our repository: https://github.com/Apicurio/apicurio-registry/blob/main/GENERAL_TECHNICAL_REVIEW.md

This document covers Scope, Usability, Design, Installation, and Security for the Sandbox (Day 0) phase. We plan to extend it with Day 1 and Day 2 sections as we progress toward Incubation.

Application contact email(s)

apicurio.registry@redhat.com, carnalca@redhat.com, eric.wittmann@redhat.com

Contributing or sponsoring entity signatory information

Name	Address	Type (e.g., Delaware corporation)	Signatory name and title	Email address
Red Hat, Inc.	100 East Davie Street, Raleigh, NC 27601, USA	Delaware corporation

CNCF contacts

@angellk was part of the review process for our previous application and is familiar with the project.

Additional information

Previous application context. Apicurio Registry previously applied for CNCF Sandbox in November 2023 (#72). The application was withdrawn in January 2024 due to two factors: (1) branding issues arising from multiple projects under the Apicurio umbrella (Registry, Studio, Data Models), and (2) a desire to first engage with the xRegistry specification effort. Both factors have been resolved:

• Branding resolved. Apicurio Studio has been deprecated and its functionality merged into Apicurio Registry 3.1.0. The project scope is now clear and self-contained.
• xRegistry engagement. The team has had some engagement with the xRegistry working group and is actively working toward spec compliance, creating the organic spec-to-implementation relationship anticipated in the previous application.

Project maturity. Since the 2023 application, the project has achieved significant milestones:

• Released Apicurio Registry 3.0 GA (June 2024) and 3.1.x series with 7 patch releases
• Consolidated from multiple container images to a single artifact
• Added custom artifact type extensibility
• Pioneered AI agent artifact support (A2A, MCP, LLM schemas)
• Added MCP server for AI/LLM integration with the registry
• Absorbed Apicurio Studio functionality
• 768 GitHub stars, 312 forks, 114 contributors from 30+ organizations
• Active release cadence (monthly releases throughout 2025-2026)
• Production deployments as part of IBM Event Streams and Red Hat Application Foundations

[angellk]

/vote

[git-vote]

Vote created

@angellk has called for a vote on [Sandbox] Apicurio Registry (#461).

The members of the following teams have binding votes:

Team
@cncf/cncf-toc-voters

Non-binding votes are also appreciated as a sign of support!

How to vote

You can cast your vote by reacting to this comment. The following reactions are supported:

In favor	Against	Abstain
👍	👎	👀

Please note that voting for multiple options is not allowed and those votes won't be counted.

The vote will be open for 2months 30days 2h 52m 48s. It will pass if at least 66% of the users with binding votes vote In favor 👍. Once it's closed, results will be published here as a new comment.