Docker Architecture Explained: Client, Daemon, Images, Containers, and Registries

Typing docker run nginx feels like a single action, but behind it several separate programs cooperate: a client that sends a request, a daemon that coordinates the work, a runtime stack that creates the container, a registry that supplies the image, and the Linux kernel that enforces isolation. Most Docker problems, from "Cannot connect to the Docker daemon" to slow pulls and missing images, become easy to diagnose once you know which of these parts is involved.

This guide explains Docker architecture from end to end. You will learn what each component does, how they communicate, what really happens step by step when you run a container, and how the architecture changes on Docker Desktop and in Kubernetes. Everything reflects Docker Engine 29, as of October 2026.

Quick Answer

Docker uses a client-server architecture with five main building blocks:

Component	What it is	One-line role
Docker client	The docker CLI (plus Compose, Buildx and SDKs)	Sends your commands to the daemon through the Docker Engine API
Docker daemon	dockerd, a background service on the Docker host	Manages images, containers, networks, volumes and builds
Docker images	Read-only, layered templates	Package an application and everything it needs to run
Docker containers	Running (or stopped) instances of images	Isolated processes created from an image plus a writable layer
Docker registries	Image storage services such as Docker Hub or Amazon ECR	Store and distribute images through pull and push

Under the daemon, containerd manages container lifecycles and image content, and runc creates each container using Linux kernel features: namespaces for isolation and cgroups for resource limits.

The Big Picture: How Docker Components Fit Together

Figure 1: Docker architecture: client, Docker host and registry

The diagram shows three zones:

The client is where you type commands. It can be on the same machine as the daemon or on a different one.
The Docker host is the machine that actually runs containers. It contains the daemon, the runtime stack (containerd, shims and runc), local images, and the containers themselves, all sitting on the Linux kernel.
The registry is a remote service that stores images. The daemon, not the client, pulls images from it and pushes images to it.

The separation matters. Because the client and daemon communicate through an API, one client can control many hosts, and many tools (Compose, IDEs, CI systems) can control the same daemon.

1. The Docker Client

The Docker client is the program you interact with, most commonly the docker command-line interface. The client does not create containers, download images or configure networks itself. It turns each command into an HTTP request to the Docker Engine API, sends it to a daemon, and displays the response.

Ways the Client Talks to the Daemon

Transport	Address example	Typical use
Unix socket	unix:///var/run/docker.sock	Default on Linux: client and daemon on the same machine
Named pipe	npipe:////./pipe/docker_engine	Windows hosts
SSH	ssh://deploy@server.example.com	Managing a remote host securely without opening extra ports
TCP with TLS	tcp://server.example.com:2376	Remote access where SSH is unavailable; requires mutual TLS

You choose which daemon the client talks to with Docker contexts, or with the DOCKER_HOST environment variable. See our tutorial Docker Contexts: Manage Remote Docker Hosts for the full setup.

Client Plugins

Several familiar commands are CLI plugins that extend the client while still talking to the same daemon:

docker compose — defines and runs multi-container applications from a compose.yaml file.
docker buildx — the full interface to BuildKit, including multi-platform builds.
docker scout — image vulnerability analysis (bundled with Docker Desktop).

API Version Negotiation

The client and daemon each support a range of API versions and automatically agree on one they both understand. Run docker version to see both sides. Docker Engine 29 raised the minimum supported API version to 1.44, so very old clients can no longer talk to a current daemon; upgrading the client fixes the resulting "client version is too old" error.

docker version --format "Client API: {{.Client.APIVersion}} Server API: {{.Server.APIVersion}}"

2. The Docker Daemon (dockerd)

The Docker daemon, dockerd, is a long-running background service on the Docker host. It listens for API requests and is the central coordinator of everything Docker does on that machine.

What the Daemon Is Responsible For

Responsibility	Examples
Image management	Pulling, storing, tagging, removing and pushing images
Builds	Running image builds with the built-in BuildKit builder
Container orchestration on one host	Creating, starting, stopping and removing containers through containerd
Networking	Creating bridge and other networks, assigning IP addresses, embedded DNS, port publishing and firewall rules
Storage	Creating volumes and preparing each container's filesystem
Logging and events	Collecting container output through logging drivers and emitting events
Security settings	Applying seccomp profiles, capabilities, user namespaces and AppArmor or SELinux labels

Daemon Configuration and Files

Item	Default location on Linux
Configuration file	/etc/docker/daemon.json
API socket	/var/run/docker.sock
Data directory (classic store, volumes, metadata)	/var/lib/docker
Image content and snapshots (containerd image store)	/var/lib/containerd
systemd service	docker.service

Security: The daemon traditionally runs as root, so anyone who can reach its API socket, including members of the docker group, effectively has root access to the host. Rootless mode runs the daemon as an ordinary user instead; see our tutorial Rootless Docker: Setup and Limitations.

