Remote execution
Bazel sends each action to a fleet of workers instead of running it on one machine, so a build runs as many actions at once as the fleet has slots. The fleet implements the Remote Execution API v2, which Bazel, Buck2, Pants and Reclient all speak.- Worker pools you define. Each pool has its own container image, instance type and platform properties: Linux on x86 or Arm, high-memory, GPU, macOS, and workers on your own hardware. Bazel routes each action to a pool by its exec platform.
- Scaling you set. Pools scale on queue depth between a floor and a ceiling, down to zero when idle; on AWS they can also raise the floor on a schedule ahead of the working day.
Remote cache
The cache sits on the deployment’s private network, next to the remote execution workers and CI runners. A cache tier serves it from object storage: S3 Express on AWS, Cloud Storage on GCP, so capacity follows the bucket and you size throughput rather than disks. Retention is yours to set. Remote cache on Aspect Enterprise has the detail.The external endpoint
CI runners in the deployment reach the cache and remote execution privately. Developer machines, and CI you run anywhere else, reach them through the external endpoint,remote.<your-domain>, signed in through the deployment’s identity provider. The endpoint either shares CI’s cache and executor fleet or runs its own, sized apart from CI’s. See the external endpoint.
CI runners
Aspect Workflows CI runners are persistent, auto-scaling runners that keep Bazel warm between jobs, for GitHub Actions, Buildkite, GitLab and CircleCI. We recommend running CI on them: they sit in the same VPC as the cache and the remote execution fleet, so the heaviest traffic in a build stays on the private network. CI runners on Aspect Enterprise covers how they work and how to configure them. You can also bring your own self-hosted runners, for the CI system of your choice. They can reach the remote cache, remote execution and the build event backend inside the deployment’s VPC, from your own VPC over AWS PrivateLink, GCP Private Service Connect or VPC peering, or through the external endpoint. See .Build Results UI
Included with Aspect Enterprise. Every build and test from CI and developer machines, with streaming logs, timing profiles and critical paths, flaky-test tracking, artifacts, build comparison and target trends, plus an API and an MCP server. See Build Results UI.What Aspect does
- Stands it up: the account or project setup, network and every service.
- Runs it: monitoring, alerting, capacity, certificates, and backups of the build event database. Standard Aspect Enterprise agreements include 24/7 on-call and a 99.9% uptime SLA.
- Upgrades it, in scheduled windows, with any client-side steps sent ahead.
- Supports your team: a Slack channel with Aspect’s Bazel experts and a dedicated support engineer.
Pricing
See how Aspect Enterprise is priced, and estimating capacity for a first estimate of the vCPUs your deployment needs.Hosted, self-hosted or on-prem
Hosted by Aspect
In an isolated account in Aspect’s cloud. Aspect provisions, monitors, upgrades and restores it. You configure runner groups and remote execution pools by asking, not by applying Terraform.
Self-hosted
In your own AWS account or GCP project. Source, secrets and artifacts stay in your network. Covers air-gapped and GovCloud.
On-prem Coming soon
On your own hardware, deployed with a Helm chart.
Azure and Oracle Cloud are planned. Contact us if you’re interested.
Identity options
Network options
Getting started
1
Evaluate it on your own repository
A 30-day trial of Aspect Enterprise measures your build on
remote execution and the remote cache against your current CI, on the same commits.
Talk to us to start one.
2
Stand it up
Hosted by Aspect: Aspect
provisions it from what you provide.
Self-hosted: deployed by Terraform into your AWS
account or GCP project, by Aspect or your team.
3
Connect developers and pipelines
for laptops, and
for pipelines, on Workflows
runners or your own.