Skip to main content
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 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 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.
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, including deployments hosted by Aspect. Whether the deployment is self-hosted is a separate question about whose cloud account it runs in.

​
Where they’re available

CI runners are available on Aspect Enterprise today and are coming soon to Aspect Cloud.
Interested in early access to Aspect Cloud CI runners and remote execution, coming in early 2027? Join the early access list.
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.

​
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.
  • Add the setup step to any job that calls bazel directly. See the setup step.
  • Schedule a warming job if the group has warming turned on. See Warming.
Each CI provider’s pipeline page has examples for vanilla bazel, non-Bazel jobs and Aspect CLI tasks.