rkt

What it is

rkt (pronounced "rock-it") was a container runtime originally built by CoreOS as an alternative to Docker's daemon-based architecture. It ran containers without a long-lived background daemon, used a pod-native execution model (multiple app containers grouped as one unit, conceptually similar to what Kubernetes pods later formalized), and supported the App Container (appc) spec before the industry converged on OCI. It could also execute OCI and Docker-format images. Development stopped in 2020, and the CNCF archived the project. Do not deploy this in a new cluster.

Who builds it and why

CoreOS built rkt as part of its broader bet on a more secure, Unix-philosophy-aligned container stack (alongside CoreOS Container Linux and etcd). The pitch was daemonless execution, stronger process isolation, and no single point of failure or attack surface the way dockerd running as root represented at the time. Red Hat acquired CoreOS in 2018, and rkt's relevance collapsed once Kubernetes standardized on CRI and the ecosystem consolidated around containerd and CRI-O. Red Hat did not carry the project forward. Last commit: February 2020. It is dead upstream — 252 contributors got it to v1.30.0 and then walked away.

Production readiness signal

None. This is a historical artifact, not a supported runtime.

• CNCF status: archived — CNCF's explicit signal that a project is no longer maintained and shouldn't be adopted.
• Last commit over 4 years ago (Feb 2020), no security patches since.
• No CRI (Container Runtime Interface) support was ever fully stabilized for modern Kubernetes — Kubernetes deprecated and removed rktnetes-era integration years ago.
• 8,775 GitHub stars reflects historical interest circa 2015–2017, not current adoption.
• Apache-2.0 licensed, Go, but that doesn't matter if nobody's fixing CVEs.

If you're running rkt in production today, you have an unpatched, unsupported runtime underneath your workloads. That's a liability, not a technology choice.

Who should use this

Nobody, for new deployments. The only legitimate reasons to touch rkt in 2024+:

• You're doing container runtime history/research (studying pre-OCI runtime design, appc spec).
• You've inherited a legacy CoreOS Container Linux + rktnetes environment and are actively migrating off it — in which case you're using rkt only long enough to get out.
• Academic or archival interest in daemonless runtime architecture patterns.

Who should NOT use this

• Anyone building a new cluster or choosing a runtime today — full stop.
• Teams needing CVE patching, CRI compliance, or vendor support — none of that exists here.
• Anyone currently on rktnetes — you're on borrowed time; plan the migration now, not later.
• Compliance-driven environments (SOC2, FedRAMP, PCI) — an archived, unpatched runtime will fail any competent audit.
• Anyone who found this because a tutorial or blog post from 2016 recommended it — that content is stale; the ecosystem moved on.

Alternatives

• containerd — the CNCF-graduated, CRI-native runtime that most Kubernetes distributions use by default today; actively maintained, backed by a broad multi-vendor community.
• CRI-O — a lightweight, Kubernetes-specific runtime built explicitly to implement CRI with OCI images; the default in OpenShift and a solid choice if you want minimal surface area.
• Docker Engine / Moby — still viable outside Kubernetes contexts or where dockerd-based workflows and tooling are already entrenched, though most K8s installs no longer use it as the node runtime.

Pricing

Fully open source, Apache-2.0 licensed. No commercial tier ever existed, and none will now — there's no vendor behind it to sell one.