In CI, when do you mount the Docker socket for Testcontainers instead of running Docker-in-Docker?

## Two ways to hand a daemon to the tests Testcontainers needs one reachable Docker endpoint. CI gives it one of two ways. **Socket mounting.** The job runs in a container (or directly on the host) and `/var/run/docker.sock` is made visible to it. Testcontainers' Unix socket strategy finds it and issues API calls to the *host's* daemon. Containers it starts are therefore **siblings** of the job container, not children — they are ordinary containers on the host, listed by `docker ps` on the host, sharing the host's networks, image cache and disk. **Docker-in-Docker.** A second daemon runs inside the job's environment, usually as a service container from the `docker:dind` image in privileged mode, and the job points at it with `DOCKER_HOST=tcp://…`. Testcontainers' environment strategy finds that. Containers it starts live inside the nested daemon and are invisible to the host. ## What actually differs **Isolation.** DinD gives each job a private daemon: no name or port collisions, no chance of one job's cleanup killing another job's containers, nothing left behind on the host. Socket mounting shares one daemon across everything running on that host, which is fine on a single-use VM and dangerous on a busy shared machine. **Security.** Access to the Docker socket is equivalent to root on the host: anyone who can talk to it can start a privileged container that mounts the host filesystem. Mounting the socket into a job that executes code from forks or untrusted contributors hands over the machine. DinD avoids that specific exposure but requires privileged mode for the nested daemon, which is its own concession — you are trading "root on the host via the API" for "a privileged container on the host". **Image cache and speed.** The single biggest practical difference. A socket-mounted host daemon keeps its image cache between jobs, so the second run of a suite pulls nothing. A fresh DinD daemon starts empty and re-pulls every image on every job, which on a suite with a database, a broker and an object-store emulator dominates the run time and burns registry bandwidth. Mitigations exist — an internal registry mirror, a persistent cache volume — but they are work you would not otherwise do. **Filesystem paths.** With a mounted socket, any path you ask the daemon to bind-mount into a container is resolved on the **daemon's** filesystem, not inside the job container. A path that exists in the job container but not on the host silently mounts as empty or fails. This is the classic socket-mounting trap. APIs that stream content through the Docker API instead of bind-mounting — copying files into a container, or building an image from a context the client uploads — are unaffected, which is why the streaming variants are the safer default in CI. **Networking.** With a mounted socket, published ports land on the host, so the address at which the test JVM reaches a container depends on whether the job itself is on the host or in a container on some bridge network. With DinD, ports are published on the nested daemon's container, and the reachable host name is the service alias in `DOCKER_HOST` rather than localhost. Either way, always ask the container for its address and mapped port rather than assuming localhost — that habit is what makes a suite portable across both models. ## Choosing On hosted ephemeral runners where Docker is already installed on the VM and the VM is destroyed after the job, socket access is the default and the right answer: the isolation argument is satisfied by the VM boundary, and you keep the warm cache. On a self-hosted fleet where many jobs share a long-lived host, prefer isolation — either DinD, or one runner per host with aggressive per-job cleanup, or a remote/managed daemon per job. Where the CI platform forbids privileged containers outright, DinD is simply unavailable and a remote daemon endpoint is the remaining option. ## Things that bite either way Run a resource ceiling check before choosing: a nested daemon plus three service containers on a two-core runner will not be faster in any configuration. Confirm that whatever cleanup mechanism you rely on actually runs on that model. And keep the choice uniform across the fleet — a suite that only passes on the runners with warm caches is a suite whose timeouts are tuned to an accident.