For a deeper look at the daemon on its own, see our tutorial Docker Daemon Explained.

Under the Hood: containerd, Shims and runc

dockerd does not create container processes itself. Since Docker 1.11, the runtime work has been split into smaller, specialised components. This design is why the same building blocks also power Kubernetes.

Layer	Component	What it does
High-level runtime	containerd	Manages container lifecycles, image content and filesystem snapshots. A graduated CNCF project used by Docker and by most Kubernetes clusters.
Shim	containerd-shim-runc-v2	One small process per container. It keeps the container's standard input and output open and reports its exit status, so containers keep running even if dockerd or containerd restarts.
Low-level runtime	runc	Creates the container: sets up namespaces, cgroups, mounts and security settings, starts the container's first process, then exits.
Kernel	Linux kernel	Actually enforces isolation (namespaces) and resource limits (cgroups) and provides the layered filesystem.

Two industry standards from the Open Container Initiative (OCI) connect these layers: the image specification, which defines how images are packaged, and the runtime specification, which defines how a runtime such as runc creates a container from a filesystem bundle and a configuration file. Because Docker follows these standards, an image built with Docker runs on Podman, containerd and Kubernetes, and the reverse.

Why This Layering Matters in Practice

Daemon upgrades without downtime. With "live-restore": true in daemon.json, you can restart or upgrade dockerd while containers keep running, because the shims keep them alive.
Clearer troubleshooting. A container that fails to start with an "OCI runtime create failed" error points to runc and the kernel, not to the network or the registry.
Kubernetes compatibility. Kubernetes talks to containerd directly and does not use dockerd at all, yet runs the same images.

You can see the stack on any Linux host running containers:

systemctl status docker containerd --no-pager

ps -eo pid,ppid,cmd | grep -E "dockerd|containerd" | grep -v grep

The output shows dockerd, containerd, and one containerd-shim-runc-v2 process for each running container. You will not see runc itself, because it exits as soon as each container has started.

3. Docker Images

A Docker image is a read-only template containing everything an application needs to run: a minimal operating system filesystem, runtime, libraries, application code and default settings such as the command to start and the user to run as.

Images Are Made of Layers

An image is a stack of read-only layers. Each filesystem-changing instruction in a Dockerfile, such as RUN, COPY or ADD, produces a new layer containing only the files that changed. Layers are identified by a hash of their content, which gives three big benefits:

Sharing: if ten images use the same base image, its layers are stored on disk only once.
Faster pulls and pushes: only layers the destination does not already have are transferred.
Build caching: unchanged instructions reuse existing layers instead of running again.

docker image history nginx:1.29

What an Image Consists Of

Part	Contents
Layers	Compressed archives of filesystem changes
Image configuration	Metadata: entrypoint, command, environment variables, exposed ports, working directory, user, labels and the ordered list of layers
Manifest	A document listing the configuration and layers for one platform, each referenced by digest
Index (manifest list)	For multi-platform images, a list of manifests, one per platform such as linux/amd64 and linux/arm64

When you pull a multi-platform image, Docker reads the index and downloads only the manifest and layers for your machine's platform. That is why the same docker pull nginx works on an Intel server and on an Apple silicon Mac.

Tags and Digests

Every image is identified in two ways:

A tag, such as nginx:1.29, is a human-friendly, mutable label. The publisher can move it to a newer image at any time.
A digest, such as nginx@sha256:..., is a hash of the image manifest. It is immutable: the same digest always refers to exactly the same image.

Use tags while developing and digests when you need guaranteed reproducibility, for example in production deployments.

Docker Engine 29: Fresh installations of Docker Engine 29 store images in the containerd image store by default, instead of Docker's older graph-driver store. Image content and snapshots therefore live under /var/lib/containerd, and multi-platform images and attestations are kept intact locally. Hosts upgraded from older versions keep their existing store until migrated. Run docker info and look at the storage driver line to see which store a host uses.

4. Docker Containers

A container is a runnable instance of an image. Docker creates it by adding a thin writable layer on top of the image's read-only layers and starting a process with its own isolated view of the system.

Image vs Container

	Image	Container
Nature	Read-only template	Running or stopped instance with a writable layer
Analogy	A class, or an installation disc	An object created from the class, or the installed and running program
Changes	Never change after they are built	Can write files, but changes disappear when the container is removed
Count	One image	Any number of containers from the same image
Command	docker build, docker pull	docker run, docker start

How Containers Are Isolated

A container is not a virtual machine. It is an ordinary Linux process that the kernel isolates using two features:

