[Feature]: Gitlab CI Support

Module

No response

Problem

In many GitLab CI pipelines, integration tests that rely on Testcontainers need a running Docker daemon. The typical workaround is:

1. Run a docker:dind service in privileged mode
2. Mount the host Docker socket into the test container
3. 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

Start by reviewing TestcontainersConfiguration and the existing Docker environment detection and connection setup. Define how GitLab CI service discovery, Docker host selection, TLS certificates, and fallback behavior should fit the library, then verify the configuration and CI scenarios described in the issue.