OCI Artifacts: The Generic Envelope

"If it fits in a layer, we can ship it"

Imagine a shipping container. It was designed to hold cargo on a ship, but the same standard container can be loaded onto a truck or a train. The container doesn't care what's inside — it just provides a standard way to move things. The Open Container Initiative (OCI) specification works the same way for software artifacts.

The Open Container Initiative (OCI) is a Linux Foundation project that defines open standards for container image formats and distribution. Originally designed for Docker images, engineers realized the specification was generic enough to hold any file type. The protocol is just HTTP with a specific set of API endpoints — there's nothing inherently "Docker" about it.

An OCI Artifact consists of two parts:

• Manifest: A JSON document that lists the artifact's contents, their sizes, and their cryptographic digests (SHA-256 hashes). This is the "packing list."
• Blobs: The actual file content, stored as one or more layers. This is the "cargo."

When you push a Docker image, the layers are the filesystem layers. When you push a Helm chart, the single blob is the .tgz tarball. The registry doesn't care — it stores blobs and manifests the same way regardless of content type. The mediaType field in the manifest tells clients what kind of artifact they're dealing with.

Practical Use Cases

Because major cloud registries (AWS ECR, Azure ACR, Google Artifact Registry) already support the OCI distribution specification, you can store diverse assets without provisioning new infrastructure. The same IAM roles, network policies, and vulnerability scanning pipelines apply automatically.

1. Helm Charts

In Helm v3.8+, OCI is the standard distribution mechanism.

• Old Way: helm repo add my-repo https://charts.example.com — this points to an HTTP server hosting an index.yaml file. You manage a separate web server, and there's no content-addressable integrity guarantee.
• New Way: helm push my-chart-1.0.0.tgz oci://my-registry.example.com/charts — the chart is stored with a cryptographic digest. You can pin to an exact digest, not just a tag.

2. OPA Policy Bundles

Open Policy Agent (OPA) can pull policy bundles from OCI registries. This means your Rego policy files go through the same review, tagging, and promotion workflow as your application images. A cluster running OPA can be configured to pull policy:v1.4.2 from your registry, giving you the same version pinning and rollback capability you have for application deployments.

3. WebAssembly (WASM) Modules

Compiled WASM modules for serverless edge functions (e.g., Cloudflare Workers, Envoy filters) can be stored as OCI artifacts. This lets you version, sign, and distribute WASM binaries using the same toolchain as everything else.

4. Terraform Modules and Provider Binaries

Some organizations store internal Terraform modules as OCI artifacts, enabling the same promotion and retention policies used for application artifacts to apply to infrastructure code.

The architectural implication is significant: a single registry, a single auth system, a single audit log, and a single vulnerability scanner can now cover your entire software supply chain.