Why is the first Testcontainers run on a clean machine far slower than later runs?

## Two costs, only one of them repeats When a test asks Testcontainers for a container, the work splits into two buckets that behave very differently over time. **Image acquisition** happens once per image per machine. The Docker daemon looks in its local image store for the requested repository and tag. If it is missing it contacts the registry, downloads the missing layers, and unpacks them. For a database image that is commonly tens to hundreds of megabytes, which is why the very first `./gradlew test` after cloning a repository feels broken. **Container creation and startup** happens on every run: the daemon creates a writable layer over the image, starts the process, Testcontainers maps the exposed ports onto free host ports, and then blocks on the wait strategy until the service answers. For a well-behaved image this is typically one to a few seconds. ## Why later runs are fast Testcontainers' default image pull policy only pulls when the image is not present locally. Once it is cached, every subsequent run pays only the second bucket. Nothing about Testcontainers itself gets faster — the difference is entirely Docker's image cache. ## Controlling the pull `withImagePullPolicy(...)` takes an `ImagePullPolicy`. `PullPolicy.defaultPolicy()` is pull-if-absent; `PullPolicy.alwaysPull()` forces a pull on every start; `PullPolicy.ageBased(Duration.ofDays(7))` re-pulls only when the cached copy is older than the given age. Age-based is the useful middle ground when you track a moving tag but do not want a network round trip on every run. ## Tag discipline Pin a specific tag, ideally an immutable one. A pinned tag means every developer and every CI job resolves to the same cached image, so cache hits are predictable and test behaviour does not silently change when upstream republishes. A floating tag such as `latest` is worse on both counts: the cache may hold a copy that no longer matches what a colleague has, and reproducing a failure becomes guesswork. ## CI, where the cache may not exist Ephemeral runners start with an empty image store, so every job pays the pull. Options, roughly in order of effort: pull the images in an explicit setup step so the cost is visible and parallel with other setup; run on runners that keep a warm Docker image cache between jobs; or serve images from a registry mirror inside the same network so the download is fast even when it happens. Whichever you choose, keeping the set of distinct images small helps — every extra image is another cold pull. ## What interviewers are checking That you can separate a one-time cost from a per-run cost instead of concluding that "Testcontainers is slow". A candidate who says "the first run pulls, after that it is container startup, and CI pays the pull every time unless we do something about it" has the whole model.