19.3.3.2 Version Server Output
A focused guide to Version Server Output, connecting core concepts with practical Docker and container operations.
The Server section in docker version output describes the Docker daemon (also called Docker Engine) running on the host, along with the versions of the runtime components it uses. This section requires a successful connection to the daemon and is absent when the daemon is not running or the client cannot reach it.
Server Output Structure
docker version
The Server section appears after the Client section:
Server: Docker Engine - Community
Engine:
Version: 25.0.3
API version: 1.44 (minimum version 1.12)
Go version: go1.21.6
Git commit: 4debf41
Built: Tue Feb 6 21:12:32 2024
OS/Arch: linux/amd64
Experimental: false
containerd:
Version: 1.7.13
GitCommit: 7c3aca7a610df76212171d200ca3811ff6096eb8
runc:
Version: 1.1.12
GitCommit: v1.1.12-0-g51d5e946
docker-init:
Version: 0.19.0
GitCommit: de40ad0
Product Line Label
The header Server: Docker Engine - Community identifies the product variant of the Docker Engine. This mirrors the client label and can be:
Docker Engine - Community: The open-source Docker Engine.Docker Desktop: When Docker Desktop is running, the daemon it manages appears with this label.Mirantis Container Runtime: The enterprise Docker distribution.
Engine Subsection
Version
The version number of the Docker daemon binary (dockerd). This is the primary version indicator for the server-side component and is what most upgrade procedures target.
API version
The API version range the daemon supports, displayed in the format:
1.44 (minimum version 1.12)
The first number is the maximum API version the daemon understands — the highest-version API calls it can respond to. The minimum version is the lowest API version the daemon will accept. Clients using API versions below the minimum will be rejected with an incompatibility error.
The API version is negotiated between client and daemon at connection time. The effective version used during a session is the minimum of the client's maximum and the daemon's maximum. If the client's maximum is lower than the daemon's minimum, the connection fails.
Go version
The Go language compiler version used to build the daemon binary. This is relevant when evaluating whether a specific Go security advisory affects a given Docker installation.
Git commit
The short commit hash from the Docker source repository corresponding to this daemon build. This can be used to look up the exact source code, changelog entries, or commit messages associated with this release.
Built
The timestamp when the daemon binary was compiled. For official releases, this corresponds to the release date.
OS/Arch
The operating system and CPU architecture where the daemon is running:
linux/amd64: Linux on 64-bit Intel/AMD (most server deployments).linux/arm64: Linux on ARM64 (AWS Graviton, Raspberry Pi 4, Apple Silicon).windows/amd64: Windows containers daemon on Windows hosts.
This value is determined by the host where the daemon runs, not the host running the CLI. When using Docker Desktop on macOS, the client's OS/Arch may be darwin/arm64 while the server's OS/Arch is linux/amd64 because the daemon runs inside a Linux virtual machine.
Experimental
A boolean indicating whether experimental Docker features are enabled on the daemon. When true, features marked as experimental in Docker documentation are available. Experimental features may be unstable or subject to change in future releases.
Experimental mode is enabled in the Docker daemon configuration file or via the --experimental flag when starting the daemon.
containerd Subsection
containerd is the container runtime daemon that Docker Engine delegates container lifecycle management to. It handles image storage, container creation, execution monitoring, and snapshot management.
- Version: The version of the containerd binary installed alongside Docker.
- GitCommit: The full Git commit hash of the containerd source code corresponding to this build. Unlike the Docker Engine fields, containerd uses a full hash rather than a short one.
The containerd version is relevant when diagnosing container runtime issues or when checking compatibility with Kubernetes, which also uses containerd as a runtime in many configurations.
runc Subsection
runc is the low-level OCI (Open Container Initiative) runtime that containerd uses to create and run individual containers. It interacts directly with Linux kernel primitives including namespaces, cgroups, and seccomp filters.
- Version: The runc binary version.
- GitCommit: The Git commit hash of the runc source code.
runc version matters for security auditing because container escape vulnerabilities (like CVE-2019-5736) are typically found at the runc level. Ensuring runc is up to date is part of container security hardening.
docker-init Subsection
docker-init is a minimal init process used as PID 1 in containers started with the --init flag. It is responsible for proper signal forwarding to child processes and zombie process reaping.
- Version: The docker-init binary version.
- GitCommit: The Git commit hash.
Without an init process as PID 1, containers that spawn child processes may accumulate zombie processes, and signals sent to the container may not reach the intended process.
Extracting Server Fields
Go templates can extract individual server fields:
docker version --format "{{.Server.Version}}"
docker version --format "{{.Server.APIVersion}}"
docker version --format "{{.Server.Os}}/{{.Server.Arch}}"
docker version --format "{{.Server.Experimental}}"
When the Server Section Is Missing
If the daemon is not running or the socket is not accessible, the Server section is replaced with a connection error:
Cannot connect to the Docker daemon at unix:///var/run/docker.sock.
Is the docker daemon running?
On Windows:
error during connect: In the default daemon configuration on Windows,
the docker client must be run with elevated privileges to connect.
The presence and content of the Server section is therefore a diagnostic indicator of daemon health and client connectivity.