Configuration options - Aspect Build

This page is for teams on an Aspect Enterprise deployment hosted by Aspect, where you decide the configuration and Aspect applies it. It lists the common options and which of your own Bazel or CI settings each one has to line up with. Any other setting of the Aspect Workflows Terraform module can be changed on request too. To request a change, see Requesting changes.

Runner groups

A runner group is a pool of identically configured machines that register with your CI provider under one queue or label set. Most deployments have several, because different jobs want different hardware.

Option	What it controls	Lines up with
Name	The queue or label your CI jobs target	Your pipeline’s `runs-on:` / `queue:` / `tags:` / `resource_class:`. See Targeting runner groups from CI
Instance type	vCPU, memory, architecture, GPUs, local NVMe	Your build’s memory ceiling, and any test that needs a GPU or Arm
Minimum size	Machines kept running when the queue is empty	How fast the first job of the morning starts
Maximum size	The ceiling the group scales to	Peak concurrency of your pipeline
Idle runners	Free runners kept ready beyond those running jobs	How many jobs arrive at once
Warming set	Which warming archive and caches the group restores	Your scheduled `aspect ci warming` job, which sets the targets it warms. See Warming
Disk size	NVMe available to the Bazel output base	Repository size plus output base growth between reclaims

A group scales to zero when idle unless you set a minimum, so a group kept for occasional heavy jobs uses no compute while nothing needs it.

A common early adjustment is splitting one large group into two: a small, always-warm group for PR jobs, and a larger group that scales from zero for nightly and release builds. It shortens PR feedback without paying for idle capacity.

Remote execution platforms

A remote execution platform is a worker configuration: a container image, an instance type, and the set of platform properties it advertises.

Option	What it controls	Lines up with
Container image	The toolchain available to remote actions	Your Bazel toolchains and any non-hermetic system dependency your actions need
Platform properties	What the worker advertises, including `Pool`	Your Bazel `platform` targets’ `exec_properties`, which must match exactly. See Targeting remote execution worker pools
Instance type	vCPU, memory, NVMe, GPUs per worker	The heaviest action you expect to run there
Concurrency	Actions executed in parallel per worker	vCPU per worker against per-action CPU use
Minimum and maximum workers	Fleet floor and ceiling	Peak parallelism of `bazel build`
Operating system	Linux, or macOS (EC2 Mac on AWS, or Macs you provide)	Whether you build iOS or macOS targets remotely

Platform matching in REv2 is whole-set equality, not a subset match. A worker advertising OSFamily, container-image and Pool is only reachable by a client requesting exactly those three properties with exactly those values. It’s the most common reason a newly added pool sits idle, and it’s why the platform properties Aspect gives you need to land verbatim in your Bazel exec platform.

Warming

New runners restore from a warming archive so that a first job doesn’t pay to fetch external repositories and run repository rules. Aspect configures which groups are warmed and which warming set each restores. Which targets are warmed, and how often, is up to the aspect ci warming job in your own pipeline. Cover your common build targets rather than everything: the archive has to be downloaded and unpacked before the runner takes work, so there is a point past which a bigger archive costs more than it saves. See Warming.

Retention

What	Adjustable	Notes
Remote cache	✓	Longer retention raises hit rate on infrequently-touched targets and raises stored bytes
Build event history	✓	How far back the Build Results UI can show an invocation

Endpoints and access

Option	Default	Alternative
Endpoint domain	Aspect’s domain	A subdomain you delegate to Aspect
Sign-in	Aspect sign-in	SSO through Aspect sign-in, connected to your identity provider; or your own identity provider in place of Aspect sign-in. See the consequences for CI
User provisioning	Invites in Aspect settings	SCIM provisioning from your directory, with Aspect sign-in. With your own identity provider, users and groups are managed there
Network path	Authenticated public endpoints	Private endpoints via AWS PrivateLink or GCP Private Service Connect
Build Results UI access	Everyone who can sign in	Scoped by groups in your own identity provider, where you bring one

What isn’t adjustable here

Some things are properties of a deployment hosted by Aspect rather than options within it. If you need one of these, you want self-hosted:

The cloud account the deployment runs in, and direct access to it.
VPC peering with your own networks.
Running the deployment in a specific region or partition Aspect doesn’t operate in, including GovCloud.

​Runner groups

​Remote execution platforms

​Warming

​Retention

​Endpoints and access

​What isn’t adjustable here

Runner groups

Remote execution platforms

Warming

Retention

Endpoints and access

What isn’t adjustable here