Skip to main content
Try these on the runners themselves. They’re independent, and each one changes speed and cost, so measure after each. For the build running on them, see Optimizing your Bazel build.

​
Tune instance type size

The right instance size depends on your workload’s parallelism and memory profile. An undersized machine serializes actions; an oversized one pays for idle cores.
  1. Review available instance types from your cloud provider, noting regional availability.
  2. Use a binary search: double or halve the instance size and measure wall-clock CI time against cost. Stop when the speed gain no longer justifies the cost increase.
  3. Evaluate Arm instances. They typically offer better price-to-performance for CPU-bound workloads.
A resize replaces the running instances and their local output bases, so the first builds afterwards run cold. On a self-hosted deployment, instance types are runner group settings in Terraform; see the AWS and GCP references.

​
Tune runner group scaling

These settings control how a runner group scales. On a deployment hosted by Aspect, ask for the values you want; on a self-hosted deployment, they’re runner group settings in Terraform:
  • min_runners: the minimum number of runners always allocated. Set this to absorb burst traffic without a cold start.
  • max_runners: the upper bound. Set this based on your peak concurrent job count and budget.
  • min_free_runners: the number of idle runners to keep ready. A value of 1–2 removes the wait for a new runner to provision when several jobs arrive at once.

​
Configure runner warming

A scheduled aspect ci warming job runs bazel build --nobuild over your warming targets, then archives the runner’s repository cache and output base. A new runner restores the archive before its first job, so that job starts with external repositories fetched and repository rules already run. See Warming for configuration details.