runc

Definition

runc is a lightweight, low-level command-line container runtime that creates and runs containers according to the Open Container Initiative runtime specification, handling the direct work of setting up Linux namespaces, cgroups, and filesystem mounts for a container process. It is the default low-level runtime underneath Docker and containerd, invoked automatically rather than used directly by most developers, and it originated as extracted code from Docker's own container execution engine.

Overview

Container platforms like Docker needed a standard, interoperable way to actually start a container process once an image had been unpacked, so that different tools could share a common, well-defined runtime layer instead of each reimplementing low-level container creation. runc emerged from Docker's own internal container execution code, extracted and donated to become the reference implementation of the OCI runtime specification. At its core, runc takes a filesystem bundle and a configuration describing namespaces, cgroup limits, mounts, and capabilities, then makes the necessary Linux system calls to create isolated namespaces for process IDs, networking, and mounts, apply cgroup resource limits, and finally execute the container's entrypoint process inside that isolated environment. It performs this work once per container start and then exits, handing off no ongoing supervision. runc sits at the bottom of the container runtime stack: higher-level runtimes such as containerd or CRI-O manage image pulling, storage, and the container lifecycle, and call down to runc, or an OCI-compatible alternative like gVisor's runsc or Kata Containers, to actually create the isolated process. Because it implements the OCI specification, any of these low-level runtimes can be swapped in without changing the tools above them. In practice, most engineers never invoke runc directly; it runs invisibly beneath Docker, containerd, and Kubernetes' container runtime interface implementations every time a container starts. Its OCI compliance is what allows a Kubernetes cluster to select an alternative low-level runtime, such as Kata Containers for stronger isolation, without changing how pods are defined, since higher-level tools interact with any OCI runtime through the same interface regardless of which one is actually installed. runc's simplicity is also its limitation: it shares the host kernel with every container it starts, so it offers no protection against kernel-level exploits the way VM-based runtimes do, and a runc container escape historically has meant direct access to the host. It also has no built-in image management, networking configuration, or lifecycle supervision, all of which are left to the higher-level runtime calling it. Because of this exposure, several well-known container escape vulnerabilities over the years have specifically involved runc's handling of file descriptors and namespaces, prompting periodic security patches and driving interest in VM-isolated alternatives for higher-risk workloads, which is one reason platform teams running multi-tenant clusters often pair runc's speed for trusted workloads with a stronger-isolation runtime reserved for anything untrusted, treating the choice of runtime as a per-workload security decision rather than a single cluster-wide default.

Key Features

• Reference implementation of the OCI container runtime specification
• Creates Linux namespaces, cgroups, and mounts to isolate a container process
• Invoked by higher-level runtimes such as containerd and CRI-O
• Exits after starting the container rather than supervising its lifecycle
• Shares the host kernel directly with every container it creates
• Swappable with OCI-compatible alternatives like runsc or Kata's runtime
• Written in Go and maintained under the Open Container Initiative
• Forms the default execution layer beneath Docker and Kubernetes

Use Cases

Alternatives

Frequently Asked Questions

Related in DevOps