> ## Documentation Index
> Fetch the complete documentation index at: https://site.aspect.build/llms.txt
> Use this file to discover all available pages before exploring further.

# CI runners

> Persistent, NVMe-backed self-hosted CI runners from Aspect Workflows that keep Bazel's output base warm across jobs for faster CI builds.

A CI runner is the machine your CI provider hands a job to: it checks out your repository and runs the pipeline's steps. GitHub Actions' `ubuntu-latest`, a Buildkite agent and a GitLab runner are all runners, and most start every job from an empty disk, so Bazel starts cold every time.

Aspect Workflows managed CI runners are auto-scaling runners built for Bazel, for GitHub Actions, Buildkite, GitLab and CircleCI: Linux VMs (x86, Arm, GPU) on any AWS or GCP instance type, in runner groups registered with your CI provider.

You can also bring your own runners on any CI system, such as Jenkins, Bamboo, Travis CI or Bitbucket Pipelines, and use the remote cache, remote execution and Build Results UI from them.

## What makes them different

**They stay warm.** A Workflows runner is a persistent VM that takes jobs in sequence rather than terminating after one. The Bazel server keeps running between jobs, so the analysis cache carries over in memory, and the output base stays on local NVMe, striped across the instance's drives.

**New runners start warm too.** With [warming](/docs/aspect-workflows/enterprise/ci-runners/warming) turned on, a new runner's first job starts with external repositories fetched and repository rules already run.

**You pick the hardware.** Each [runner group](/docs/aspect-workflows/enterprise/ci-runners/runner-groups) sets its instance type, architecture, CPU, memory, GPUs and NVMe storage. Several groups run side by side, so x86, Arm and GPU jobs each land on the machines they need. Docker-based tests work on the runners.

**You own the image.** On Aspect Enterprise, runners are VMs booted from a machine image you can customize fully, so system packages and tools your jobs need are there from the start.

**They scale to zero.** Each group scales on queue depth, between a minimum and a maximum you set, and down to zero when there's no work.

<Note>
  Two senses of "self-hosted" meet on this page. Workflows runners are **self-hosted
  runners** in your CI provider's sense: machines you supply, registered with GitHub
  Actions, Buildkite, GitLab or CircleCI, as opposed to that provider's own hosted runners.
  That's true on every [Aspect Enterprise deployment](/docs/aspect-workflows/enterprise/overview), including
  deployments hosted by Aspect. Whether the *deployment* is self-hosted is a separate question
  about whose cloud account it runs in.
</Note>

## Where they're available

CI runners are available on Aspect Enterprise today and are coming soon to Aspect Cloud.

<Tip>
  Interested in early access to Aspect Cloud CI runners and remote execution, coming in early 2027? [Join the early access list](/contact?topic=early-access).
</Tip>

|                                                                                                      | Today                                                    | Coming soon                                    |
| ---------------------------------------------------------------------------------------------------- | -------------------------------------------------------- | ---------------------------------------------- |
| **[Aspect Enterprise](/docs/aspect-workflows/enterprise/overview)**, hosted by Aspect or self-hosted | Linux VMs (x86, Arm, GPU) with fully customizable images | macOS runners and OCI image-based runners      |
| **[Aspect Cloud](/docs/aspect-workflows/cloud/overview)**                                            | —                                                        | Linux runners, customized through an OCI image |

Until then, an Aspect Cloud pipeline runs on the runners you already have and reaches the cache and build event service through the setup step. See [Aspect Cloud CI setup](/docs/aspect-workflows/cloud/ci-setup).

## Using them from your pipeline

* **Target a runner group** with your CI provider's own selector: `runs-on:` labels, a Buildkite queue, GitLab tags or a CircleCI resource class. See [Runner groups](/docs/aspect-workflows/enterprise/ci-runners/runner-groups).
* **Add the setup step** to any job that calls `bazel` directly. See [the setup step](/docs/aspect-workflows/enterprise/connect/ci-setup#the-setup-step).
* **Schedule a warming job** if the group has warming turned on. See [Warming](/docs/aspect-workflows/enterprise/ci-runners/warming).

Each CI provider's [pipeline page](/docs/aspect-workflows/enterprise/connect/ci-setup#where-each-integration-lives) has examples for vanilla `bazel`, non-Bazel jobs and Aspect CLI tasks.

{!user.loggedIn ? (
<Info>
The Terraform and infrastructure reference for self-hosted Aspect Enterprise deployments is available to customers. <a href="/login?redirect=%2Fdocs%2Faspect-workflows%2Fplatform%2Ffeatures%2Fci-runners">Log in</a> to read it, or ask an admin in your organization to invite you in <a href="https://app.aspect.build/settings/org/users">Aspect settings</a>.
<br /><br />
<a href="https://signup.aspect.build/">Sign up free</a> for Aspect Cloud, or <a href="/contact">talk to us</a> about a <a href="/trial">30-day trial of Aspect Enterprise</a>.
</Info>
) : !user.tenantMetadata?.docsGroups?.includes('workflows-subscriber') ? (
<Info>
The Terraform and infrastructure reference for self-hosted Aspect Enterprise deployments is available to customers. If your organization is one, contact Aspect support for access.
<br /><br />
Not a customer yet? <a href="/contact">Talk to us</a> about a <a href="/trial">30-day trial of Aspect Enterprise</a>.
</Info>
) : null}