1.1.1.3 Engine Runtime Role

The engine's role within Docker is to be the runtime layer that actually creates, starts, stops, and supervises containers on a host machine. While the image format defines what gets packaged and the Dockerfile defines how it is built, it is the Docker Engine that takes a built image and turns it into a live, running process, enforcing the isolation and resource boundaries that make containers safe to run alongside one another.

Components of the Engine

The Docker Engine is not a single monolithic program but a small stack of cooperating components, each with a distinct runtime responsibility:

The Docker daemon (dockerd) is the long-running background service that exposes the engine's functionality over a REST API. It receives requests — to build an image, start a container, attach a volume — and coordinates the lower-level work needed to satisfy them.

containerd sits beneath the daemon and manages the full lifecycle of containers on the host: pulling images, managing storage and network namespaces, and supervising running container processes. It is itself a high-level container runtime, independent of Docker, that Docker delegates to.

runc sits at the lowest layer and is the component that actually creates a container according to the Open Container Initiative (OCI) runtime specification, invoking the Linux kernel calls that set up namespaces and cgroups for a single container process.

The Engine in a Command

When a command such as the following is run, it is the engine, end to end, that carries it out:

docker run -d --name web -p 8080:80 nginx:latest

The docker client sends this request to dockerd, which checks whether the nginx:latest image is present locally, pulling it from a registry if not, and then asks containerd to create and start a new container from that image. containerd in turn calls runc, which performs the actual kernel-level work of setting up the container's isolated environment and starting its main process. The container's status can then be confirmed through the same engine:

docker ps
docker logs web

Supervising the Container Lifecycle

Beyond simply starting containers, the engine continuously tracks their state. It is responsible for restarting containers according to a configured restart policy, reporting their exit codes when they stop, cleaning up their network and storage resources when they are removed, and streaming their logs and resource statistics on demand:

docker stats web
docker restart web

Why the Runtime Layer Is Separate from the Image Format

Separating the runtime engine from the image format is what allows Docker images to remain portable across different underlying runtimes. Because the engine implements the OCI runtime specification rather than a Docker-specific one, images built with Docker can, in principle, be executed by other OCI-compliant engines, and Docker's own engine can run images that were built by other compliant tools. This separation of "what to run" (the image) from "how to run it" (the engine) is what allows the broader container ecosystem — including orchestrators like Kubernetes, which delegate to a node-level container runtime in much the same way the Docker Engine delegates to containerd and runc — to interoperate around a shared standard.

Summary

The engine's runtime role is to be the active component that converts a passive image into an isolated, resource-bounded, running container, supervises it for as long as it exists, and exposes that entire lifecycle through a consistent API and command-line interface.