Container Internals Deep Dive 05: OCI Standard
Why OCI image and runtime specs matter for interoperability across tools and platforms.
On this page
Container Internals Deep Dive — this post is part of a series
- Part 1: Container Internals Deep Dive 00
- Part 2: Container Internals Deep Dive 01: Cgroups
- Part 3: Container Internals Deep Dive 02: Namespaces
- Part 4: Container Internals Deep Dive 03: Network Namespaces and CNI
- Part 5: Container Internals Deep Dive 04: containerd Internals
- Part 6: Container Internals Deep Dive 05: OCI Standard
- Part 7: Container Internals Deep Dive 06: runc vs crun
- Part 8: Container Internals Deep Dive 07: Rootless Containers with Podman
- Part 9: Container Internals Deep Dive 08: Kata Containers
- Part 10: Container Internals Deep Dive 09: Firecracker microVM
Series: 6/10. In part 04 we covered containerd internals. Here we cover OCI.
OCI (Open Container Initiative) gives us common specs so build tools, registries, and runtimes can interoperate.
Two specs you should know #
- OCI Image Spec: how images and layers are described.
- OCI Runtime Spec: how a filesystem bundle + config becomes a running container.
Without this standardization, each vendor stack would be incompatible.
Image spec in practice #
- Manifest points to config + layers.
- Config includes entrypoint, env, labels, and rootfs metadata.
- Layers are content-addressed and immutable.
This enables reproducibility and deduplication across hosts and registries.
Runtime spec in practice #
Runtime spec defines config.json fields for:
- process args/env/cwd
- mount points
- Linux namespaces/cgroups/capabilities
- seccomp and additional restrictions
OCI runtimes (runc, crun, others) implement this contract.
Why this matters to teams #
- You can swap runtime implementations with less friction.
- Security tooling can reason about common metadata and behavior.
- CI/CD and registry workflows remain portable across platforms.
Takeaway #
OCI is the compatibility layer that makes the container ecosystem practical at scale.