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. CI runners on Aspect Enterprise covers how they work, what they add and how to configure them.
Two senses of “self-hosted” meet here. Workflows runners are self-hosted runners in your CI provider’s sense: machines 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.