OCI (Open Container Initiative)

The Open Container Initiative (OCI) is the body that publishes the specifications making container images and runtimes interchangeable between vendors. In its own words, it “develops specifications for standards on Operating System process and application containers.” Quotations here are from those specifications, read in September 2026; they are versioned documents and they grow.

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.

Two specifications, two jobs

The structure that matters is that packaging and running are specified separately.

• The image specification describes the package. It “defines an OCI Image, consisting of an image manifest, an image index (optional), a set of filesystem layers, and a configuration,” with the stated goal “to enable the creation of interoperable tools for building, transporting, and preparing a container image to run.”
• The runtime specification describes running it. It “aims to specify the configuration, execution environment, and lifecycle of a container,” where the configuration is “specified as the config.json for the supported platforms,” and the execution environment is specified “to ensure that applications running inside a container have a consistent environment between runtimes along with common actions defined for the container’s lifecycle.”

The handoff between them is a single sentence in the image specification, and it is the most useful line for understanding the whole arrangement: “once built the OCI Image can then be discovered by name, downloaded, verified by hash, trusted through a signature, and unpacked into an OCI Runtime Bundle.”

So the image is built, moved, verified, and then converted into the thing a runtime consumes. Everything before that sentence is one specification’s concern and everything after is the other’s.

Why the separation is practically useful

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

• Your builder and your runtime can differ. An image built by one tool runs under another, which is why a team can change how images are built without changing what runs them, and why platforms can replace their runtime without asking anyone to rebuild.
• “Docker image” is common usage rather than a format. The format is an OCI image; Docker is one tool that produces and consumes them. Saying “container image” is more accurate and avoids implying a dependency that does not exist.
• Registries are generic. Because the package is specified independently of who runs it, any conforming registry can store any conforming image — which is what makes “push here, pull there” work across vendors.

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. What a container may do, which user it runs as, what it may reach on the network — all decided by whoever launches it.
• 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.

And a note on what conformance means at all. The specifications use RFC 2119 keywords, and the image specification is explicit that “an implementation is not compliant if it fails to satisfy one or more of the MUST, MUST NOT, REQUIRED, SHALL, or SHALL NOT requirements for the protocols it implements.” That qualifier is doing real work: a tool can conform to the parts it implements while not implementing everything, so “OCI-compliant” on a product page is a claim about a scope you may want to ask about rather than a guarantee 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. Both read September 2026; these are versioned specifications.