Runner SaaS

You can run your CI/CD jobs on GitLab.com using SaaS runners hosted by GitLab to seamlessly build, test and deploy your application on different environments. These runners fully integrated with GitLab.com and are enabled by default for all projects, with no configuration required. Your jobs can run on:

Refer to the compute minutes cost factor for the cost factor applied to the machine type based on size. The number of minutes you can use on these runners depends on the maximum number of compute minutes in your subscription plan.

How SaaS runners work

When you use SaaS runners:

  • Each of your jobs runs in a newly provisioned VM, which is dedicated to the specific job.
  • The VM is active only for the duration of the job and immediately deleted. This means that any changes that your job makes to the virtual machine will not be available to a subsequent job.
  • The virtual machine where your job runs has sudo access with no password.
  • The storage is shared by the operating system, the image with pre-installed software, and a copy of your cloned repository. This means that the available free disk space for your jobs to use is reduced.
  • Untagged jobs automatically run in containers on the small Linux runners.
  • The objective is to make 90% of CI jobs start executing in 120 seconds or less. The error rate target will be less than 0.5%.
note
Jobs handled by SaaS runners on GitLab.com time out after 3 hours, regardless of the timeout configured in a project.

Security for SaaS runners

GitLab SaaS runners on Linux and Windows run on Google Compute Platform. The Google Infrastructure Security Design Overview whitepaper provides an overview of how Google designs security into its technical infrastructure. The GitLab Trust Center and GitLab Security Compliance Controls pages provide an overview of the security and compliance controls that govern the GitLab SaaS runners.

The following section provides an overview of the additional built-in layers that harden the security of the GitLab Runner SaaS CI build environment.

Security of CI job execution

A dedicated temporary runner VM hosts and runs each CI job. On GitLab SaaS, two CI jobs never run on the same VM.

In this example, there are three jobs in the project’s pipeline. Therefore, there are three temporary VMs used to run that pipeline, or one VM per job.

Job isolation

The build job ran on runner-ns46nmmj-project-43717858, test job on f131a6a2runner-new2m-od-project-43717858 and deploy job on runner-tmand5m-project-43717858.

GitLab sends the command to remove the temporary runner VM to the Google Compute API immediately after the CI job completes. The Google Compute Engine hypervisor takes over the task of securely deleting the virtual machine and associated data.

Network security of CI job VMs

  • Firewall rules only allow outbound communication from the temporary VM to the public internet.
  • Inbound communication from the public internet to the temporary VM is not allowed.
  • Firewall rules do not permit communication between VMs.
  • The only internal communication allowed to the temporary VMs is from the runner manager.