OCI

Definition

The Open Container Initiative (OCI) is a Linux Foundation governance project that defines open, vendor-neutral specifications for container image formats, container runtimes, and image distribution. It standardizes what a container image looks like on disk, how a runtime should execute it, and how registries should serve it, so that images built with one tool can run correctly on any OCI-compliant runtime regardless of vendor.

Overview

Before container standardization, Docker's image and runtime formats were the de facto standard simply because Docker popularized containers, which left other companies building competing runtimes and orchestration tools dependent on a single vendor's undocumented implementation details. The OCI was formed to remove that dependency by turning Docker's de facto formats into formally specified, vendor-neutral standards that any tool could implement independently and interoperably. The OCI publishes three core specifications. The Image Format Specification defines the layout of a container image, a manifest listing content-addressable layers, each a compressed filesystem diff, plus a configuration object describing environment variables, entrypoints, and other runtime settings. The Runtime Specification defines how a compliant runtime must take an unpacked image bundle and actually create and run a container, covering namespace and cgroup setup on Linux without mandating a specific implementation. The Distribution Specification defines the HTTP API a registry must expose to push and pull images, which is what allows any client to talk to any compliant registry, whether Docker Hub, GitHub Container Registry, or a private one, using the same protocol. Because these specifications were derived from Docker's original formats, most container tooling built afterward is largely compatible by design: Docker itself, along with runc, containerd, Podman, and CRI-O, all implement the OCI Runtime Specification, which is also what Kubernetes relies on through the Container Runtime Interface, since Kubernetes doesn't run containers directly but delegates to any OCI-compliant runtime underneath. This is what makes it possible to build an image with Docker and run it under a completely different runtime like containerd or Podman without modification. In practice, most developers never interact with the OCI specifications directly; they show up in tool documentation as OCI-compliant or an OCI image and matter mainly when choosing infrastructure, confirming that a given registry, runtime, or orchestrator will interoperate with the rest of a toolchain. Tool authors and platform engineers are the ones who read the specifications directly, when building a new runtime, registry, or a tool that needs to construct or inspect OCI images programmatically. The specifications standardize the container format and runtime contract, but they deliberately leave out orchestration, networking, and storage plugin behavior, which is why separate, related specifications like the Container Network Interface and Container Storage Interface exist alongside but outside OCI's scope. A tool being OCI-compliant guarantees image and runtime interoperability; it says nothing about how that tool schedules, networks, or manages the storage of the containers it runs.

Specification

• Image Format Specification defining container image layout on disk
• Runtime Specification defining how containers must be created and executed
• Distribution Specification defining the registry push/pull HTTP API
• Vendor-neutral governance under the Linux Foundation
• Adopted by Docker, containerd, Podman, CRI-O, and other runtimes
• Underpins how Kubernetes delegates container execution
• Derived directly from Docker's original de facto formats
• Enables interoperability across independently built container tools

Use Cases

Alternatives

Frequently Asked Questions

Related in Programming