Skip to content

GitLab

runner.li serves GitLab CI for GitLab.com and for self-managed GitLab that is reachable from the internet. Self-managed GitLab on a private network needs private connectivity, which is planned.

runner.li runs GitLab Runner with the Kubernetes executor. The runner token stays with runner.li's runner manager; your job only gets GitLab's CI_JOB_TOKEN, which is scoped to the job and expires with it.

Connect a project or group

  1. In GitLab, create a project or group runner: Settings → CI/CD → Runners → New project runner (or group runner).
  2. Give it the tags we agree on at onboarding, for example runnerli. Leave Run untagged jobs off, so only jobs that ask for runner.li go there.
  3. Send us the runner authentication token (glrt-...) through the secure channel agreed at onboarding.

For flex jobs we use a second runner with its own tag, for example runnerli-flex-6h, so it needs a second token.

Use it in a pipeline

Select runner.li with the tag:

test:
  tags: [runnerli]
  image: ubuntu:24.04
  script:
    - make test

Without image, jobs run in ubuntu:24.04.

Docker in a job

Use the docker:dind service, as on GitLab's own runners:

build:
  tags: [runnerli]
  image: docker:27
  services: [docker:27-dind]
  script:
    - docker build -t "$CI_REGISTRY_IMAGE:$CI_COMMIT_SHORT_SHA" .

The whole job pod runs in its own virtual machine, so the privileged Docker daemon cannot reach the host or other customers.

Next