Kernel feature	What it provides
Namespaces	Separate views of process IDs (pid), network (net), mounts (mnt), hostname (uts), inter-process communication (ipc), users (user) and cgroups (cgroup)
Control groups (cgroups)	Limits and accounting for CPU, memory, process count and I/O
Union filesystem (overlay)	Combines the read-only image layers and the writable container layer into one filesystem view
Security features	Capabilities, seccomp syscall filtering, and AppArmor or SELinux profiles reduce what the process may do

Because containers share the host's kernel, they start in milliseconds and use far less memory than virtual machines. It also means a Linux container needs a Linux kernel, which is why Docker Desktop runs a small Linux virtual machine on macOS and Windows. Our tutorial Container Isolation and Linux Namespaces explores this in depth.

Containers Are Disposable; Data Is Not

The writable layer is deleted when the container is removed. Anything that must survive, such as database files or uploads, belongs in a volume or a bind mount, which live outside the container's lifecycle.

5. Docker Registries

A registry is a service that stores and distributes images. Within a registry, images are organised into repositories (for example library/nginx), and each repository holds many tagged versions.

Registry type	Examples
Public default	Docker Hub (docker.io), home of Docker Official Images and Docker Hardened Images
Cloud provider registries	Amazon ECR, GitHub Container Registry (ghcr.io), Azure Container Registry, Google Artifact Registry
Self-hosted	Harbor, the open-source CNCF Distribution registry

How Docker Resolves an Image Name

A full image reference has up to five parts. Docker fills in defaults for any part you leave out:

registry/namespace/repository:tag@digest

nginx

= docker.io/library/nginx:latest

bitcodematrix/api:1.4

= docker.io/bitcodematrix/api:1.4

123456789012.dkr.ecr.ap-south-1.amazonaws.com/api:1.4

= an image in a private Amazon ECR repository

Part	Default if omitted	Example
Registry	docker.io (Docker Hub)	ghcr.io
Namespace	library (Docker Official Images)	bitcodematrix
Repository	Required	api
Tag	latest	1.4
Digest	None	sha256:4f2a...

Best practice: Never rely on the implicit latest tag in production. It changes whenever the publisher releases a new version, so two servers can run different code from the same reference. Use a specific version tag or a digest.

Pulling and Pushing

The daemon talks to registries using the OCI Distribution protocol over HTTPS. For a pull, it fetches the manifest (choosing your platform from the index), then downloads only the layers it does not already have. For a push, it uploads only the layers the registry does not already have, then the manifest. Credentials from docker login are stored by the client and passed to the daemon with each request.

Supporting Objects: Networks and Volumes

Images, containers and registries are the core of the architecture, but the daemon also manages two other kinds of objects that containers depend on:

Object	Purpose	Learn more
Networks	Connect containers to each other and to the outside world: bridge (default), host, none, macvlan, ipvlan and overlay drivers, with built-in DNS on user-defined networks	Docker Networking Fundamentals
Volumes	Persistent storage managed by Docker that survives container removal	Docker Volumes and Persistent Storage

What Happens When You Run docker run nginx

Here is the complete journey through the architecture, from pressing Enter to a running web server:

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

Step	Component	What happens
1	Client	The CLI parses the command and checks which daemon to use (current context or DOCKER_HOST).
2	Client → daemon	The CLI sends a request to create a container through the Docker Engine API over the Unix socket.
3	Daemon	dockerd checks whether nginx:1.29 exists locally. If not, it returns "image not found" and the CLI asks the daemon to pull it.
4	Daemon → registry	The daemon resolves the name to docker.io/library/nginx:1.29, fetches the index and the manifest for your platform, and downloads only the missing layers.
5	Daemon	The daemon creates the container configuration: name, port mapping, network, environment and security settings.
6	Daemon + containerd	A filesystem snapshot is prepared: read-only image layers plus a new writable layer.
7	Daemon	Networking is set up: a virtual Ethernet pair connects the container to the bridge network, an IP address is assigned, and firewall rules publish port 8080.
8	containerd → shim → runc	containerd starts a shim, which calls runc. runc creates the namespaces and cgroups, applies security settings and starts the Nginx process as PID 1, then exits.
9	Shim	The shim stays alive as the container's parent, holding its output streams and waiting for its exit status.
10	Daemon → client	The daemon confirms the start, and the CLI prints the container ID. Nginx now serves requests on port 8080.

Every later command, such as docker logs web, docker stop web or docker rm web, follows the same path: client to API to daemon to containerd and the shim.

What Happens When You Build and Push an Image

docker build -t bitcodematrix/api:1.4 . packages the build context (your project directory, minus anything in .dockerignore) and sends it to the daemon.
BuildKit, the builder inside the daemon, reads the Dockerfile, pulls the base image if needed, runs each instruction (reusing cached layers where possible) and produces a new image with its layers, configuration and manifest.
docker push bitcodematrix/api:1.4 makes the daemon authenticate to the registry, upload any layers the registry does not already have, and then upload the manifest.
Any other Docker host, CI runner or Kubernetes cluster can now pull the exact same image.

