docker-library
`docker:stable` image is outdated causing API version mismatch with updated `docker:dind`
Hello,
We recently encountered an issue in our CI pipelines after docker:dind was updated.
The docker:stable image, which many users rely on as the default Docker CLI image, ships with an older client API version (1.40). Since docker:dind now requires a newer API version, the following error occurs:
Error response from daemon: client version 1.40 is too old. Minimum supported API version is 1.44, please upgrade your client to a newer version
This creates a version mismatch where the default CLI image (docker:stable) cannot communicate with the current docker:dind.
Thank you!
Workaround (GitLab)
a) Lock to a specific major Docker version
job[...]:
- image: docker:stable
+ image: docker:29
services:
- - docker:dind
+ - name: docker:29-dind
+ alias: docker
b) Use stable-dind (not recommended)
⚠️ Note: The docker:stable and docker:stable-dind images is currently over 5 years old.
job[...]:
image: docker:stable
services:
- - docker:dind
+ - name: docker:stable-dind
+ alias: docker
Hello, same issue here but with the latest version. We use Docker Dind for our GitLab pipeline (
services:
- name: docker:dind
) and it was causing that exact same error, but when we were running some Java tests with Localstack. Full error messages:
Could not find a valid Docker environment. Please check configuration. Attempted configurations were:
EnvironmentAndSystemPropertyClientProviderStrategy: failed with exception BadRequestException (Status 400: {"message":"client version 1.32 is too old. Minimum supported API version is 1.44, please upgrade your client to a newer version"}
)
UnixSocketClientProviderStrategy: failed with exception InvalidConfigurationException (Could not find unix domain socket). Root cause NoSuchFileException (/var/run/docker.sock)
DockerDesktopClientProviderStrategy: failed with exception NullPointerException (Cannot invoke "java.nio.file.Path.toString()" because the return value of "org.testcontainers.dockerclient.DockerDesktopClientProviderStrategy.getSocketPath()" is null)As no valid configuration was found, execution cannot continue.
Did a workaround by using docker:28-dind
See https://github.com/docker-library/docker/issues/301#issuecomment-804402059:
Channel aliases were limited in: #179. The Docker Hub Page shows which are actively maintained under "Supported tags and respective Dockerfile links".
Or in practical terms: the floating stable tag is (long) unsupported and will (very likely) stay so. If somewhere in your workflow it is being pulled, it is probably time to adjust or report it to any upstream you use that still employs this tag.
Having a "similar" issue here using
image: docker:latest
services:
- docker:dind
Error response from daemon: client version 1.52 is too new. Maximum supported API version is 1.43
@Samuel-MM, that sounds like your docker:dind image was cached or something. The images on Docker Hub are up to date. docker:dind and docker:latest are tags for the same image.
$ docker pull docker:cli
cli: Pulling from library/docker
Digest: sha256:87858a6dd14149240f4a2c33e0ec0f32a5ac1bb2548c04f5a20694ea25cb6157
Status: Image is up to date for docker:cli
docker.io/library/docker:cli
$ docker pull docker:dind
dind: Pulling from library/docker
Digest: sha256:96789d56621ae702a2f8aa316c87a1a1875dd3f02bf67cdcb56a524a09fa3af9
Status: Image is up to date for docker:dind
docker.io/library/docker:dind
$ docker pull docker:latest
latest: Pulling from library/docker
Digest: sha256:96789d56621ae702a2f8aa316c87a1a1875dd3f02bf67cdcb56a524a09fa3af9
Status: Image is up to date for docker:latest
docker.io/library/docker:latest
$ docker images docker
REPOSITORY TAG IMAGE ID CREATED SIZE
docker dind 96789d56621a 15 hours ago 552MB
docker latest 96789d56621a 15 hours ago 552MB
docker cli 87858a6dd141 16 hours ago 289MB
$ # cli image versions
$ docker run -it --rm docker:cli docker version
Client:
Version: 29.0.0
API version: 1.52
Go version: go1.25.4
Git commit: 3d4129b
Built: Mon Nov 10 21:45:29 2025
OS/Arch: linux/amd64
Context: default
Get "http://docker:2375/v1.52/version": dial tcp: lookup docker: i/o timeout
$ # dind image versions (it is FROM the cli image, so the cli version is the same)
$ docker run -it --rm --privileged --name dind-test docker:dind
...
INFO[2025-11-11T17:23:42.856585158Z] Daemon has completed initialization
$ docker exec -it dind-test sh
/ # docker version
Client:
Version: 29.0.0
API version: 1.52
Go version: go1.25.4
Git commit: 3d4129b
Built: Mon Nov 10 21:45:29 2025
OS/Arch: linux/amd64
Context: default
Server: Docker Engine - Community
Engine:
Version: 29.0.0
API version: 1.52 (minimum version 1.44)
Go version: go1.25.4
Git commit: d105562
Built: Mon Nov 10 21:47:52 2025
OS/Arch: linux/amd64
Experimental: false
containerd:
Version: v2.1.5
GitCommit: fcd43222d6b07379a4be9786bda52438f0dd16a1
runc:
Version: 1.3.3
GitCommit: v1.3.3-0-gd842d77
docker-init:
Version: 0.19.0
GitCommit: de40ad0
As for the original issue regarding docker:stable, @jnoordsij is correct: it is unsupported and has not been updated in a long time. We have no plans to bring it back without there being support within the moby/moby project for a Docker "stable" that is different from the latest release.
See #301 (comment):
Channel aliases were limited in: #179. The Docker Hub Page shows which are actively maintained under "Supported tags and respective Dockerfile links".
Or in practical terms: the floating
stabletag is (long) unsupported and will (very likely) stay so. If somewhere in your workflow it is being pulled, it is probably time to adjust or report it to any upstream you use that still employs this tag.
In the linked issue there was some debate about how many people might still be using that tag. After doing some research, here’s what I found:
- https://grep.app/search?q=docker%3Astable
- https://github.com/search?q=docker%3Astable&type=code
I’ve seen some fairly large projects on that list as well. Because of this, it might be worth considering a strategy where stable points to latest (or to another actively maintained tag). A more radical solution would be to remove deprecated tags altogether - this would immediately surface the issue and force developers to investigate the root cause. In that case, it would be important to clearly communicate in the Docker Hub description which tags are no longer supported, along with a recommendation for which tag users should switch to.
I'm having a similar issue when using Docker executor with image bentolor/docker-dind-awscli with or without the latest tag.
stages:
- test
image: bentolor/docker-dind-awscli
tests:
stage: test
only:
- main
services:
- docker:dind
script:
- docker build -t tests .
Log:
Running with gitlab-runner 18.4.0~pre.195.g5de42c65 (5de42c65)
on blue-2.saas-linux-small-amd64.runners-manager.gitlab.com/default XxXxXxXxX, system ID: s_4f69a8eedce5
Preparing the "docker+machine" executor
Using Docker executor with image bentolor/docker-dind-awscli:latest ...
Starting service docker:dind...
Using effective pull policy of [always] for container docker:dind
Pulling docker image docker:dind ...
Using docker image sha256:58cdce60b4d9596765151d2508cad4e3441223cf71e32ba68015def44b654c2e for docker:dind with digest docker@sha256:96789d56621ae702a2f8aa316c87a1a1875dd3f02bf67cdcb56a524a09fa3af9 ...
Waiting for services to be up and running (timeout 30 seconds)...
Using effective pull policy of [always] for container bentolor/docker-dind-awscli:latest
Pulling docker image bentolor/docker-dind-awscli:latest ...
Using docker image sha256:91276a6bcb118490bbd187fb59debaec29250aad8fdf3fd05ceb259e3534c3d1 for bentolor/docker-dind-awscli:latest with digest bentolor/docker-dind-awscli@sha256:73fb18d7e89d17099cd5da01447203b5255a7a9522dcf2b72bd950ab4bdd5dc4 ...
Preparing environment
Using effective pull policy of [always] for container sha256:be592dfad1d9b47f5b7e72da407136fc4e0c343c23220fd691e3aa38168e6c86
...
Executing "step_script" stage of the job script
Using effective pull policy of [always] for container bentolor/docker-dind-awscli:latest
Using docker image sha256:91276a6bcb118490bbd187fb59debaec29250aad8fdf3fd05ceb259e3534c3d1 for bentolor/docker-dind-awscli:latest with digest bentolor/docker-dind-awscli@sha256:73fb18d7e89d17099cd5da01447203b5255a7a9522dcf2b72bd950ab4bdd5dc4 ...
$ docker build -t tests .
ERROR: Error response from daemon: client version 1.43 is too old. Minimum supported API version is 1.44, please upgrade your client to a newer version: driver not connecting
Cleaning up project directory and file based variables
ERROR: Job failed: exit code 1
The error is:
ERROR: Error response from daemon: client version 1.43 is too old. Minimum supported API version is 1.44, please upgrade your client to a newer version: driver not connecting
You need to either upgrade the Docker CLI inside bentolor/docker-dind-awscli or downgrade your Docker engine (docker:28-dind, for example).
The point of floating tag like stable is to follow the stable status without effort, and only fix things when they break. It is not adapted to production environment, but it is to dev and ci environments.
With versioned tags, the version gets duplicated everywhere, gets deprecated more quickly, and requires more work for few to none benefit in a lot of environments.
stableis a notion used everywhere, from kernels to distros, from applications to a lot of docker images. I can understand why this is currently broken because of moby not supporting it, but I would not understand if it would be definitely abandoned... 😢
observed same issue as @bencurio .
`~# docker version
Client: Docker Engine - Community Version: 29.0.2 API version: 1.40 (downgraded from 1.52) Go version: go1.25.4 Git commit: 8108357 Built: Mon Nov 17 12:33:26 2025 OS/Arch: linux/amd64 Context: default Error response from daemon: client version 1.40 is too old. Minimum supported API version is 1.44, please upgrade your client to a newer version`
Yeah, this is an unfortunate artifact of Docker previously having a "stable" version and no longer doing so - the only Docker-supported release of Docker is now latest.
See also https://github.com/moby/moby/blob/45169d5784e7f18233fbfca1a00bfe0699fb1ae2/project/BRANCHES-AND-TAGS.md (which looks like it needs an update to reflect 29+, but the pattern is pretty clear regardless).