Read Docker Client, Engine and API Versions with docker version

You will finish with a reliable check for the Docker CLI installed on this machine, the Engine it is currently addressing, and the API version the client is using. You will also have copy-and-paste formats for scripts and a way to spot an API override that is hiding normal negotiation. The examples were verified with Docker Community CLI package version 5:29.8.1-1~ubuntu.24.04~noble, providing Docker 29.8.1.

Allow about ten minutes. You need a shell and the docker-ce-cli package. The ordinary checks are unprivileged and read-only. They do not create containers, change contexts or alter Docker configuration. A reachable Docker Engine is needed for the Server section and server-specific fields.

1. Confirm the command you are about to run

Check the executable and package version first. This catches the common mistake of diagnosing one Docker installation while invoking another:

$ command -v docker
/usr/bin/docker
$ docker --version
Docker version 29.8.1, build 4a63305
$ dpkg-query -W -f='${Package}\t${Version}\n' docker-ce-cli
docker-ce-cli	5:29.8.1-1~ubuntu.24.04~noble

docker --version is a short CLI check. It does not replace docker version, which reports independently versioned Docker components and normally separates Client and Server information.

2. Read the complete client and server report

Run the command with no options:

$ docker version
Client: Docker Engine - Community
 Version:           29.8.1
 API version:       1.56
 Go version:        go1.26.8
 Git commit:        4a63305
 Built:             Tue Sep 15 16:26:01 2026
 OS/Arch:           linux/amd64
 Context:           default

Server: Docker Engine - Community
 Engine:
  Version:          29.8.1
  API version:       1.56 (minimum version 1.40)
  Go version:        go1.26.8
  Git commit:        464cd50
  Built:             Tue Sep 15 16:26:01 2026
  OS/Arch:           linux/amd64
  Experimental:      false
 containerd:
  Version:           v2.3.5
 runc:
  Version:           1.5.1
 docker-init:
  Version:           0.19.0

Your build dates, commits, context and component versions will differ. The useful distinction is ownership: Client describes the CLI and its client components; Server describes the Engine and components used by that Engine, such as containerd and runc. Do not report the first Version line as the Engine version without checking which section it belongs to.

3. Extract one value without parsing display text

Use --format when a script or a ticket needs a single field. The option accepts a Go template. Get the Engine version like this:

$ docker version --format '{{.Server.Version}}'
29.8.1

Get the API version currently used by the client with:

$ docker version --format '{{.Client.APIVersion}}'
1.56

These expressions address fields in the structured result, so they are less fragile than extracting a column from the human-readable report. Keep the single quotes around the template in a POSIX shell. They prevent the shell from interpreting the braces before Docker receives them.

A formatted command returning no value or an error is a diagnostic signal, not a reason to guess a field name. First run the complete report and compare its Client or Server section with the field you want.

4. Capture the structured result for inspection

The special format value json is intended for a JSON representation of the version data:

$ docker version --format '{{json .}}' > docker-version.json
$ test -s docker-version.json && echo 'version data captured'
version data captured

Keep the file in a private working directory if it will leave the machine. Version output includes environment details such as operating system, architecture, context, build information and component commits. It is not a secret by itself, but it can reveal deployment details that do not belong in a public issue.

The redirection creates or truncates docker-version.json. To avoid overwriting an existing report, choose a new filename, for example docker-version-$(date +%Y%m%d-%H%M%S).json, after checking that the directory is appropriate. If you created the file only for this check, remove that file when finished. That deletion is irreversible, so do not run it against a path you have not inspected.

5. Check API negotiation before blaming compatibility

The client and Engine negotiate the highest API version both support. The value in .Client.APIVersion is therefore about this connection, not simply the newest API supported by the CLI package.

Check whether the environment is forcing a value:

$ printenv DOCKER_API_VERSION
1.50

No output means the variable is not set in that shell. If it is set, Docker uses that value and disables normal API version negotiation. This can make a current CLI behave as though it were talking to an older API. Inspect the value before changing it, especially in a service environment or a troubleshooting session copied from another host.

For the current shell only, remove the override and check the negotiated value again:

$ unset DOCKER_API_VERSION
$ docker version --format '{{.Client.APIVersion}}'
1.56

6. Handle the common failure paths

If the command cannot reach the selected Engine, the complete report cannot provide a trustworthy Server section. Check the context and Docker service using your normal host procedures, then rerun docker version. Do not use sudo automatically: these checks normally need no elevated privilege, and root does not repair a stopped or remote Engine.

If Client data appears but Server data is missing or an error is reported, keep the two results separate in your notes. Record the selected context, the exact error, and the output of docker --version. If the Engine is remote, verify the remote endpoint and its availability with the team that owns it before changing local Docker settings.

Do not confuse an API mismatch with a component-version mismatch. Record both the Client and Engine versions, the negotiated API version, and any DOCKER_API_VERSION value. That small record is usually enough to make a compatibility report reproducible.