containerd belongs under a platform, not in a developer's hand
containerd manages image transfer and storage, container execution, process supervision, storage snapshots, and network attachments. That sounds like a complete container product until the README states the intended boundary: larger systems embed it, while developers and end users normally interact with something above it. Kubernetes reaches it through the built-in Container Runtime Interface plugin. Other products can use its APIs and plugin model.
That boundary is the main buying advice. If you are building a cluster service, appliance, edge platform, or another container control plane, containerd supplies the difficult host-level machinery without imposing Docker's whole product experience. If a developer merely wants to build an image and run a command, containerd exposes too much plumbing and too little guidance for daily use.
What happened when we ran it
Our sandbox cloned commit 301026e with 3 CPUs and 8 GB of RAM. The 11.8 MB checkout contained 1,625 files and about 274,558 lines of source. Its install step succeeded in 36 seconds and added 0 packages, which is consistent with a Go module workflow rather than an operating-system installation. The build then completed successfully in 76 seconds.
Tests ran for 100 seconds and returned exit code 1. Our summary recorded 101 passed packages and 2 failed out of 103. The supplied tail shows successful and no-test results across several snapshotter and plugin packages, followed only by the overall FAIL. It does not identify the two failures. We can report the incomplete pass, but assigning it to privileges, kernel behavior, or missing host tools would go beyond the log.
The repository has 17 CI workflow files and a dedicated tests directory. It does not have a Dockerfile. That is sensible for software whose behavior depends on real kernel, filesystem, namespace, and runtime facilities. A green compile inside a generic build container says less than targeted checks on the distributions and storage drivers that production nodes will use.
A containerd host still needs runc, CNI, and kernel choices
Official release archives do not finish the machine. The v2.3.4 notes say operators usually need to install runc and CNI plugins separately. The README points to the required runc version, registry host configuration, namespace behavior, and client options. Checkpoint and restore needs CRIU. Each item has its own compatibility and update cycle, which belongs in the node image or provisioning system.
Storage also binds the runtime to the host. The default overlay snapshotter uses features finalized in Linux 4.x. The README gives 4.x as a reasonable starting point, with the caveat that distribution kernels backport features. Btrfs can work from a recommended 3.18 kernel but needs the kernel module and user-space tools. These are operational requirements, not details a Go binary can hide.
Windows is supported too, through OS-specific libraries such as hcsshim. Cross-platform support should not be mistaken for identical behavior. Node builders need separate validation for Windows isolation, Linux namespaces, selected snapshotters, and the network stack. containerd creates one runtime contract over those systems; it does not make their host rules interchangeable.
CRI is built in, while ctr is the wrong product surface
The CRI plugin has shipped in release binaries and been enabled by default since containerd 1.1. The README describes it as generally available and links Kubernetes validation, node end-to-end tests, configuration, and crictl debugging guidance. For a Kubernetes operator, that is the supported route: kubelet calls CRI, and crictl helps inspect what the runtime sees.
The included ctr client is useful for low-level inspection and exercising APIs. It is easy to mistake its presence for a Docker replacement because it can pull images and start containers. That skips the layers that manage networking, user intent, and long-lived application state. Human-facing workflows belong in Kubernetes tools, nerdctl, or another engine that deliberately owns them.
Release v2.3.4 changes restore behavior by default
GitHub shows a last push on August 26, 2026, 21,184 stars, and 454 combined open issues and pull requests. Release v2.3.4 arrived in August 2026 with runtime, snapshotter, Windows logging, CRI, and NRI fixes. Recent code movement plus a current issue and pull request queue indicates active maintenance; the combined 454 count must not be read as 454 confirmed bugs.
One patch detail warrants an upgrade check. v2.3.4 disables checkpoint restore through CreateContainer by default and requires an experimental configuration option to re-enable it. The release also deprecates that path and adds CRIU availability checks. Operators using restore workflows need to read the release notes and configuration rather than rolling this patch as if every default remained fixed.
The release assets span several operating systems and architectures, with dynamic and static Linux archives. The recommended dynamic archive expects glibc 2.35, while the static archive targets systems without that level and is not position-independent. Distribution packages may be the cleaner choice when they integrate service files, dependencies, and security updates with the host.
Choose containerd when another system owns the experience
containerd has earned its place beneath Kubernetes and other container platforms because its scope is disciplined. OCI registries, runtime supervision, snapshots, CRI, and a plugin architecture are enough for a control plane without forcing one developer workflow. Apache 2.0 licensing and CNCF governance also make it a practical infrastructure dependency.
That same discipline makes it a poor direct tool for many teams. You must bring runc, networking plugins, suitable kernels, storage decisions, host configuration, upgrades, and observability. Our 76-second build proves the checked-out source compiled; the 2 failures among 103 tested packages say the environment still deserves investigation. Platform engineers should shortlist it. Individual developers should start one layer higher.