GitLab: Running your tests with Testcontainers

This documentation is part of the CI/CD guide. View the full guide here: How to use GitLab CI/CD.

👋 Welcome to the Stackhero documentation!

Stackhero provides a ready-to-use GitLab cloud solution designed for teams that need a fast, secure, and scalable environment:

• Unlimited users, repositories, data transfers, and CI/CD processing time for complete flexibility.
• Effortless updates with a single click, so your environment stays current without downtime.
• Custom domain name secured with HTTPS (for example, https://git.your-company.com) for professional branding and security.
• Consistent performance and strong security on your own private, dedicated infrastructure. There are no noisy neighbors and you have full isolation.
• Choice of hosting location: 🇪🇺 Europe or 🇺🇸 USA to suit your compliance or latency needs.

Get started fast and focus on your code. Stackhero's GitLab cloud hosting solution is ready to use in about 5 minutes.

If your test suite uses Testcontainers, a library that starts real services (databases, message brokers and more) as disposable Docker containers while your tests run, the configuration above already covers it. Keep the docker:29-dind service and both variables: Testcontainers uses DOCKER_HOST to reach the Docker daemon and to connect to the containers it starts, so nothing else is required.

Leaving DOCKER_HOST out is the most common cause of Testcontainers failures in CI. The library then falls back to the Docker socket mounted by the runner and cannot reach its own test containers, which usually shows up as its Ryuk helper container timing out.