Skip to content
As OCI registries support multiple artifact types, we need a means to understand the artifacts by their manifests
Branch: master
Clone or download
Fetching latest commit…
Cannot retrieve the latest commit at this time.
Type Name Latest commit message Commit time
Failed to load latest commit information.
cnab reset readmes to include config.mediaType Feb 8, 2019
container-image-docs First draft of Docs in an OCI Index Feb 27, 2019
LICENSE Initial commit Jan 26, 2019 readme shuffling Feb 11, 2019 Update Feb 13, 2019 Update Feb 12, 2019
mediaTypeMappings.json reset readmes to include config.mediaType Feb 8, 2019 Updating type string May 11, 2019

Using OCI Compliant Registries as Artifact Registries

OCI Distribution is evolving to support additional artifact types. This repo presents information on how registries and artifact authors can collaborate to have all OCI compliant registries be capable of supporting any new OCI compliant artifact.


The OCI image-spec and OCI distribution-spec were designed to support platform neutral container images. It turns out that flexibility can be used for additional artifacts.

This repository proposes a set of templates and guidance for registries to support new artifact types, and what a new artifact author would need to store and retrieve their artifact from an OCI compliant registry.

Table of Contents


Docker brought great usability to the evolving container ecosystem by providing end to end experiences. These experiences included a registry storing secured, layered, optional signed, images.

The experience to call docker run [registry]/image:[version] turns out to be productive and powerful, and not limited to just container images.

As new artifacts evolve, storing them in a registry for easy referencing turns out to be just as powerful.

Helm example

helm upgrade myBlog 
    --reuse-values \
    --set wordpressBlogName=myBlog

CNAB example

duffle install myBlog 

Azure example

az deployment create

aws example

aws ecs run-task --task-definition

Leveraging Registries for Additional Artifacts

The major cloud vendors have implemented docker/distribution to support the registry api, implementing their cloud specific storage and security semantics. Additional products and projects like Codefresh, JFrog, Harbor have built experiences around docker/distribution.

With the volume of development and production activity, these registries are hardened, secured & highly scalable and available.

By evolving registries to support additional artifact types, customers and cloud vendors can leverage their existing registry investments.

Understanding Artifact Types

If we assume registries can host various artifact types, the next set of question include:

  • How does one reason over the various artifact types in a registry?
  • How would a registry listing represent the different artifact types?
    • Can a registry show an icon and/or a short text identifier?
  • If a registry listings wishes to provide optimized action points, such as gestures to deploy Helm Chart, ecs task, or deploying an image directly to a container service; how would the UI know which actions to surface on which artifact types?
  • How would vulnerability scanners know how to scan the various artifacts? Would scanners perform different scanning routines, based on the artifact type? How do they know the type?

Registry Listing

While tools should have knowledge of the artifacts they work with, so should a registry. By providing information on the artifact, registries can display artifacts, with context and details.


artifact reference icon type actions
samples/image/hello-world:1.0 container image docker run ...
samples/helm/hello-world:1.0 helm chart helm install ...
samples/cnab/hello-world:1.0 CNAB duffle install ...
samples/arm/hello-world:1.0 arm az deployment create ...
samples/ecs-task/hello-world:1.0 ecs-task aws ecs create-service ...
You can’t perform that action at this time.