2.1.2 Client Role

The client role in Docker's architecture is to translate user-facing commands into API requests sent to the daemon, and to present the daemon's responses back to the user — the client itself holds no container or image state and performs none of the actual work involved in building or running containers.

The Client Is a Thin Layer

The docker command-line tool accepts commands typed by a user, formats them as the appropriate HTTP request to the daemon's API, and waits for and displays the result. It does not itself manage filesystems, namespaces, or networking.

docker run -d --name myapp myapp:1.0

The client's entire job here is constructing the correct API request representing this command and sending it to whichever daemon it is configured to talk to.

Connecting to a Local or Remote Daemon

Because the client is just an API consumer, it can be pointed at any daemon it can reach, local or remote, without any change to how commands are issued.

docker --context remote-server ps

Docker contexts let a single client switch between talking to different daemons, which is useful when managing containers on multiple hosts from one workstation.

Multiple Kinds of Clients

The official CLI is only one possible client. Docker Desktop's graphical interface, IDE plugins that show running containers, and custom scripts that call the API directly are all clients in the same architectural sense, each translating some other form of user interaction into the same underlying API calls.

curl --unix-socket /var/run/docker.sock http://localhost/containers/json

This is a minimal client, issuing a raw API request without any of the conveniences the official CLI provides.

Why Statelessness in the Client Matters

Because the client holds no state of its own, closing it, restarting it, or running a different client entirely has no effect on containers that are already running — they continue to exist and run as managed by the daemon, entirely independent of whatever client happened to start them.

docker run -d myapp:1.0
exit

Exiting the terminal session that issued this command does not stop the container, because the client's job ended the moment the daemon acknowledged the request; the daemon, not the client, continues managing the running container afterward.

Why This Separation Is Useful

Separating the client from the daemon means a container can be started from one machine and inspected or managed from an entirely different client session later, as long as both are able to reach the same daemon.