此内容没有您所选择的语言版本。

Migrating Apicurio Registry deployments


Red Hat build of Apicurio Registry 3.1

Migrate from Apicurio Registry version 2.6 to 3.1

Red Hat build of Apicurio Registry Documentation Team

Abstract

This guide describes the major changes in Apicurio Registry version 3.x, and explains how to migrate an existing Apicurio Registry version 2.6 deployment to version 3.1.

Chapter 1. Migration from Apicurio Registry 2.6 to 3.x

Apicurio Registry 3.x includes a redesigned data model, a reworked REST API, and a refreshed SDK ecosystem compared to the previous Apicurio Registry 2.6 release. This section outlines the major changes between Apicurio Registry 2.6 and version 3.x so that you can plan your upgrade activities.

Because of the breaking changes in 3.x, there is no in-place upgrade. You must stand up a new 3.x deployment, migrate the persisted content, and update your client applications and automation.

When migrating to version 3.x, take the following areas into account:

1.1. Updated data model and governance

Apicurio Registry 3.x separates artifact metadata from version metadata and introduces first-class support for empty artifacts. These capabilities let you prepare governance metadata, rules, and branch structures before the first version exists. Additional highlights include:

  • Artifact metadata is now managed independently from version metadata.
  • Groups and artifacts can define custom labels to improve categorization.
  • Users can create and manage custom branches, and the latest branch is implemented as a system managed branch.

1.2. Core v3 REST API

The v3 REST API focuses on consistency and discoverability:

  • Group management now covers descriptions, owners, labels, and hierarchical rules.
  • New search endpoints at /search/groups and /search/versions expand discovery.
  • Version-focused endpoints streamline content management and require explicit Content-Type headers.
  • A dryRun query parameter replaces the former /test endpoints.
  • A dedicated Branch API enables multitrack artifact development.

1.3. Re-engineered Kafka storage variant

The KafkaSQL storage implementation is now optimized for stability and maintainability. The new design reduces startup times for large installations.

1.4. Generated SDKs powered by Kiota

Apicurio Registry 3.x ships Kiota-generated SDKs that mirror the REST API structure across languages. Updated libraries are available for Java, TypeScript, Python, and Go, providing lightweight, type-safe clients with minimal dependencies and consistent naming.

1.5. Migrating Apicurio Registry data

Use the export and import APIs to migrate persisted content from Apicurio Registry 2.6 into a new Apicurio Registry 3.x deployment. The APIs preserve artifact identifiers, metadata, and references so that downstream Kafka payloads remain compatible.

Apicurio Registry 3.x accepts the export archive generated from a 2.6 instance. Capture the archive from your existing deployment, provision the 3.x environment, and import the archive into the new cluster.

Prerequisites

  • Running Apicurio Registry instances of the 2.6 server you are exporting from and the 3.x server you are importing into.
  • Administrative credentials that allow access to the /apis/registry/v2/admin/export and /apis/registry/v3/admin/import endpoints.

Procedure

  1. Export all data from Apicurio Registry 2.6. The following command downloads registry-export.zip to your working directory:

    curl -X GET "http://old-registry.my-company.com/apis/registry/v2/admin/export" \
      -o registry-export.zip
    Copy to Clipboard Toggle word wrap
  2. Import the archive into Apicurio Registry 3.x by posting it to the admin import endpoint:

    curl -X POST "http://new-registry.my-company.com/apis/registry/v3/admin/import" \
      -H "Content-Type: application/zip" \
      --data-binary @registry-export.zip
    Copy to Clipboard Toggle word wrap
  3. Validate the migrated content. Compare artifact counts between the legacy and new deployments:

    curl "http://old-registry.my-company.com/apis/registry/v2/search/artifacts"
    Copy to Clipboard Toggle word wrap
    curl "http://new-registry.my-company.com/apis/registry/v3/search/artifacts"
    Copy to Clipboard Toggle word wrap

    Check that global rules were imported successfully:

    curl "http://new-registry.my-company.com/apis/registry/v3/admin/rules"
    Copy to Clipboard Toggle word wrap

1.6. Migrating Apicurio Registry client applications

Review every application that integrates with Apicurio Registry 2.6 to ensure compatibility with the v3 REST API, SDKs, and client libraries. Update dependency coordinates, reconfigure endpoints, and adjust automation to account for the new data model.

