An API/Schema registry - stores and retrieves APIs and Schemas.
Build the project and run the registry with the in-memory storage variant:
Build requirement: JDK 21 or newer is required to build the project (the build tooling, e.g. Checkstyle, needs a Java 21+ runtime). The produced artifacts still target Java 17.
./mvnw clean install -Dlocal -DskipTests
cd app/
../mvnw quarkus:dev -Dlocal
(See DEVELOPING.md for build tier details and other options.)
This should result in Quarkus and the in-memory registry starting up, with the REST APIs available on localhost port 8080:
To start the user interface in development mode, hosted on port 8888 of your localhost:
cd ui
npm install
cd ui-app
./init-dev.sh
npm run dev
For more information on the UI, see the UI module's README.md.
Pre-built container images are published to Docker Hub for every commit to main.
Run the registry image:
docker run -it -p 8080:8080 apicurio/apicurio-registry:latest-snapshot
To also run the user interface, start its image as well:
docker run -it -p 8888:8080 apicurio/apicurio-registry-ui:latest-snapshot
Once both are running you can access:
For the full set of runtime configuration options (storage, deployment, and more), see the documentation. For the available image tags and the support policy, see Versioning & Support Policy below; for authentication, see Security.
Apicurio Registry follows Semantic Versioning:
- Minor releases (3.3.0, 3.4.0, ...): new features, enhancements, and bug fixes.
- Patch releases (3.3.1, 3.3.2, ...): CVE and security fixes only. No new features, no bug fixes.
Support window: the two most recent minor versions (latest and latest-1) receive patch releases for security issues. Older minors are end-of-life.
Docker image tags:
| Tag | Description |
|---|---|
3.3.0 |
Pinned to an exact release |
3.3 |
Floating tag — always points to the latest patch in the 3.3.x series |
latest / latest-release |
Always points to the most recent stable release |
latest-snapshot |
Most recent build from the main branch (unstable) |
OLM channels (Kubernetes operator): each minor version has its own OLM channel (e.g., 3.3.x). Subscribe to a channel to receive only patch updates within that minor. A rolling 3.x channel is also available for users who always want the latest minor.
You can enable authentication for both the REST APIs and the user interface using an OpenID Connect (OIDC) server. The same server and users are federated across the UI and the REST APIs, so a single set of credentials works for both. Set the following environment variables to enable it.
REST API:
| Env. variable | Description |
|---|---|
QUARKUS_OIDC_TENANT_ENABLED |
Set to true to enable (default is false) |
QUARKUS_OIDC_AUTH_SERVER_URL |
OIDC server URL |
QUARKUS_OIDC_CLIENT_ID |
The client for the API |
User interface:
| Env. variable | Description |
|---|---|
REGISTRY_AUTH_TYPE |
Set to oidc (default is none) |
REGISTRY_AUTH_URL |
OIDC auth URL |
REGISTRY_AUTH_REDIRECT_URL |
OIDC redirect URL |
REGISTRY_AUTH_CLIENT_ID |
The client for the UI |
Everything must be configured in your OIDC provider before starting the application. Registry supports a much wider range of authentication and authorization options than shown here — treat this as a starting point and see the security documentation for the full picture.
- Build setup, IDE configuration, and testing → DEVELOPING.md
- Contribution guidelines → CONTRIBUTING.md
- Runtime configuration, security, and deployment → full documentation
Apicurio Registry is a Cloud Native Computing Foundation Sandbox project.
Join us on the #apicurio channel on CNCF Slack.
Mailing lists:
- Development: cncf-apicurio-registry-dev@lists.cncf.io
- Security reports: cncf-apicurio-registry-security@lists.cncf.io (see SECURITY.md)
We abide by the CNCF Code of Conduct.
Copyright Apicurio Registry a Series of LF Projects, LLC. For web site terms of use, trademark policy and other project policies please see https://lfprojects.org/policies/.
