Skip to main content
The remote cache and remote execution implement the standard Remote Execution API (REv2), so any build system that speaks it can use them, not only Bazel. CI runners run any job, whatever builds it. Warming and the Build Results UI read Bazel’s own output and work with Bazel only. Remote execution is available on Aspect Enterprise today and is coming soon to Aspect Cloud.

​
What each column means

  • Remote cache and remote execution. The client reads and writes action results and runs actions on the worker fleet over REv2. The AOSP benchmark is a non-Bazel build on Aspect remote execution.
  • CI runners. A Workflows runner is a persistent VM that takes jobs in sequence, so whatever a build leaves on the runner’s disk is still there for the next job on it. That keeps any build system’s local state warm between jobs.
  • Warming. Warming archives a runner’s Bazel repository cache and output base and restores it on new runners, so a runner’s first job doesn’t start cold. It works only with Bazel’s on-disk layout.
  • Build Results UI. The Build Results UI, its REST API and its MCP server are built from Bazel’s Build Event Protocol, which other build systems don’t send.
Selective delivery and the Aspect CLI tasks also work with Bazel only.

​
Connecting a build system other than Bazel

Point the build system’s remote cache and remote execution settings at your deployment’s endpoints. Each project documents its own settings: The Bazel-specific setup pages, Aspect Cloud local setup and Aspect Enterprise local setup, don’t apply to these clients. Talk to us for the endpoints and credentials to use from another build system.