> ## Documentation Index
> Fetch the complete documentation index at: https://site.aspect.build/llms.txt
> Use this file to discover all available pages before exploring further.
# Configuration options
> What you can configure on an Aspect Enterprise deployment hosted by Aspect (runner groups, remote execution platforms, warming sets, retention and endpoints) and how each option lines up with your Bazel and CI configuration.
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](/docs/aspect-workflows/enterprise/hosted/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](/docs/aspect-workflows/enterprise/ci-runners/runner-groups) |
| **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](/docs/aspect-workflows/enterprise/ci-runners/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](/docs/aspect-workflows/platform/guides/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](/docs/aspect-workflows/enterprise/ci-runners/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](/docs/aspect-workflows/enterprise/connect/ci-setup#if-the-deployment-uses-your-own-identity-provider) |
| **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](/docs/aspect-workflows/enterprise/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.