Prerequisites

  • Existing Apicurio Registry 2.6 applications that rely on the v2 REST API or legacy client libraries.
  • Access to the source code or deployment configuration for each application you must update.

Procedure

  1. Update your client configuration to target the v3 REST API base path:

    String registryUrl = "https://new-registry.my-company.com/apis/registry/v3";
    RegistryClient client = RegistryClientFactory.create(registryUrl);
    Copy to Clipboard Toggle word wrap

    Automation that previously targeted /apis/registry/v2 continues to function, but new functionality is only exposed through the v3 API.

  2. Refresh your client dependencies to the latest 3.x SDKs generated with Kiota. For Maven-based Java applications, use the new artifact identifier:

    <dependency>
        <groupId>io.apicurio</groupId>
        <artifactId>apicurio-registry-java-sdk</artifactId>
        <version>3.1.0.Final-redhat-00004</version>
    </dependency>
    Copy to Clipboard Toggle word wrap

    Install the TypeScript, Python, or Go SDKs through the respective package managers (npm install @apicurio/apicurio-registry-sdk, pip install apicurioregistrysdk, or go get github.com/apicurio/apicurio-registry/go-sdk).

  3. Align your integration code with the reorganized endpoints:

    • Manage artifact metadata at /groups/{groupId}/artifacts/{artifactId}.
    • Retrieve or create content exclusively through /versions endpoints.
    • Replace calls to /test endpoints with the dryRun query parameter.
    • Use /search/groups and /search/versions where you previously enumerated artifacts indirectly.
  4. Adopt the branch API if you need parallel development streams. Branches allow you to promote or merge versions without duplicating artifacts.
  5. If you build Kafka SerDes integrations, verify that serializers and deserializers still reference the correct registry URL and consider enabling group- or artifact-level rules introduced in 3.x to enforce compatibility upstream.

1.7. Updating Apicurio Registry configuration

Configuration keys in Apicurio Registry 3.x adopt a unified apicurio. namespace and reorganize authentication, eventing, UI, and storage settings. Review and update your deployment descriptors so that server-side properties match the new naming scheme.

1.7.1. Naming convention changes

Most configuration properties now start with the apicurio. prefix. The following examples illustrate common mappings:

Expand
Registry 2.x propertyRegistry 3.x property

registry.auth.roles.admin

apicurio.auth.roles.admin

registry.events.kafka.topic

apicurio.events.kafka.topic

registry.rest.artifact.deletion.enabled

apicurio.rest.deletion.artifact.enabled

1.7.2. Authentication and authorization

Authentication settings continue to rely on Quarkus OIDC support, but role-based properties moved to the new namespace. Update the property names and review any removed options:

Expand
Registry 2.x propertyRegistry 3.x property

registry.auth.enabled

quarkus.oidc.enabled

registry.auth.role-source

apicurio.auth.role-source

registry.auth.anonymous-read-access.enabled

apicurio.auth.anonymous-read-access.enabled

registry.auth.oidc.client-id

quarkus.oidc.client-id

registry.auth.oidc.token-endpoint

quarkus.oidc.token-path

# Registry 2.x
registry.auth.enabled=true
registry.auth.roles.admin=admin
registry.auth.oidc.client-id=my-client

# Registry 3.x
quarkus.oidc.enabled=true
apicurio.auth.roles.admin=admin
quarkus.oidc.client-id=my-client
Copy to Clipboard Toggle word wrap

1.7.3. Eventing and Kafka storage

Kafka-related settings now share the apicurio.kafkasql prefix. Update both event notifications and Kafka storage properties:

Expand
Registry 2.x propertyRegistry 3.x property

registry.events.kafka.topic

apicurio.events.kafka.topic

registry.kafkasql.bootstrap.servers

apicurio.kafkasql.bootstrap.servers

registry.kafkasql.topic.auto-create

apicurio.kafkasql.topic.auto-create

# Registry 3.x example
apicurio.events.kafka.topic=my-registry-events
apicurio.kafkasql.bootstrap.servers=kafka:9092
apicurio.kafkasql.topic=my-registry-storage
apicurio.kafkasql.topic.auto-create=true
Copy to Clipboard Toggle word wrap

