Skip to content

Adoption & Ecosystem ​

Who uses it ​

The organisations below appear in the project's ADOPTERS.md. The two with external corroboration are cited to that source as well.

OrganisationUse caseSource
Red HatOpenShift Container Platform 4 ships CRI-O as the only supported CRI implementationRed Hat blog
OracleLinux Cloud Native Environment and Kubernetes Engine, valued for running both runc and KataOracle docs
SUSEDefault runtime in CaaS Platform v4; also openSUSE KubicADOPTERS.md
LyftProduction use since 2017ADOPTERS.md
Reddit, AdobeListed production adoptersADOPTERS.md
NestyboxDistributed with SysboxADOPTERS.md
Digital Science, HERE Technologies, Particule, PITS Global Data Recovery ServicesListed adoptersADOPTERS.md

Adoption signals ​

Measured from the GitHub API on 2026-06-22 for cri-o/cri-o: 5,628 stars, 1,179 forks, 119 watchers, 133 open issues, and roughly 326 contributors enumerated through the API. The latest release at that time was v1.36.1 (2026-06-03). Releases follow the Kubernetes minor cadence, with recent lines 1.36, 1.35, and 1.34 maintained in parallel.

The strongest adoption signal is structural: OpenShift 4 runs CRI-O as its only supported CRI implementation (Red Hat blog), which puts CRI-O under every OpenShift 4 cluster.

Ecosystem ​

CRI-O is built from shared container components rather than reimplementing them. It delegates execution to runc or crun, monitoring to conmon or conmonrs, images to containers/image, and storage to containers/storage, the same stack Podman and Buildah use (README.md:113-119). Networking is any CNI plugin. VM-isolated workloads run through Kata Containers, selected per pod by runtime handler. The Node Resource Interface plugin surface lives in internal/nri/.

Alternatives ​

The dockershim path was removed from the kubelet in Kubernetes 1.24, leaving CRI-O and containerd as the practical choices for a CRI runtime. CRI-O is the right pick when you run Kubernetes and want a runtime scoped to exactly that, tracking your Kubernetes minor version. containerd fits when you also need a general-purpose runtime usable outside Kubernetes and a richer plugin and snapshotter model.

AlternativeDiffers by
containerdCNCF Graduated, general-purpose; serves both Docker and Kubernetes with a plugin and snapshotter design, where CRI-O is Kubernetes-only and version-locked to it
runcAn OCI runtime, not a CRI runtime; it is what CRI-O drives through conmon rather than a substitute for CRI-O