Plugin of the Month – September 2026: ORAS Artifact Manager

By default, Jenkins stores archived artifacts and stashes on the controller’s local disk (or on whatever storage backend an artifact manager plugin provides). The ORAS Artifact Manager Plugin takes a different approach: it stores them in any OCI-compliant registry, using ORAS (OCI Registry As Storage).

OCI registries were originally built to distribute container images, but the OCI ecosystem has since standardized on storing arbitrary content — SBOMs, Helm charts, signatures, and now Jenkins build artifacts — as regular OCI artifacts.

Once configured, every archived file and every stash produced by your jobs is pushed to the registry of your choice instead of piling up on the Jenkins controller’s disk:

From the build page, artifacts look exactly like artifacts always have — you don’t lose the familiar Jenkins UX, you just change where the bytes are stored.

The plugin doesn’t talk to registries directly. It relies on a dedicated ORAS Java API Jenkins plugin, which in turn bundles the official ORAS Java SDK.

This layering matters:

Because the underlying protocol is just OCI, any registry that speaks the OCI Distribution Spec works: Docker Registry, Harbor, Zot, GitHub Container Registry, Artifactory, and others.

This is the part that’s genuinely interesting if you’re curious about OCI internals, and not just "another storage backend."

The plugin maps each Jenkins job to an OCI repository, sanitizing the name in the process (for example folder/My Job becomes folder/my-job). For every build, it pushes a build root artifact, tagged with the build number, which acts as the anchor for everything produced during that build. Every archived file is then pushed as its own single-layer OCI manifest, linked back to that root artifact using the OCI 1.1 subject field — the same mechanism used for referrers like signatures or SBOMs on container images. Stashes follow a similar pattern, stored as tagged, gzip-compressed layers.

The two custom media types you’ll see on the manifests are:

Because files reference the build root through subject instead of a hand-rolled index file, the plugin can discover every artifact for a build with a single call to the registry’s referrers API.

You can see this structure yourself with the oras CLI. Given a build root tagged 13, asking the registry what refers to it:

Each of those digests is an independent manifest carrying a single layer (the file’s content) plus annotations that preserve the metadata Jenkins cares about — the archived path, the creation timestamp, and so on. A registry UI that understands OCI referrers, like Zot, will show exactly that relationship when you inspect the build root artifact:

Notice the annotations: io.jenkins.oras-artifact-manager.path tells you which archived file this manifest corresponds to, and standard OCI annotations like org.opencontainers.image.created come along for free.

The plugin is still in beta, and so is the underlying ORAS Java SDK — APIs on both sides may still change before things settle. If you’re evaluating it, start with non-critical jobs, keep an eye on the GitHub repository for updates, and report anything unexpected through its issue tracker.

If your Jenkins controllers are drowning in archived artifacts, or you already run an OCI registry for your container images and would rather not maintain a second storage system just for build outputs, the ORAS Artifact Manager Plugin is worth a look.

Stay tuned for next month’s Plugin of the Month, and feel free to suggest plugins you’d like to see featured!