Services & Sidecars
Jobs that declare services: get sidecar containers running alongside the main job container. glci passes the full service definition to gitlab-runner, which manages the lifecycle on the local Docker daemon.
Service behavior – DNS aliases, health checks, pull policies, and the extended name/alias/entrypoint/command/variables/pull_policy/ports/docker: syntax – works the same as production GitLab CI. Refer to the GitLab CI services documentation for usage details.
Docker-in-Docker services#
Jobs that use docker:dind as a service receive special treatment. glci creates an isolated per-job Docker network to prevent alias collisions when multiple DinD jobs run concurrently in the same pipeline. See the Docker & Network page for DinD details.
Simulation mode#
When running with --simulate, services are skipped entirely. Simulated jobs echo their script commands without executing them, so sidecar containers are unnecessary.
Differences from production GitLab CI#
- Service logs: Visible in Docker daemon logs (
docker logs <container>), not in the job trace. - Host port access: Service ports are not exposed to the host by default. In production this is not applicable since jobs run on a remote runner.
- Local resources: Services run on your local Docker daemon, which means faster container startup but local resource consumption.
Everything else – DNS alias derivation, TCP readiness checks, default: inheritance, the full extended service syntax – is identical to production.