OCI (Open Container Initiative)

The Open Container Initiative (OCI) publishes standards for container image formats, runtime behavior, and distribution. These interfaces support interoperability between compatible implementations; they do not guarantee that every image runs on every platform.

One disambiguation first, because the abbreviation is overloaded: OCI also stands for Oracle Cloud Infrastructure, a cloud provider. This entry is about the container standards body, and in writing it is worth spelling out which you mean on first use.

Image, runtime, and distribution

The specifications separate package structure, execution, and registry exchange.

• Image. Defines manifests, configuration, layers, and optional indexes that identify and describe packaged content.
• Runtime. Defines container configuration, the execution environment, and lifecycle operations for supported platforms. A runtime consumes a filesystem bundle and configuration such as config.json.

Distribution defines APIs for registry exchange, including pulling content and additional capabilities for pushing, discovery, and content management. Its minimum conformance requires the Pull API category; verify the capabilities needed for your workflow.

A toolchain builds the image, transfers it through registry APIs, verifies content and any required trust evidence, and prepares a bundle for a runtime. These are distinct steps with separate format, protocol, and policy requirements.

Why the separation is practically useful

Three consequences follow, and each explains something you can observe in a real estate.

• Builders and runtimes can differ. Switching tools can preserve the same image when the destination supports its format, OS, architecture, and required runtime features. Verify those conditions before assuming that no rebuild or adaptation is needed.
• Check the actual image format. Docker manifest V2 schema 2 and OCI image media types both exist. The informal term “Docker image” does not identify which format a particular manifest uses. Inspect supported media types rather than inferring them from the tool’s name.
• Registry exchange has conditions. Check supported APIs and media types as well as authorization and policy. Image-format conformance alone does not establish that a registry accepts a particular push, and distribution conformance can cover a narrower API scope than the workflow requires.

One nuance in the runtime specification worth knowing, because it contradicts a common assumption. The platforms it defines are freebsd, linux, solaris, windows, zos — and vm. A container is a packaging and lifecycle contract, not a commitment to a particular isolation technology, and some runtimes satisfy the contract using virtual machines underneath. “Container or VM” is therefore the wrong question; what the isolation boundary actually is, is the right one.

What the standards do not decide

Conformance is narrower than it sounds, and four things people expect to be standardized are not.

• How strongly a container is isolated. The specification describes a consistent execution environment; the strength of the boundary is a property of the runtime and the host kernel. See container for what actually does the isolating.
• Security policy. Images supply defaults such as the user, while runtime overrides and host policy determine effective permissions and reachability. Standards describe relevant fields and behavior; operators must choose and enforce the intended policy.
• Orchestration. Scheduling, scaling, restarting, and service discovery are outside these specifications entirely; that is a different layer with its own interfaces.
• Authentication and policy at the registry. Who may push and pull, retention, and signature verification are the registry’s and your organization’s decisions.

Conformance applies to the requirements of the implemented protocol scope. Ask which versions, platforms, media types, and capabilities a product supports. A claim of OCI compliance alone is insufficient evidence of drop-in interchangeability.

Where this matters most in practice is that the specified, content-addressable package is what makes verification possible at all — the basis for signing and checking what you run, covered under software supply chain security. The internal structure of the package and what follows from it is in container image, and how the pieces fit together is worked through in Isolated From What, Exactly.

References

• OCI Runtime Specification
• OCI Image Format Specification
• OCI overview
• OCI Distribution specification
• Docker Image Manifest V2 Schema 2
• OCI Image Configuration