Artifact Registry
The Distr Artifact Registry is a built-in, OCI-compliant registry designed for AI and software companies to distribute Docker images and Helm Charts, SBOMs and other OCI artifacts to self-managed and BYOC environments. It also includes tag-based access and licensing controls. The registry also provides detailed download analytics that let you monitor which versions of your software are being used by each customer.
Use it to publish versioned artifacts, enforce entitlement rules, and track consumption across your customer base.


Core capabilities
Section titled “Core capabilities”- Multi-artifact support: Distribute Docker Images, Helm Charts, Terraform Modules, Zarf packages, and any OCI-compliant artifact
- Software supply chain security: Store SBOMs and signatures for image verification
- Visibility: Get insights into which customers are using which artifacts and versions
- Open standards: Built on the OCI specification and compatible with existing tooling (Docker, ORAS, Helm, etc.)
- Built-in licensing (beta): Bind artifact versions to entitlements for fine-grained customer access control
Getting started
Section titled “Getting started”Want a quick overview of how it works? Watch this short walkthrough:
Artifact Registry UI
Section titled “Artifact Registry UI”Artifact List
Section titled “Artifact List”The Artifact List page lets you view all artifacts stored in your registry. It provides an overview of pull counts across all tags, along with insights into which users and customers are using each artifact.


Artifact Details
Section titled “Artifact Details”The artifact details page gives you a complete view of all tags associated with a specific artifact. You can see the OCI URL, upload date, and artifact size, along with pull counts for each tag.


Versioning Strategy
Section titled “Versioning Strategy”Every artifact has a versioning strategy, which determines how its versions are sorted on the artifact details page and which tag counts as the newest:
- Chronological versioning orders versions by the time they were pushed, whatever their tags are named. It is the default and accepts any tag.
- Semantic versioning orders versions by SemVer precedence, so
1.10.0is newer than1.9.0and2.0.0is newer than2.0.0-rc.1. A version with several tags is ranked by its highest one.
Under semantic versioning, every tag has to be a SemVer version with exactly three numbers, optionally prefixed with v: 1.2.3, v1.2.3 and 1.2.3-rc.1 are accepted, 1.2, latest and main are not.
The registry rejects a push of any other tag with 403 Forbidden and the error code DENIED.
Signature and attestation tags (sha256-<digest>.sig, .att, .sbom and .cosign) are exempt, so signing an image with cosign keeps working.
Change the strategy on the artifact details page. Switching an artifact that holds tags that are not SemVer versions to semantic versioning deletes those tags, after Distr has named them and you have confirmed. Their pull history is deleted with them, and pushed tags cannot be restored. The switch is refused if one of them cannot be deleted, for example because an entitlement grants exactly that version, and if none of the artifact’s tags is a SemVer version.
Public Artifacts
Section titled “Public Artifacts”A single artifact can be made public, so anyone who knows its name can pull it without credentials. This is meant for what you want to hand out freely, an installer image, a CLI, an agent chart or a public demo, while everything else in the registry stays private.
Open the artifact details page and pick Make public from the menu in the top right. The artifact then carries a Public badge everywhere it is listed, and Make private in the same menu requires credentials again. Only organization admins can change it.
Pulling without credentials
Section titled “Pulling without credentials”Docker, Podman, Skopeo, ORAS, Helm and anything speaking the HTTP API directly pull a public artifact with no setup at all:
docker pull registry.example.com/acme/my-image:1.0.0oras pull registry.example.com/acme/my-artifact:1.0.0helm pull oci://registry.example.com/acme/my-chart --version 1.0.0curl -sSL https://registry.example.com/v2/acme/my-image/manifests/1.0.0 \ -H 'Accept: application/vnd.oci.image.manifest.v1+json'Private artifacts still need credentials: log in with docker login, podman login or
helm registry login, using a PAT as the password.
Anonymous pulls are rate limited per client IP address, considerably more strictly than the pull
limits of the large public registries. A client that exceeds them gets 401 Unauthorized with a
request to authenticate and a Retry-After header. Authenticated pulls are never rate limited, so
a client that holds a PAT authenticates with it and pulls on, and a customer who runs into
the limit only has to log in. The answer is a 401 rather than 429 Too Many Requests because
OCI clients send their credentials only once they have seen a 401, so a 429 would lock out a
customer whose credentials are sitting unused in the client’s config file. Self-hosted instances can
change the limits, see the REGISTRY_ANONYMOUS_*
variables.
Every anonymous pull is recorded in the download analytics like any other pull, marked as Anonymous since there is no user or customer behind it.
Global Dashboard Artifact View
Section titled “Global Dashboard Artifact View”The main Distr dashboard also provides a global view of which artifacts each end customer has consumed, including version details and a health status.


