OCI (Open Container Initiative) is an open governance project under the Linux Foundation that defines vendor-neutral specifications for container images, runtimes, and distribution, so containers built with one tool run consistently across any compliant platform.
OCI
OCI (Open Container Initiative) is an open governance project, hosted under the Linux Foundation, that maintains vendor-neutral specifications for containers. It grew out of Docker’s early formats and exists so that a container image built with one tool runs consistently on any runtime or registry that conforms to the specs. In practice OCI is the reason “container” stopped meaning “Docker” and became a portable, interoperable unit of software.
- Image Specification - Defines the on-disk format of a container image — layers, configuration, and manifest — independent of any single vendor.
- Runtime Specification - Describes how to unpack and execute a container so runtimes like runc, containerd, and CRI-O behave the same way.
- Distribution Specification - Standardizes the registry API for pushing and pulling images, which is why OCI registries now store more than just container images.
- Vendor neutrality - Governed in the open so no single company controls how containers are built, shipped, or run.
For API work, OCI matters because it standardizes the units APIs and microservices ship in. Almost every modern API deployment — Kubernetes, serverless container platforms, CI/CD pipelines — assumes OCI-compliant images, so the packaging of an API is now as much a standard as the interface itself. The OCI distribution spec has also been repurposed as a general artifact store, meaning OpenAPI definitions, Helm charts, and other API governance artifacts increasingly travel through the same registries as the containers they describe. Containers, as I wrote years ago, do for APIs what APIs did for companies — and OCI is what keeps that portable.
Open source tools that implement this standard
Harvested from this standard's own governing organisation, with the license read from each repository rather than assumed. The role is what the tool does to the specification, from the shared vocabulary — so an agent holding one of these documents can resolve straight from a goal to a tool.
| Tool | Role | License | What it does |
|---|---|---|---|
| runc | runs |
Apache-2.0 | The reference OCI runtime — spawns and runs containers per the Runtime Specification, and the thing Docker and containerd ultim... |
| Skopeo | transfers |
Apache-2.0 | Inspects, copies, signs and deletes container images between registries and storage backends — without a daemon and without pul... |
| Distribution | stores |
Apache-2.0 | The reference implementation of the OCI Distribution Specification — the registry server most private registries are built from. |
| crane / go-containerregistry | transfers |
Apache-2.0 | A Go library and the `crane` CLI for working with container registries and images directly over the Distribution API — list tag... |
| Zot | stores |
Apache-2.0 | A production OCI-native registry that stores only OCI images and artifacts, with built-in vulnerability scanning and a search API. |
| ORAS | transfers |
Apache-2.0 | Pushes and pulls arbitrary artifacts through an OCI registry — Helm charts, SBOMs, signatures, models — using the registry as g... |
| umoci | transforms |
Apache-2.0 | Creates and modifies OCI images directly, without a container runtime or daemon. |
Referenced on the API Evangelist blog
Where this standard shows up across sixteen years of my writing at apievangelist.com — how it fits into API design, governance, and the agentic turn.
Relationship Between APIs And Containers
2014-08-26