1.8. UI and API configuration

The UI configuration is now grouped under apicurio.ui.*, and API diagnostics align with the new hierarchy:

Expand
Registry 2.x propertyRegistry 3.x property

registry.ui.contextPath

apicurio.ui.contextPath

registry.ui.features.readOnly

apicurio.ui.features.read-only.enabled

registry.ui.auth.oidc.redirect-url

apicurio.ui.auth.oidc.redirect-uri

registry.api.errors.include-stack-in-response

apicurio.api.errors.include-stack-in-response

1.8.1. Storage and database configuration

Database settings moved out of the Quarkus datasource namespace. Update JDBC configuration and storage selection properties:

Expand
Registry 2.x propertyRegistry 3.x property

quarkus.datasource.jdbc.url

apicurio.datasource.url

quarkus.datasource.username

apicurio.datasource.username

registry.sql.init

apicurio.sql.init

registry.storage.kind

apicurio.storage.kind

1.8.2. Migration checklist

  1. Inventory all configuration files, including deployment manifests and application.properties.
  2. Translate properties to their 3.x equivalents using the mappings in this section.
  3. Start a staging deployment of Apicurio Registry 3.x with the updated configuration and monitor logs for deprecated or unknown keys.
  4. Validate UI login flows, rule enforcement, and storage connectivity before promoting to production.

1.8.3. Common issues and resolutions

  • Authentication failures: confirm that apicurio.auth.roles.* properties mirror the expected role names and that OIDC redirect URIs use the new property names.
  • Missing Kafka settings: verify that all Kafka-related properties use the apicurio.kafkasql prefix and that optional settings removed in 3.x are not still present.
  • Database connection errors: ensure you migrated JDBC settings out of the quarkus.datasource.* namespace and updated secrets or ConfigMaps accordingly.

Appendix A. Using your subscription

Apicurio Registry is provided through a software subscription. To manage your subscriptions, access your account at the Red Hat Customer Portal.

Accessing your account

  1. Go to access.redhat.com.
  2. If you do not already have an account, create one.
  3. Log in to your account.

Activating a subscription

  1. Go to access.redhat.com.
  2. Navigate to My Subscriptions.
  3. Navigate to Activate a subscription and enter your 16-digit activation number.

Downloading ZIP and TAR files

To access ZIP or TAR files, use the customer portal to find the relevant files for download. If you are using RPM packages, this step is not required.

  1. Open a browser and log in to the Red Hat Customer Portal Product Downloads page at access.redhat.com/downloads.
  2. Locate the Red Hat Integration entries in the Integration and Automation category.
  3. Select the desired Apicurio Registry product. The Software Downloads page opens.
  4. Click the Download link for your component.

Revised on 2025-10-23 18:25:52 UTC

Legal Notice

Copyright © 2025 Red Hat, Inc.
The text of and illustrations in this document are licensed by Red Hat under a Creative Commons Attribution–Share Alike 3.0 Unported license ("CC-BY-SA"). An explanation of CC-BY-SA is available at http://creativecommons.org/licenses/by-sa/3.0/. In accordance with CC-BY-SA, if you distribute this document or an adaptation of it, you must provide the URL for the original version.
Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law.
Red Hat, Red Hat Enterprise Linux, the Shadowman logo, the Red Hat logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.
Linux® is the registered trademark of Linus Torvalds in the United States and other countries.
Java® is a registered trademark of Oracle and/or its affiliates.
XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.
MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.
Node.js® is an official trademark of Joyent. Red Hat is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.
The OpenStack® Word Mark and OpenStack logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation's permission. We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.
All other trademarks are the property of their respective owners.
返回顶部
Red Hat logoGithubredditYoutubeTwitter

学习

尝试、购买和销售

社区

关于红帽文档

通过我们的产品和服务,以及可以信赖的内容,帮助红帽用户创新并实现他们的目标。 了解我们当前的更新.

让开源更具包容性

红帽致力于替换我们的代码、文档和 Web 属性中存在问题的语言。欲了解更多详情,请参阅红帽博客.

關於紅帽

我们提供强化的解决方案,使企业能够更轻松地跨平台和环境(从核心数据中心到网络边缘)工作。

Theme

© 2025 Red Hat