GitLab CI "Cannot connect to unix:///var/run/docker.sock"

The fast fix

If your GitLab CI job fails with Cannot connect to the Docker daemon at unix:///var/run/docker.sock, your docker client is looking for a local socket that does not exist inside the job container, because DOCKER_HOST is not set. Point the client at the docker:dind service over TCP and the error goes away:

build:

  image: docker:28.3

  services:

    - name: docker:28.3-dind

      alias: docker

  variables:

    DOCKER_HOST: tcp://docker:2376

    DOCKER_TLS_CERTDIR: "/certs"

    DOCKER_CERT_PATH: "/certs/client"

    DOCKER_TLS_VERIFY: "1"

  script:

    - docker info

    - docker build -t my-app .

That is the whole fix for the common case. The rest of this page explains why the socket variant of the error is different from the tcp://docker:2375 variant, and covers the two other setups (socket-mounted runners and the Kubernetes executor) where the same message shows up for a different reason.

Why you get the unix socket variant specifically

This error is not the same as Cannot connect to the Docker daemon at tcp://docker:2375. The address in the message tells you exactly what the client tried:

Cannot connect to the Docker daemon at unix:///var/run/docker.sock. Is the docker daemon running?

When DOCKER_HOST is empty, the Docker CLI falls back to its compiled-in default, the local unix socket at /var/run/docker.sock. Inside a GitLab CI job that uses the docker executor, that socket file simply is not there. The daemon runs in a separate docker:dind service container, not in your job container, so there is nothing listening on the local socket. The client connects, finds no socket, and prints the message above.

The tcp://docker:2375 form is the opposite problem: DOCKER_HOST is set correctly but the dind service is not reachable (missing service, no privileged mode, or a TLS mismatch). If you are seeing that address instead, read the companion write-up on the . Once your builds connect reliably, the multi-stage build guide is a good next step for shrinking the images those pipelines produce.