Skip to content

Adoption & Ecosystem

Who uses it

Every adopter below is named in the project's ADOPTERS.md at the pinned commit.

OrganisationUse caseSource
Docker / MobyEngine's underlying runtime, then and nowADOPTERS.md
Google Kubernetes EngineAvailable from 1.14, default from 1.19; Autopilot containerd-only since launchADOPTERS.md
Amazon EKS / Fargate / BottlerocketEKS CRI from 1.21 (default 1.22); Fargate with Firecracker; Bottlerocket core runtimeADOPTERS.md
Azure Kubernetes ServiceLinux nodes 1.19+, Windows 1.20+ADOPTERS.md
IBM Cloud Kubernetes ServiceCRI runtime from 1.11+ADOPTERS.md
k3s (Rancher / SUSE)Embedded runtime in lightweight KubernetesADOPTERS.md
Talos Linux, Deckhouse, VMware TKG/TCEDefault CRI runtimeADOPTERS.md
Kata Containers, firecracker-containerdCustom v2 shims driving VM-based containersADOPTERS.md
OpenFaaS faasd, Balena, LinuxKit, BuildKit, Cloud Foundry GuardianExecution backendADOPTERS.md

Adoption signals

  • GitHub: 20,870 stars and 3,979 forks (GitHub API, observed 2026-06-22).
  • CNCF LFX Insights, via the CNCF project page: 6,382 total contributors (up about 10% year over year), 1,667 contributing organisations, first commit 2015-07-17, health score "Excellent (83)".
  • containerd is the default CRI runtime across the three major managed Kubernetes services, which is the strongest practical adoption signal: most Kubernetes clusters run on it.

Ecosystem

  • nerdctl: a Docker-compatible CLI for containerd (around 10k stars).
  • BuildKit: image building, run on containerd.
  • stargz-snapshotter and SOCI: lazy image pull through snapshotter plugins.
  • runwasi: runs Wasm workloads through a shim (Rust).
  • CNI plugins for networking, and snapshotters for overlayfs, devmapper, zfs, and btrfs.

Alternatives

containerd is a general-purpose runtime with a stable API, where CRI is one plugin among many. The honest comparisons:

AlternativeDiffers by
CRI-OKubernetes-only by design; smaller surface, no general runtime API
Docker / MobySits above containerd rather than competing; uses it internally
PodmanDaemonless, rootless-first; uses conmon + crun, not containerd
runc / crun / youkiOCI runtimes that run under containerd, not replacements for it
gVisor / Kata / FirecrackerStronger isolation runtimes that plug in as containerd shims

Pick containerd when you want the runtime Kubernetes defaults to or a programmable runtime API. Pick CRI-O when you want a minimal Kubernetes-only runtime. Pick Podman when you want a daemonless single-host workflow.