cri-o (Wasm)

What it is

CRI-O is a Kubernetes-native container runtime that implements the Container Runtime Interface (CRI), letting Kubernetes talk directly to OCI-compliant runtimes without a general-purpose container engine like Docker sitting in between. In the Wasm category, CRI-O's relevance comes from its pluggable runtime handler model — it can shell out to a WebAssembly runtime (via crun-wasm, wasmedge, wasmtime, or similar OCI-wasm-compatible shims) as a runtime class, letting you schedule Wasm/WASI workloads alongside regular OCI containers on the same cluster without a separate control plane. It's not a Wasm runtime itself — it's the CRI shim that routes pods to one.

Who builds it and why

CRI-O is maintained by a large, distributed set of contributors (369 on GitHub) primarily from Red Hat, SUSE, and the broader Kubernetes/CRI-O SIG community, with Red Hat historically the primary corporate driver (it's the default runtime in OpenShift). The motivation is straightforward: strip out everything Kubernetes doesn't need from a container runtime — no image building, no swarm mode, no unnecessary API surface — and track the Kubernetes release cadence tightly. The Wasm integration work is a smaller, more experimental slice of the project driven by contributors interested in running Wasm as a first-class Kubernetes workload type rather than bolting it on via sidecars or separate schedulers.

Production readiness signal

The core CRI-O project is mature and battle-tested — it's been running production OpenShift clusters for years. Signals here: active commit history (last commit 2026-07-01), 5,636 GitHub stars, 369 contributors, and a recent stable release (v1.36.1) tracking Kubernetes' own versioning scheme. CNCF maturity level is not publicly available in this profile's data, so don't cite a graduation tier without checking cncf.io directly. The Wasm-specific runtime handler support is newer and less battle-tested than the core CRI runtime path — treat it as beta-grade unless you've validated it against your specific Wasm workload and shim combination.

Who should use this

Teams already running CRI-O (especially OpenShift or OKD shops) who want to add Wasm workloads without introducing a second orchestration layer. Platform teams experimenting with Wasm for edge, serverless-style, or sandboxed multi-tenant workloads who want to reuse existing Kubernetes RBAC, scheduling, and observability tooling instead of standing up a Wasm-specific PaaS. Anyone who needs a CRI implementation with a smaller attack surface than a full Docker Engine install, independent of the Wasm angle.

Who should NOT use this

If you're not already on CRI-O, don't adopt it just for Wasm support — containerd's runwasi shim has broader community momentum and better documentation for the Wasm use case specifically. If your Wasm workloads are truly ephemeral, function-style, and don't need Kubernetes' pod/deployment model at all, a dedicated Wasm PaaS (Fermyon Spin, wasmCloud) will get you there faster with less YAML. If you need GPU-heavy or stateful workloads as your primary use case, this is irrelevant — CRI-O plus Wasm doesn't change your GPU scheduling story. And if you can't tolerate operating a less-traveled runtime class in production, wait for the Wasm shim integration to mature further before betting a critical path on it.

Alternatives

• containerd + runwasi: the more common path to Wasm-on-Kubernetes today, with broader shim support (wasmtime, wasmedge, spin) and more production references.
• Docker Desktop + Wasm (containerd shim): useful for local dev/prototyping Wasm workloads, not a production Kubernetes runtime story.
• wasmCloud / Fermyon Spin: purpose-built Wasm application platforms that skip the CRI/Kubernetes runtime layer entirely if you don't need standard pod semantics.

Pricing

Fully open source, Apache-2.0 licensed. No paid tier, no vendor lock-in on the project itself. Cost is operational — running and upgrading your own runtime infrastructure — not licensing.