Scope and principles

containerd carries an explicit scope document in SCOPE.md. This page summarizes it and points at the code that enforces each principle.

What's in scope

Feature	Status	Why
Container execution (create/start/stop/pause/resume/exec/signal/delete)	In	Core daemon responsibility; implemented by runtime v2 + the runc-v2 shim
Copy-on-write filesystems	In	The snapshotter abstraction (core/snapshots) is built around this
Image distribution (pull/push, manifest/layer ops)	In	Implemented by core/remotes, core/transfer, and the unpack pipeline
Container metrics (cgroup stats, OOM events)	In	core/metrics, plugins/server/metrics, OOM monitor in core/runtime/monitor.go

What's deliberately out of scope

Feature	Status	Why (from SCOPE.md)
Networking	Out	"Networking will be handled and provided to containerd via higher level systems." Wires only into CRI via CNI
Build (image building)	Out	"Build is a higher level tooling feature and can be implemented in many different ways on top of containerd"
Volumes	Out	"The API supports mounts, binds, etc where all volumes type systems can be built on top of containerd."
Logging persistence	Out	"Logging can be built on top of containerd because the container's STDIO will be provided to the clients"

The omission of these features is what makes containerd an embeddable runtime rather than a complete container platform. Docker, nerdctl, and Kubernetes layer their own networking, volumes, and logging on top.

Design principles (from SCOPE.md)

1. Components don't depend on each other. The execution layer and the snapshotter share a Mount struct but otherwise can be used independently. This is enforced socially (in code review) and structurally (separate packages, separate plugin types).
2. Expose primitives, not high-level abstractions. containerd exposes "snapshot", "diff", "mount" and lets the user build "build" on top — instead of having a Build API.
3. Pluggable defaults. Each component has a default implementation chosen by the maintainers. Alternatives can plug in via the plugin/proxy plugin model. New built-ins are not generally accepted; they belong in separate repositories.
4. Single host. containerd makes assumptions based on running on one machine. There is no cluster awareness, no leader election, no distributed coordination. That layer is someone else's problem.
5. ctr is for development. The bundled CLI exists for debugging, not as a stable user interface.

How scope changes

SCOPE.md ends with: "For the scope of this project to change it requires a 100% vote from all maintainers of the project." That bar is rarely cleared.

Effect on the codebase

• The CRI plugin lives in internal/cri/ because Kubernetes integration is still inside the project's scope but is implemented as a contained, optional plugin.
• Networking only appears via CNI invocations from the CRI plugin — there is no core/network/ package.
• pkg/oci/ lets users build runtime specs themselves; containerd doesn't ship a "compose" or "stack" abstraction.