info:To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments
---
---
# Runner Cloud for Linux **(FREE)**
This document was moved to [another location](../runner_cloud/linux_runner_cloud.md).
Runner Cloud runners for Linux run in autoscale mode and are powered by Google Cloud Platform.
<!-- This redirect file can be deleted after 2022-02-05. -->
<!-- Before deletion, see: https://docs.gitlab.com/ee/development/documentation/#move-or-rename-a-page -->
Autoscaling means reduced queue times to spin up CI/CD jobs, and isolated VMs for each job, thus maximizing security. These shared runners are available on GitLab.com.
GitLab offers Ultimate tier capabilities and included CI/CD minutes per group per month for our [Open Source](https://about.gitlab.com/solutions/open-source/join/), [Education](https://about.gitlab.com/solutions/education/), and [Startups](https://about.gitlab.com/solutions/startups/) programs. For private projects, GitLab offers various [plans](https://about.gitlab.com/pricing/), starting with a Free tier.
All your CI/CD jobs run on [n1-standard-1 instances](https://cloud.google.com/compute/docs/machine-types) with 3.75GB of RAM, CoreOS and the latest Docker Engine
installed. Instances provide 1 vCPU and 25GB of HDD disk space. The default
region of the VMs is US East1.
Each instance is used only for one job. This ensures that any sensitive data left on the system can't be accessed by other people's CI/CD jobs.
The `gitlab-shared-runners-manager-X.gitlab.com` fleet of runners are dedicated for GitLab projects as well as community forks of them. They use a slightly larger machine type (n1-standard-2) and have a bigger SSD disk size. They don't run untagged jobs and unlike the general fleet of shared runners, the instances are re-used up to 40 times.
Jobs handled by the shared runners on GitLab.com (`shared-runners-manager-X.gitlab.com`),
**time out after 3 hours**, regardless of the timeout configured in a
project. Check the issues [#4010](https://gitlab.com/gitlab-com/infrastructure/-/issues/4010) and [#4070](https://gitlab.com/gitlab-com/infrastructure/-/issues/4070) for the reference.
These runners share a [distributed cache](https://docs.gitlab.com/runner/configuration/autoscale.html#distributed-runners-caching) through use of a Google Cloud Storage (GCS) bucket. Cache contents not updated within the last 14 days are automatically removed through use of an [object lifecycle management policy](https://cloud.google.com/storage/docs/lifecycle).
## Pre-clone script
Build Cloud runners for Linux provide a way to run commands in a CI
job before the runner attempts to run `git init` and `git fetch` to
demonstrates how you might use a pre-clone step to seed the build
directory.
NOTE:
The `CI_PRE_CLONE_SCRIPT` variable does not work on Windows runners.
## `config.toml`
The full contents of our `config.toml` are:
NOTE:
Settings that are not public are shown as `X`.
**Google Cloud Platform**
```toml
concurrent=X
check_interval=1
metrics_server="X"
sentry_dsn="X"
[[runners]]
name="docker-auto-scale"
request_concurrency=X
url="https://gitlab.com/"
token="SHARED_RUNNER_TOKEN"
pre_clone_script="eval \"$CI_PRE_CLONE_SCRIPT\""
executor="docker+machine"
environment=[
"DOCKER_DRIVER=overlay2",
"DOCKER_TLS_CERTDIR="
]
limit=X
[runners.docker]
image="ruby:2.5"
privileged=true
volumes=[
"/certs/client",
"/dummy-sys-class-dmi-id:/sys/class/dmi/id:ro"# Make kaniko builds work on GCP.
]
[runners.machine]
IdleCount=50
IdleTime=3600
MaxBuilds=1# For security reasons we delete the VM after job has finished so it's not reused.
MachineName="srm-%s"
MachineDriver="google"
MachineOptions=[
"google-project=PROJECT",
"google-disk-size=25",
"google-machine-type=n1-standard-1",
"google-username=core",
"google-tags=gitlab-com,srm",
"google-use-internal-ip",
"google-zone=us-east1-d",
"engine-opt=mtu=1460",# Set MTU for container interface, for more information check https://gitlab.com/gitlab-org/gitlab-runner/-/issues/3214#note_82892928
"engine-opt=ipv6",# This will create IPv6 interfaces in the containers.
"engine-opt=fixed-cidr-v6=fc00::/7",
"google-operation-backoff-initial-interval=2"# Custom flag from forked docker-machine, for more information check https://github.com/docker/machine/pull/4600
info:To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments
---
---
# VM instances and images for Build Cloud for macOS **(FREE)**
This document was moved to [another location](../../runner_cloud/macos/environment.md).
When you use the Build Cloud for macOS:
<!-- This redirect file can be deleted after 2022-02-05. -->
<!-- Before deletion, see: https://docs.gitlab.com/ee/development/documentation/#move-or-rename-a-page -->
- 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.
## VM types
The virtual machine where your job runs has `sudo` access with no password.
For the Beta, there is only one available machine type, `gbc-macos-large`.
| Instance type | vCPUS | Memory (GB) |
| --------- | --- | ------- |
| `gbc-macos-large` | 4 | 10 |
## VM images
You can execute your build on one of the following images.
You specify this image in your `.gitlab-ci.yml` file.
Each image is running a specific version of macOS and Xcode.
- Additional details on the support policy and image update release process are documented
[in this project](https://gitlab.com/gitlab-org/ci-cd/shared-runners/images/macstadium/orka/-/blob/55bf59c8fa88712960afff2bf6ecc5daa879a8f5/docs/overview.md#os-images).
info:To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments
---
---
# Runner Cloud for macOS (Beta) **(FREE SAAS)**
This document was moved to [another location](../runner_cloud/macos_runner_cloud.md).
The Runner Cloud for macOS Beta provides on-demand runners integrated with GitLab SaaS [CI/CD](../../../ci/index.md).
<!-- This redirect file can be deleted after 2022-02-05. -->
Use these runners to build, test, and deploy apps for the Apple ecosystem (macOS, iOS, tvOS). You can take advantage
<!-- Before deletion, see: https://docs.gitlab.com/ee/development/documentation/#move-or-rename-a-page -->
of all the capabilities of the GitLab single DevOps platform and not have to manage or operate a
build environment.
Build Cloud runners for macOS are in [Beta](https://about.gitlab.com/handbook/product/gitlab-the-product/#beta)
and shouldn't be relied upon for mission-critical production jobs.
## Quickstart
To start using Build Cloud for macOS Beta, you must submit an access request [issue](https://gitlab.com/gitlab-com/macos-buildcloud-runners-beta/-/issues/new?issuable_template=beta_access_request). After your
access has been granted and your build environment configured, you must configure your
`.gitlab-ci.yml` pipeline file:
1. Add a `.gitlab-ci.yml` file to your project repository.
1. Specify the [image](macos/environment.md#vm-images) you want to use.
1. Commit a change to your repository.
The runners automatically run your build.
## Example `.gitlab-ci.yml` file
The following sample `.gitlab-ci.yml` file shows how to start using the runners for macOS:
```yaml
.macos_buildcloud_runners:
tags:
-shared-macos-amd64
image:macos-11-xcode-12
stages:
-build
-test
before_script:
-echo "started by ${GITLAB_USER_NAME}"
build:
extends:
-.macos_buildcloud_runners
stage:build
script:
-echo "running scripts in the build job"
test:
extends:
-.macos_buildcloud_runners
stage:test
script:
-echo "running scripts in the test job"
```
NOTE:
During the Beta period, the architecture of this solution will change. Rather than the jobs running on a specific VM instance, they will run on an ephemeral VM instance that is created by an autoscaling instance, known as the Runner Manager. We will notify all Beta participants of any downtime required to do this work.
info:To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments
---
---
# Runner Cloud for Windows (beta) **(FREE)**
This document was moved to [another location](../runner_cloud/windows_runner_cloud.md).
Runner Cloud runners for Windows are in [beta](https://about.gitlab.com/handbook/product/gitlab-the-product/#beta)
<!-- This redirect file can be deleted after 2022-02-05. -->
and shouldn't be used for production workloads.
<!-- Before deletion, see: https://docs.gitlab.com/ee/development/documentation/#move-or-rename-a-page -->
During this beta period, the [shared runner pipeline quota](../../../user/admin_area/settings/continuous_integration.md#shared-runners-pipeline-minutes-quota)
applies for groups and projects in the same manner as Linux runners. This may
change when the beta period ends, as discussed in this [related issue](https://gitlab.com/gitlab-org/gitlab/-/issues/30834).
Windows runners on GitLab.com autoscale by launching virtual machines on
developed by GitLab for the [custom executor](https://docs.gitlab.com/runner/executors/custom.html).
Windows runners execute your CI/CD jobs on `n1-standard-2` instances with
2 vCPUs and 7.5 GB RAM. You can find a full list of available Windows packages in
the [package documentation](https://gitlab.com/gitlab-org/ci-cd/shared-runners/images/gcp/windows-containers/blob/main/cookbooks/preinstalled-software/README.md).
We want to keep iterating to get Windows runners in a stable state and
info:To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments
---
# Runner Cloud for Linux **(FREE)**
Runner Cloud runners for Linux run in autoscale mode and are powered by Google Cloud Platform.
Autoscaling means reduced queue times to spin up CI/CD jobs, and isolated VMs for each job, thus maximizing security. These shared runners are available on GitLab.com.
GitLab offers Ultimate tier capabilities and included CI/CD minutes per group per month for our [Open Source](https://about.gitlab.com/solutions/open-source/join/), [Education](https://about.gitlab.com/solutions/education/), and [Startups](https://about.gitlab.com/solutions/startups/) programs. For private projects, GitLab offers various [plans](https://about.gitlab.com/pricing/), starting with a Free tier.
All your CI/CD jobs run on [n1-standard-1 instances](https://cloud.google.com/compute/docs/machine-types) with 3.75GB of RAM, CoreOS and the latest Docker Engine
installed. Instances provide 1 vCPU and 25GB of HDD disk space. The default
region of the VMs is US East1.
Each instance is used only for one job. This ensures that any sensitive data left on the system can't be accessed by other people's CI/CD jobs.
The `gitlab-shared-runners-manager-X.gitlab.com` fleet of runners are dedicated for GitLab projects as well as community forks of them. They use a slightly larger machine type (n1-standard-2) and have a bigger SSD disk size. They don't run untagged jobs and unlike the general fleet of shared runners, the instances are re-used up to 40 times.
Jobs handled by the shared runners on GitLab.com (`shared-runners-manager-X.gitlab.com`),
**time out after 3 hours**, regardless of the timeout configured in a
project. Check the issues [#4010](https://gitlab.com/gitlab-com/infrastructure/-/issues/4010) and [#4070](https://gitlab.com/gitlab-com/infrastructure/-/issues/4070) for the reference.
These runners share a [distributed cache](https://docs.gitlab.com/runner/configuration/autoscale.html#distributed-runners-caching) through use of a Google Cloud Storage (GCS) bucket. Cache contents not updated within the last 14 days are automatically removed through use of an [object lifecycle management policy](https://cloud.google.com/storage/docs/lifecycle).
## Pre-clone script
Build Cloud runners for Linux provide a way to run commands in a CI
job before the runner attempts to run `git init` and `git fetch` to
demonstrates how you might use a pre-clone step to seed the build
directory.
NOTE:
The `CI_PRE_CLONE_SCRIPT` variable does not work on Windows runners.
## `config.toml`
The full contents of our `config.toml` are:
NOTE:
Settings that are not public are shown as `X`.
**Google Cloud Platform**
```toml
concurrent=X
check_interval=1
metrics_server="X"
sentry_dsn="X"
[[runners]]
name="docker-auto-scale"
request_concurrency=X
url="https://gitlab.com/"
token="SHARED_RUNNER_TOKEN"
pre_clone_script="eval \"$CI_PRE_CLONE_SCRIPT\""
executor="docker+machine"
environment=[
"DOCKER_DRIVER=overlay2",
"DOCKER_TLS_CERTDIR="
]
limit=X
[runners.docker]
image="ruby:2.5"
privileged=true
volumes=[
"/certs/client",
"/dummy-sys-class-dmi-id:/sys/class/dmi/id:ro"# Make kaniko builds work on GCP.
]
[runners.machine]
IdleCount=50
IdleTime=3600
MaxBuilds=1# For security reasons we delete the VM after job has finished so it's not reused.
MachineName="srm-%s"
MachineDriver="google"
MachineOptions=[
"google-project=PROJECT",
"google-disk-size=25",
"google-machine-type=n1-standard-1",
"google-username=core",
"google-tags=gitlab-com,srm",
"google-use-internal-ip",
"google-zone=us-east1-d",
"engine-opt=mtu=1460",# Set MTU for container interface, for more information check https://gitlab.com/gitlab-org/gitlab-runner/-/issues/3214#note_82892928
"engine-opt=ipv6",# This will create IPv6 interfaces in the containers.
"engine-opt=fixed-cidr-v6=fc00::/7",
"google-operation-backoff-initial-interval=2"# Custom flag from forked docker-machine, for more information check https://github.com/docker/machine/pull/4600
info:To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments
---
# VM instances and images for Build Cloud for macOS **(FREE)**
When you use the Build Cloud for macOS:
- 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.
## VM types
The virtual machine where your job runs has `sudo` access with no password.
For the Beta, there is only one available machine type, `gbc-macos-large`.
| Instance type | vCPUS | Memory (GB) |
| --------- | --- | ------- |
| `gbc-macos-large` | 4 | 10 |
## VM images
You can execute your build on one of the following images.
You specify this image in your `.gitlab-ci.yml` file.
Each image is running a specific version of macOS and Xcode.
- Additional details on the support policy and image update release process are documented
[in this project](https://gitlab.com/gitlab-org/ci-cd/shared-runners/images/macstadium/orka/-/blob/55bf59c8fa88712960afff2bf6ecc5daa879a8f5/docs/overview.md#os-images).
info:To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments
---
# Runner Cloud for macOS (Beta) **(FREE SAAS)**
The Runner Cloud for macOS Beta provides on-demand runners integrated with GitLab SaaS [CI/CD](../../../ci/index.md).
Use these runners to build, test, and deploy apps for the Apple ecosystem (macOS, iOS, tvOS). You can take advantage
of all the capabilities of the GitLab single DevOps platform and not have to manage or operate a
build environment.
Build Cloud runners for macOS are in [Beta](https://about.gitlab.com/handbook/product/gitlab-the-product/#beta)
and shouldn't be relied upon for mission-critical production jobs.
## Quickstart
To start using Build Cloud for macOS Beta, you must submit an access request [issue](https://gitlab.com/gitlab-com/macos-buildcloud-runners-beta/-/issues/new?issuable_template=beta_access_request). After your
access has been granted and your build environment configured, you must configure your
`.gitlab-ci.yml` pipeline file:
1. Add a `.gitlab-ci.yml` file to your project repository.
1. Specify the [image](macos/environment.md#vm-images) you want to use.
1. Commit a change to your repository.
The runners automatically run your build.
## Example `.gitlab-ci.yml` file
The following sample `.gitlab-ci.yml` file shows how to start using the runners for macOS:
```yaml
.macos_buildcloud_runners:
tags:
-shared-macos-amd64
image:macos-11-xcode-12
stages:
-build
-test
before_script:
-echo "started by ${GITLAB_USER_NAME}"
build:
extends:
-.macos_buildcloud_runners
stage:build
script:
-echo "running scripts in the build job"
test:
extends:
-.macos_buildcloud_runners
stage:test
script:
-echo "running scripts in the test job"
```
NOTE:
During the Beta period, the architecture of this solution will change. Rather than the jobs running on a specific VM instance, they will run on an ephemeral VM instance that is created by an autoscaling instance, known as the Runner Manager. We will notify all Beta participants of any downtime required to do this work.
info:To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments
---
# Runner Cloud for Windows (beta) **(FREE)**
Runner Cloud runners for Windows are in [beta](https://about.gitlab.com/handbook/product/gitlab-the-product/#beta)
and shouldn't be used for production workloads.
During this beta period, the [shared runner pipeline quota](../../../user/admin_area/settings/continuous_integration.md#shared-runners-pipeline-minutes-quota)
applies for groups and projects in the same manner as Linux runners. This may
change when the beta period ends, as discussed in this [related issue](https://gitlab.com/gitlab-org/gitlab/-/issues/30834).
Windows runners on GitLab.com autoscale by launching virtual machines on
developed by GitLab for the [custom executor](https://docs.gitlab.com/runner/executors/custom.html).
Windows runners execute your CI/CD jobs on `n1-standard-2` instances with
2 vCPUs and 7.5 GB RAM. You can find a full list of available Windows packages in
the [package documentation](https://gitlab.com/gitlab-org/ci-cd/shared-runners/images/gcp/windows-containers/blob/main/cookbooks/preinstalled-software/README.md).
We want to keep iterating to get Windows runners in a stable state and