Artifact Deletion
Section titled “Artifact Deletion”The Distr registry protects artifacts and tags that are referenced in entitlements, so customers keep access to their licensed software.
Deleting Artifact Tags
Section titled “Deleting Artifact Tags”You can delete individual tags from an artifact through the API, the UI and the registry itself (DELETE /v2/<name>/manifests/<tag>). However, the system enforces several validation rules to prevent breaking customer access.
Only named tags such as v1.0.0 can be deleted. A digest reference (sha256:…) is rejected with 400 Bad Request, which also affects clients that resolve a tag to its digest before deleting it.
When Tag Deletion is Allowed
Section titled “When Tag Deletion is Allowed”Tag deletion succeeds when all of these conditions are met:
- The tag exists
- No artifact entitlement grants all versions of the artifact
- If an entitlement grants exactly the version the tag points at, another tag must point at that version as well
- If it is the last tag of the artifact, no entitlement references the artifact at all
Deleting the last tag of an artifact deletes the entire artifact, as described in Deleting Artifacts.
When this happens through the registry API, the response carries a Warning header saying so.
A pull-through cache artifact is the exception: its last tag cannot be deleted, and the next sync restores a deleted tag unless it has been removed from the upstream repository.
What Deleting a Tag Removes
Section titled “What Deleting a Tag Removes”Deleting a tag also deletes the version the tag pointed at, so that its blobs can be reclaimed. For a multi-arch image, this extends to the per-architecture manifests the index referenced. A version is only deleted when nothing references it any more, that is when no other tag points at it and no other version references it (a per-architecture manifest shared with another index is kept).
An entitlement that grants a version deleted this way loses that version, and keeps every other artifact and version it grants.
Once a version is deleted, it can no longer be pulled by its digest. The blobs themselves are removed by the blob cleanup job, which a self-hosted instance has to schedule.
Example: Tag Deletion Scenarios
Section titled “Example: Tag Deletion Scenarios”Scenario 1: Safe deletion
Artifact: myapp Tags: v1.0.0, v1.0.1, latest (all point to different digests) License: References sha256:abc123 (v1.0.0’s digest)
Action: Delete tag “v1.0.1” Result: Success - v1.0.1 is not licensed
Scenario 2: Blocked deletion - licensed digest
Artifact: myapp Tags: v1.0.0 (points to sha256:abc123) License: References sha256:abc123
Action: Delete tag “v1.0.0” Result: Blocked (400) - Cannot delete last non-SHA tag for licensed digest
Scenario 3: Last tag deletes the artifact
Artifact: myapp Tags: v1.0.0 (only tag remaining) No licenses
Action: Delete tag “v1.0.0” Result: Success - the artifact myapp is deleted as well
Deleting Artifacts
Section titled “Deleting Artifacts”You can delete entire artifacts from your registry, which will cascade to all associated versions, tags and historical download data.
When Artifact Deletion is Allowed
Section titled “When Artifact Deletion is Allowed”Artifacts can be deleted when they are not referenced in any entitlement, including an expired one.
Best Practices
Section titled “Best Practices”- Check entitlements first: Before deleting artifacts or tags, verify they are not referenced in customer entitlements
- Use caution with tags: Deleting tags can affect customer access if not done carefully
- Monitor usage: Review the Downloads section to understand which artifacts and versions are actively used
- Mind the last tag: Deleting the last tag of an artifact deletes the artifact with it