What is the Open Container Initiative (OCI), and why does it matter?

Why standardization became necessary

In Docker's early years, "a Docker image" and "how a container runs" were both effectively defined by Docker's own proprietary implementation — there was no independent, vendor-neutral specification. As container adoption grew, other tools — including rkt, and later Kubernetes itself — wanted to work with container images and run containers without depending entirely on Docker's specific implementation. In response, the industry, with Docker itself as a founding contributor, created the OCI in 2015 to formally standardize the format. The OCI is hosted under the Linux Foundation.

The two core specifications

The OCI Image Specification defines exactly how a container image is structured — its layered filesystem format, its configuration (default command, environment variables, exposed ports), and how these are packaged and content-addressed. Any tool that produces an OCI-compliant image (Docker's docker build, Podman's podman build, buildah, Google's ko, and others) produces something any OCI-compliant runtime can consume, regardless of which tool built it.

The OCI Runtime Specification defines what a compliant runtime must do given an unpacked filesystem bundle and a configuration file: how to actually create the isolated, running container (setting up the namespaces and cgroups covered earlier) and manage its lifecycle. runc (see the architecture question) is the reference implementation of this spec, but it's not the only one. gVisor and Kata Containers are both OCI Runtime Spec-compliant runtimes that provide stronger isolation than runc's standard approach (gVisor via a user-space kernel intercepting syscalls, Kata via lightweight per-container VMs). Both can be swapped in for runc in an OCI-compliant system without the layers above (containerd, Docker, Kubernetes) needing to change.

Why this matters practically

Image built with: docker build, podman build, buildah, or any OCI-compliant builder
        ↓ (all produce the same standardized image format)
Runnable by: Docker, Podman, containerd (directly, or via Kubernetes), CRI-O,
             or any other OCI-compliant runtime

This is precisely what makes an image built and tested locally with Docker deployable, unchanged, onto a Kubernetes cluster using containerd or CRI-O directly. Recall from the Kubernetes stack that dockershim was removed: Kubernetes talks to containerd/CRI-O via the CRI, not to Docker itself. Yet Docker-built images run there without any modification, precisely because both sides honor the same OCI Image Spec. It also means an organization isn't locked into any single vendor's tooling. Switching from Docker to Podman for local development, or from one CRI-compliant runtime to another in a cluster, doesn't require rebuilding or reformatting existing images.

The broader pattern

The OCI is one instance of a recurring theme across the container ecosystem: standardized interfaces exist specifically so that different vendors' implementations of each layer can be mixed and matched, rather than requiring a single vendor's full, proprietary stack top to bottom. These interfaces include OCI for images/runtimes, CRI for how Kubernetes talks to runtimes, CNI for networking, and CSI for storage — several of these are covered in the Kubernetes stack. Recognizing this pattern — and being able to name OCI specifically as the image/runtime layer of it — signals a genuine understanding of why the container ecosystem looks the way it does today. It is more than just familiarity with Docker's specific commands.