[Bug]: client version 1.32 is too old. Minimum supported API version is 1.44, please upgrade your client to a newer version

[MartinHaeusler]

Module

Core

Testcontainers version

2.0.1

Using the latest Testcontainers version?

Yes

Host OS

Fedora 43

Host Arch

x86_64

Docker version

Client: Docker Engine - Community
 Version:           29.0.0
 API version:       1.52
 Go version:        go1.25.4
 Git commit:        3d4129b
 Built:             Mon Nov 10 21:49:15 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:45:58 2025
  OS/Arch:          linux/amd64
  Experimental:     false
 containerd:
  Version:          v2.1.5
  GitCommit:        fcd43222d6b07379a4be9786bda52438f0dd16a1
 runc:
  Version:          1.3.3
  GitCommit:        v1.3.3-0-gd842d771
 docker-init:
  Version:          0.19.0
  GitCommit:        de40ad0

What happened?

I'm trying to use a Postgresql 16 container in my unit tests. This has always worked fine. Since this morning, I'm getting the following error:

com.github.dockerjava.api.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"}

	at org.testcontainers.shaded.com.github.dockerjava.core.DefaultInvocationBuilder.execute(DefaultInvocationBuilder.java:237)
	at org.testcontainers.shaded.com.github.dockerjava.core.DefaultInvocationBuilder.get(DefaultInvocationBuilder.java:202)
	at org.testcontainers.shaded.com.github.dockerjava.core.DefaultInvocationBuilder.get(DefaultInvocationBuilder.java:74)
	at org.testcontainers.shaded.com.github.dockerjava.core.exec.InfoCmdExec.exec(InfoCmdExec.java:24)
	at org.testcontainers.shaded.com.github.dockerjava.core.exec.InfoCmdExec.exec(InfoCmdExec.java:14)
	at org.testcontainers.shaded.com.github.dockerjava.core.command.AbstrDockerCmd.exec(AbstrDockerCmd.java:33)
	at org.testcontainers.dockerclient.DockerClientProviderStrategy.tryOutStrategy(DockerClientProviderStrategy.java:289)
	at org.testcontainers.dockerclient.DockerClientProviderStrategy.lambda$getFirstValidStrategy$5(DockerClientProviderStrategy.java:263)
	at java.base/java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:178)
	at java.base/java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:179)
	at java.base/java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:179)
	at java.base/java.util.ArrayList$ArrayListSpliterator.tryAdvance(ArrayList.java:1685)
	at java.base/java.util.stream.ReferencePipeline.forEachWithCancel(ReferencePipeline.java:129)
	at java.base/java.util.stream.AbstractPipeline.copyIntoWithCancel(AbstractPipeline.java:527)
	at java.base/java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:513)
	at java.base/java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:499)
	at java.base/java.util.stream.FindOps$FindOp.evaluateSequential(FindOps.java:150)
	at java.base/java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
	at java.base/java.util.stream.ReferencePipeline.findFirst(ReferencePipeline.java:647)
	at org.testcontainers.dockerclient.DockerClientProviderStrategy.getFirstValidStrategy(DockerClientProviderStrategy.java:264)
	at org.testcontainers.DockerClientFactory.getOrInitializeStrategy(DockerClientFactory.java:154)
	at org.testcontainers.DockerClientFactory.client(DockerClientFactory.java:196)
	at org.testcontainers.DockerClientFactory$1.getDockerClient(DockerClientFactory.java:108)
	at com.github.dockerjava.api.DockerClientDelegate.authConfig(DockerClientDelegate.java:109)
	at org.testcontainers.containers.GenericContainer.start(GenericContainer.java:316)

This, in turn, causes the UnixSocketClientProviderStrategy to fail. It appears that this is the only applicable provider strategy on my system.

Relevant log output

[INFO ] 2025-11-11 10:58:12 [           main] [rMachineClientProviderStrategy]: docker-machine executable was not found on PATH ([/usr/local/bin, /usr/bin])
[ERROR] 2025-11-11 10:58:12 [           main] [d.DockerClientProviderStrategy]: Could not find a valid Docker environment. Please check configuration. Attempted configurations were:
	UnixSocketClientProviderStrategy: 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"}
)
	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.

Additional Information

The "client" the message talks about seems to be the java docker client, but since Testcontainers uses a shaded variant of that dependency, I have a hard time figuring out what is actually being used there.

[bsa01]

I got the same problem, as a workaround you can add a file docker-java.properties to your ../test/resources folder with api.version=1.44.

Or check DefaultDockerClientConfig of docker-java for other ways (ENV, user home, ...) to set the api version manually.

[MartinHaeusler]

@bsa01 thank you, that worked nicely.

[omasseau]

Same problem here with test containers 1.21.3
It was working perfectly yesterday and today suddenly we got this error in our build without really understanding why.

EDIT: Seems the problem is the docker:dind image which was upgraded this morning to version 29, which requires version 1.44 of the client API.

[arthur-mts]

@omasseau same here.
This workaround fixed the problem for me, but I am wondering if I could specify the docker:dind version in my GitLab service and remove this properties file.

[arthur-mts]

I've found out that you can specify the GitLab services versions by doing this:

  services:
    - name: docker:25-dind
      command: [ '--tls=false' ]

It will solve the problem until the real fix.

[kiview]

Thanks for raising @MartinHaeusler, closing as duplicate of #11212, and will document workaround there's.