Docker's architecture — daemon, client, and registries

Docker is not one program

When you type docker run nginx, it feels like a single tool is doing everything. Under the hood, at least three separate pieces are involved, and understanding the split makes later topics (like remote Docker hosts, or why sudo matters) much clearer.

The three pieces

1. The Docker client (docker CLI) — this is what you actually type commands into. It doesn't do any of the real work itself; every command you run gets translated into an API request and sent to the daemon.

2. The Docker daemon (dockerd) — a background process that does the actual work: building images, creating and running containers, managing networks and volumes. It listens for API requests (usually over a local Unix socket) and executes them by talking to the Linux kernel — creating the namespaces and cgroups from the previous lesson. This is why on Linux you'll often see sudo docker ... — the daemon usually runs as root because manipulating namespaces/cgroups needs elevated privileges, and by default only root (or a user in the docker group) can talk to its socket. 3. Registries — a registry is a server that stores and distributes images. Docker Hub is the default public registry (hub.docker.com) and is where official images like nginx, postgres, and node live. When you run docker run nginx and don't have that image locally, the daemon pulls it from Docker Hub automatically. Companies also run private registries (AWS ECR, Google Artifact Registry, GitHub Container Registry, or self-hosted ones) to store their own application images without publishing them publicly.

Why the client/daemon split matters

Because the client just sends API requests, it can talk to a daemon running somewhere else entirely — not just on your own machine. This is how tools like Docker Desktop work on Mac and Windows: Docker's daemon needs Linux kernel features (namespaces, cgroups) that don't exist natively on macOS or Windows, so Docker Desktop quietly runs a small Linux VM in the background and runs the real daemon inside that. The docker CLI you type into on your Mac is just talking to the daemon inside that hidden VM over the API. This is invisible day-to-day, but it explains why Docker Desktop needs virtualization enabled, and why containers on Mac/Windows have a thin, unavoidable VM layer underneath them even though Linux containers "natively" don't need one.

What happens when you run docker run nginx

Tracing one full command through this architecture ties it together:

1. The client sends a "run this image" request to the daemon.
2. The daemon checks if the nginx image already exists locally.
3. If not, it contacts the configured registry (Docker Hub by default) and downloads (pulls) the image, layer by layer.
4. The daemon creates a new container from that image: a fresh set of namespaces, a cgroup with any resource limits you specified, and a writable filesystem layer on top of the image.
5. The daemon starts the container's main process inside those namespaces.
6. Output/logs stream back from the daemon to the client, which prints them to your terminal.

Every Docker command you'll learn in the rest of this course is a variation of this same round trip: client asks, daemon does the kernel-level work, registry supplies the images when needed.

A quick note on Podman and alternatives

Docker popularized this workflow, but it's not the only implementation. Podman is a popular daemonless alternative (no long-running background process, and it can run rootless more easily) that's largely command-compatible with Docker — most docker commands work if you just type podman instead. Kubernetes itself, as you'll see much later in this course, doesn't even use Docker's daemon internally anymore — it talks to container runtimes through a standard interface called the Container Runtime Interface (CRI), most commonly via containerd (which, notably, is also the component that sits underneath Docker itself). None of this changes anything about images or the container concept — an image built with docker build runs identically under Podman or Kubernetes, because the image format itself (defined by the OCI, the Open Container Initiative) is a shared industry standard, not a Docker-only thing.

What's next

You now know why containers exist and what makes them work under the hood. The next module gets hands-on: installing Docker and running your first real containers.