Docker Desktop Architecture: What Is Different?

On macOS and Windows, the kernel is not Linux, so Linux containers cannot run directly on the host. Docker Desktop adds a lightweight Linux virtual machine:

The client (docker CLI) runs natively on macOS or Windows.
The daemon, containerd, runc and containers run inside the Linux VM (using WSL 2 on Windows, or Apple's virtualization framework on macOS).
Docker Desktop forwards the API socket, published ports and file-sharing between your host and the VM, so it feels as if containers run locally.

This is why file-sharing performance and memory settings matter on Docker Desktop: containers can only use the resources allocated to the VM.

Docker Architecture vs Kubernetes

Docker and Kubernetes share the same lower layers but differ at the top:

Layer	Docker Engine	Kubernetes node
Who receives requests	dockerd, through the Docker Engine API	kubelet, from the Kubernetes API server
High-level runtime	containerd	containerd (or CRI-O), through the Container Runtime Interface
Low-level runtime	runc	runc (or another OCI runtime)
Unit of deployment	Container	Pod (one or more containers)
Scope	One host	A cluster of many nodes

Kubernetes removed its built-in Docker integration ("dockershim") in version 1.24 and talks to containerd directly. This changed nothing for images: an image built with Docker runs unchanged on Kubernetes because both follow the OCI standards.

Explore the Architecture on Your Own Machine

These commands let you see each component for yourself:

Command	What it shows
docker version	Client and server versions, API versions, and the containerd and runc versions in use
docker info	Daemon configuration: storage driver or image store, cgroup version, runtimes, security options and registry settings
docker context ls	Which daemon your client is pointing at
docker image inspect nginx:1.29	Image configuration and layer list
docker buildx imagetools inspect nginx:1.29	The image index and all platforms published in the registry
docker inspect web	A container's full configuration, state, mounts and network settings
docker system events	Live stream of what the daemon is doing

Common Misconceptions About Docker Architecture

Misconception	Reality
"The docker command runs my containers."	The CLI only sends API requests. The daemon and the runtime stack run containers.
"A container is a lightweight virtual machine."	A container is an isolated process sharing the host kernel. There is no guest operating system kernel.
"The image contains a whole operating system."	It contains a filesystem with libraries and tools from a distribution, but not a kernel.
"Restarting dockerd always kills my containers."	With live-restore enabled, containers keep running during a daemon restart, thanks to the shims.
"Kubernetes stopped supporting Docker images."	Kubernetes stopped using dockerd as its runtime. Docker-built images are OCI images and run normally.
"latest means the newest version."	latest is just a default tag name; it points wherever the publisher last put it.

Frequently Asked Questions

What are the main components of Docker architecture?

The Docker client, the Docker daemon (dockerd), images, containers and registries. Underneath the daemon, containerd and runc create and run containers using Linux kernel namespaces and cgroups.

What is the difference between dockerd, containerd and runc?

dockerd is Docker's API server and coordinator, handling images, builds, networks and volumes. containerd manages container lifecycles and image content. runc is a small tool that actually creates each container according to the OCI runtime specification and then exits.

Can the Docker client and daemon run on different machines?

Yes. The client communicates with the daemon through an API, so it can manage a remote daemon over SSH or TLS. Docker contexts make switching between local and remote daemons easy.

Where are Docker images stored on Linux?

On fresh Docker Engine 29 installations, image content and snapshots are stored by containerd under /var/lib/containerd. Hosts still using the classic store keep image layers under /var/lib/docker. Volumes are stored under /var/lib/docker/volumes in both cases.

Is Docker Hub the only registry?

No. Docker Hub is the default registry, but Docker works with any OCI-compatible registry, including Amazon ECR, GitHub Container Registry, Azure Container Registry, Google Artifact Registry and self-hosted Harbor.

Why do I need Docker Desktop on Mac and Windows?

Linux containers need a Linux kernel. Docker Desktop provides one in a lightweight virtual machine and connects it seamlessly to the Docker client on your host.

Conclusion and Next Steps

Docker architecture is a clean chain of responsibilities. The client sends requests; the daemon coordinates images, networks, volumes and builds; containerd, shims and runc create and supervise containers; the kernel enforces isolation; and registries distribute images between machines. Knowing which link in the chain is involved turns vague Docker errors into specific, solvable problems.

Continue the Docker course with these tutorials on BitCodeMatrix:

What Is Docker? — the problems containers solve and why Docker became the standard
Docker Daemon Explained — a closer look at dockerd and its configuration
Container Isolation and Linux Namespaces — the kernel features behind every container
How to Install Docker on Ubuntu, Windows (WSL2) and macOS (Module 2) — put the architecture to work on your own machine