[Feature]: Gitlab CI Support
Author: hypery2kCreated Sep 14, 2026Updated Sep 16, 2026
Labelstype/feature
Module
No response
Problem
In many GitLab CI pipelines, integration tests that rely on Testcontainers need a running Docker daemon. The typical workaround is:
- Run a docker:dind service in privileged mode
- Mount the host Docker socket into the test container
- Set DOCKER_HOST=unix:///var/run/docker.sock in the test environment
This approach has several pain points:
| Issue | Impact |
|---|---|
| Privileged mode | Requiresprivileged: truein the job, which is disallowed in many shared runners for security reasons. |
| Docker socket exposure | Mounting/var/run/docker.sockcan inadvertently grant the test container full control over the host Docker daemon. |
| Port collisions & networking | The test container must be on the same network namespace as thedocker:dindservice, which is fragile and hard to debug. |
| Resource overhead | Each job starts a full DinD daemon, increasing build time and memory usage. |
| Complex configuration | Users must remember to setDOCKER_HOST,DOCKER_TLS_VERIFY, etc., which is error‑prone. |
A native GitLab CI services integration would eliminate the need for privileged mode, reduce configuration complexity, and improve security:
- Security – Avoid exposing the host Docker socket or running privileged containers.
- Simplicity – A single configuration flag should be sufficient to enable CI‑specific behavior.
- Performance – Reuse the GitLab CI service container’s Docker daemon instead of launching a new DinD instance per job.
- Consistency – Tests run in CI will mirror local development environments that use Testcontainers without any special CI configuration.
Solution
Add a new configuration option to the `Testcontainers` Java library (and analogous options for other languages) that allows the user to specify a GitLab CI service name and network alias. Example (Java):TestcontainersConfiguration.getInstance()
.withGitLabService("docker:dind", "docker");Internally, Testcontainers will:
1. Detect that it is running inside a GitLab CI job (e.g., by checking `CI` environment variable).
2. Resolve the service container’s IP address via the GitLab CI network (`docker` alias).
3. Set `DOCKER_HOST=tcp://<service-ip>:2375` (or `2376` if TLS is enabled).
4. Optionally configure TLS certificates if the service exposes them.Runtime Behavior
- No privileged mode – The job can run without `privileged: true`.
- Automatic network discovery – Testcontainers will query the GitLab CI network for the service alias.
- TLS support – If the GitLab service exposes TLS, the library can automatically pick up the certificates from known paths (`/etc/docker/certs.d/`).Fallback
If the CI environment is not detected or the service is missing, Testcontainers will fall back to its normal local Docker daemon strategy, preserving backward compatibility.Benefit
| Category | Impact |
| --- | --- |
| Security | Positive – reduces privileged execution and socket exposure. |
| Performance | Slightly better – reusing the CI service container avoids launching a separate DinD daemon. |
| Developer Experience | Positive – fewer environment variables, clearer CI configuration. |
| Maintenance | Minimal – only a small API addition and a few environment checks. |
| Compatibility | Backward compatible; old jobs continue to work unchanged. |Alternatives
- Priviledge DinD Runner in Kubernetes
Would you like to help contributing this feature?
Yes
Source: testcontainers/testcontainers-java