The Open Container Initiative (OCI) is an open governance project under the Linux Foundation that defines vendor-neutral standards for containers: how a container image is packaged, how a runtime executes it and how registries distribute it. In containers, the OCI specifications are the reason an image built with one tool can be pushed to any compliant registry and run by any compliant runtime, from Docker and Podman to containerd in Kubernetes.
OCI was founded in 2015 by Docker, CoreOS and other industry members to prevent the container ecosystem from splitting into incompatible formats. Docker contributed its image format and its low-level runtime, runc, as the starting points. Today, OCI compliance is the baseline that container tools, cloud registries and orchestration platforms are expected to meet.
The three OCI specifications
OCI publishes three core specifications, each covering one stage in the life of a container. Together they separate building, shipping and running, so each stage can be implemented by different tools.
| Specification | What it defines | Reference or typical implementations |
|---|---|---|
| Image Format Specification | Manifest, configuration, layers and image index | Docker, Buildah, BuildKit, Kaniko |
| Runtime Specification | Filesystem bundle, config.json, container lifecycle | runc, crun, youki, gVisor, Kata Containers |
| Distribution Specification | HTTP API for pushing and pulling content | Docker Hub, Harbor, cloud registries |
The image and runtime specifications reached version 1.0 in 2017, and the distribution specification followed in 2021. Version 1.1 of the image and distribution specifications added formal support for artifacts and the referrers API, which attach signatures, SBOMs and attestations to an image.
How an OCI image is structured
An OCI image is a set of content-addressable blobs, each identified by a cryptographic digest, usually SHA-256. Because the identifier is derived from the content, any change produces a new digest, which makes images tamper-evident and deduplicable across registries and hosts.
| Element | Content | Purpose |
|---|---|---|
| Image index | List of manifests per platform | Multi-architecture images, for example amd64 and arm64 |
| Image manifest | References to config and layers with digests and sizes | Describes one runnable image |
| Image configuration | Entrypoint, environment, user, working directory, layer order | Turns layers into a runnable container |
| Layers | Tar archives of filesystem changes, gzip or zstd compressed | Stacked to form the root filesystem |
| Annotations | Key-value metadata | Source, version, license information |
Each blob carries a media type such as application/vnd.oci.image.manifest.v1+json, which tells clients how to interpret it. Images can also be stored on disk in an OCI image layout, a directory structure that tools use for offline transfer and air-gapped environments.
A client pulling an image first fetches the index or manifest, selects the entry matching its operating system and CPU architecture, and then downloads only the layers it does not already hold locally.
How the runtime specification works
The runtime specification does not deal with registries or layers. It starts from a filesystem bundle: a directory containing a root filesystem and a config.json file. That file describes the process to run, Linux namespaces, cgroup resource limits, mounts, capabilities and seccomp filters.
A higher-level engine such as containerd or CRI-O pulls the image, unpacks the layers into a bundle and then calls an OCI runtime to execute it. The runtime implements a standard lifecycle of create, start, kill and delete, plus a state query. Because this interface is standardized, operators can swap runc for crun for speed, or for gVisor or Kata Containers for stronger isolation, without changing images.
| Runtime | Isolation approach | Typical reason to choose it |
|---|---|---|
| runc | Linux namespaces and cgroups | Default reference runtime |
| crun | Namespaces and cgroups, written in C | Lower memory use and faster startup |
| gVisor (runsc) | User-space kernel intercepting system calls | Sandboxing untrusted workloads |
| Kata Containers | Lightweight virtual machine per pod | Hardware-level isolation |
OCI compared with related container standards
OCI is often confused with neighboring interfaces that operate at different layers of the stack. The comparison clarifies their roles.
| Standard | Layer | Defined by | Connects |
|---|---|---|---|
| OCI specifications | Image, runtime and registry formats | Open Container Initiative | Builders, registries and low-level runtimes |
| Docker Image Manifest V2 | Image format | Docker | Older Docker clients and registries |
| CRI (Container Runtime Interface) | Orchestrator to engine API | Kubernetes project | Kubelet and containerd or CRI-O |
| CNI (Container Network Interface) | Container networking plugins | CNCF project | Runtimes and network providers |
The OCI image format grew out of Docker Image Manifest V2 Schema 2, and the two are closely aligned, so modern tools convert between them transparently. Kubernetes uses CRI to talk to an engine, and that engine uses an OCI runtime underneath.
Practical significance and limitations
For practitioners, OCI compliance means freedom of tooling. An image can be built with BuildKit in CI, signed and stored in any compliant registry, scanned by a third-party tool and run under containerd on a cluster, all without format conversion.
- Registries as general artifact stores: Helm charts, WebAssembly modules and policy bundles are now commonly distributed as OCI artifacts.
- Compliance is not security: the specifications define formats, not whether an image contains vulnerable packages.
- Platform matching still matters: an image index without an arm64 manifest will not run on an arm64 node.
- Registry support varies: older registries may lack the referrers API or newer media types, so signatures may need fallback tagging schemes.
- Runtime configuration differs: two compliant runtimes can still differ in supported features, such as cgroup v2 options.
OCI work proceeds through open governance: a Technical Oversight Board and maintainers for each specification review proposals in public repositories, and changes go through release candidates before a version is finalized. This slow, consensus-driven process is deliberate, because a format that thousands of tools depend on must stay backward compatible. Teams evaluating a new tool should therefore check which specification versions it supports, not merely whether it claims compatibility.
In everyday language
Shipping containers transformed trade because every port, ship and truck agreed on the same box sizes and fittings. A container loaded in one country can be carried by any ship and unloaded by any crane.
The Open Container Initiative does the same for software containers. It sets common rules for how the box is packed, labeled and opened, so a program packaged with one tool can be stored anywhere and run by any compatible system.
Seen in the real world
A software company builds its services in a CI pipeline using BuildKit, producing multi-architecture images with amd64 and arm64 manifests in one image index. The images are pushed to a self-hosted Harbor registry, signed with Sigstore cosign, and a vulnerability report is attached as an OCI artifact referring to the image digest.
Production runs on a Kubernetes cluster using containerd with runc, while a separate node pool for customer-supplied plugins uses gVisor for sandboxing. Developers test the same images locally with Podman on their laptops. No image is ever converted between formats, because every tool in the chain follows the same OCI specifications.