Skip to main content
Aspect Workflows provides auto-scaling, self-hosted CI runners tuned for optimal Bazel performance. They register automatically with the CI system you already use (GitHub Actions, CircleCI, GitLab, or Buildkite), run on the exact hardware you choose, and cost a fraction of provider-hosted runners.

​
Tuned for Bazel

Generic cloud VMs, like GitHub Actions’ ubuntu-latest, provision a fresh, empty filesystem for every job. Bazel’s output base is gone. Every action must either hit the remote cache or be re-executed from scratch. Even with a warm remote cache, the round-trip cost of fetching outputs adds up, and the Bazel JVM starts cold with no in-process state. Aspect’s CI runners are designed around Bazel’s specific requirements. They are persistent VMs that accept multiple jobs in sequence rather than terminating after one. The Bazel JVM stays running between jobs, so in-memory state, including the analysis cache, carries over. Each runner mounts a RAID0 array across multiple NVMe drives to maximize filesystem IOPS, which matters for Bazel’s heavily file-intensive output base operations. When a runner starts up, it can optionally be pre-warmed from an on-disk archive: Bazel’s fetch phase is already done, with repository rule fetches, extracted external dependencies, and a populated output base all restored before the first job runs. This eliminates the cold-start penalty for new machines joining the pool: even a fresh runner’s first job skips the dependency downloads. Cached builds routinely complete in under one minute.

​
Your hardware, your choice

Runners automatically register with your CI provider as self-hosted runners, so your pipelines target them like any other runner label. And because they are your machines, you choose the exact configuration: instance type, architecture, CPU, memory, GPUs, and NVMe storage. Multiple runner groups are supported, so different CI jobs run on different machine types: x86, Arm, and GPU instances side by side. If your tests need hardware your CI provider doesn’t offer, like the GPU instance types AI teams need, runner groups are how you get it. Docker-based tests are fully supported, on runners and on remote execution workers alike.

​
Auto-scaling, down to zero

The runner pool auto-scales based on queue depth and scales back down to zero when there is no work, so you are not paying for idle machines between CI runs.

​
Health checks, not babysitting

The classic foot-gun with persistent runners is a machine that drifts into a bad state, stays in the pool, and fails every job it picks up until a human notices and drains it. Workflows runners take care of this themselves. Built-in health checks keep every runner healthy, and a runner that hits an unrecoverable failure is automatically taken out of service before it accepts another job. The pool scales replacement capacity as usual, so one bad machine never turns into a string of red builds, and nobody gets paged to go find it.

​
A fraction of provider-hosted cost

Self-hosted Workflows CI runners are substantially cheaper than the per-minute pricing on GitHub Actions, Buildkite, CircleCI, and GitLab provider-hosted runners: typically 40–80% lower CI compute spend, with the gap widening on larger instance types. Because the runners live in your own AWS or GCP account, any committed-use discounts, savings plans, or enterprise agreements you already have with your cloud provider apply directly.
To learn more about CI runners, see the Estimating the effort to build a Bazel CI/CD article.