2.2.3.2 OCI Runtime Spec
A focused guide to OCI Runtime Spec, connecting core concepts with practical Docker and container operations.
The OCI Runtime Spec is the published specification defining the configuration format a container runtime consumes to actually create an isolated process — namespaces, cgroups, mounts, and the command to execute — independent of any particular runtime implementation.
What the Specification Defines
The runtime spec describes a JSON configuration file format covering everything a runtime needs to know to start a container: which namespaces to create, what the root filesystem is, what mounts should be present, what resource limits apply through cgroups, and what process to execute as the container's main process.
{
"ociVersion": "1.0.2",
"process": { "args": ["sh"] },
"root": { "path": "rootfs" },
"linux": {
"namespaces": [{ "type": "pid" }, { "type": "network" }]
}
}
Any runtime implementing the spec is expected to interpret this configuration the same way, producing equivalent isolation regardless of which specific runtime binary processes it.
runc as the Reference Implementation
runc is the reference implementation of this specification, meaning it is the canonical example of correct behavior against which other runtime implementations are typically validated.
runc spec
runc run mycontainer
Alternative Runtimes Implementing the Same Spec
Because the specification is independent of any single implementation, other runtimes — including ones that provide stronger isolation by running each container inside a lightweight virtual machine — can consume the exact same configuration format.
ctr run --runtime io.containerd.kata.v2 myimage mycontainer
Switching the runtime here changes how the container is isolated underneath, without requiring any change to the configuration format itself.
Why a Shared Runtime Format Matters
Because higher-level tools like containerd generate configuration in this standard format rather than targeting a specific runtime's proprietary interface, swapping the underlying runtime — for stronger isolation, for a different operating system, or for specialized hardware support — does not require changes anywhere above the runtime layer.
ctr plugins list | grep runtime
Why This Matters for the Container Ecosystem
The runtime spec is what allows the lowest level of the container stack to evolve and diversify — new runtime implementations with different isolation tradeoffs can be adopted incrementally, without disrupting the tools and workflows built on top of them.