> ## 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.

# Remote cache

> A Bazel remote cache for CI and developer machines: one shared cache on Aspect Cloud, or an isolated cache of your own on Aspect Enterprise.

Every action Bazel runs, a compile, a link, a test, is keyed by a hash of its inputs, its command line and its environment. Bazel keeps the result against that key, so an action it has run before comes back from cache instead of running again.

By default, Bazel caches action results on your local machine. A **remote cache** moves that cache off the machine and shares it, so a result one machine computed is a cache hit on every other, including a fresh CI checkout.

## How it works

Before running an action, Bazel asks the remote cache whether that key already has a result. On a hit, it fetches the outputs and moves on. On a miss, it runs the action and uploads the result, so the next build that needs it gets a hit.

## Where it's available

The remote cache is available on Aspect Cloud and Aspect Enterprise.

|                                                                                              | Where the cache runs                                                                        | Get started                                                                                                                                                                         |
| -------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **[Aspect Cloud](/docs/aspect-workflows/cloud/overview)**                                    | Aspect's multi-tenant service, with your data scoped to your organization                   | [Local setup](/docs/aspect-workflows/cloud/local-setup) · [CI setup](/docs/aspect-workflows/cloud/ci-setup)                                                                         |
| **Aspect Enterprise, [hosted by Aspect](/docs/aspect-workflows/enterprise/hosted/overview)** | Your own deployment in Aspect's cloud, next to your CI runners and remote execution workers | [30-day trial of Aspect Enterprise](/trial) · [Local setup](/docs/aspect-workflows/enterprise/connect/local-setup) · [CI setup](/docs/aspect-workflows/enterprise/connect/ci-setup) |
| **Aspect Enterprise, [self-hosted](/docs/aspect-workflows/enterprise/self-hosted)**          | Your own deployment in your AWS account or GCP project, inside your VPC                     | [30-day trial of Aspect Enterprise](/trial) · [Local setup](/docs/aspect-workflows/enterprise/connect/local-setup) · [CI setup](/docs/aspect-workflows/enterprise/connect/ci-setup) |

**Who shares a cache:**

* **Aspect Cloud:** CI and developer machines use the same cache.
* **Aspect Enterprise:** the cache sits on the same private network as the runners and workers, so CI reads and writes never cross the internet. Developer machines and CI you run yourself reach the deployment through its [external endpoint](/docs/aspect-workflows/enterprise/connect/local-setup#the-external-endpoint), or privately over VPC peering. The external endpoint can share CI's cache, so a laptop gets CI's hits, or have storage of its own to keep developer traffic apart; that's a configuration choice for the deployment.

{user.loggedIn && user.tenantMetadata?.docsGroups?.includes('workflows-subscriber') ? (
<Info>
On a self-hosted Aspect Enterprise deployment, the cache is configured in Terraform. See <a href="/docs/aspect-workflows/enterprise/self-hosted/configuration/remote-cache">Remote cache configuration</a>.
</Info>
) : null}

## Who writes to the cache

On Aspect Cloud, and on an Aspect Enterprise deployment whose external endpoint shares CI's cache, developer machines and CI write to the same cache. For CI-only writes, set Bazel's `--noremote_upload_local_results` on developer machines, so a laptop reads CI's results without uploading its own. Put it in each developer's `~/.bazelrc`, which both vanilla `bazel` and Aspect CLI tasks read on a developer machine:

```bazel title="~/.bazelrc" theme={null}
build --noremote_upload_local_results
```

## Configuring your repository

The cache is a set of Bazel flags; your build rules don't change.

* **Aspect CLI tasks** take `--remote`, and on CI they connect to the cache without it.
* **Vanilla `bazel`** reads the flags from the rc that [`aspect setup bazelrc`](/docs/cli/tasks/setup_bazelrc) writes, on a developer machine or in the CI setup step.

### Build without the Bytes

Bazel 7 and later default to `--remote_download_toplevel`: Bazel downloads the outputs of the targets you asked for and leaves intermediate outputs in the cache. On CI, `--remote_download_minimal` downloads less: only what local actions need. Keep it off developer builds, where you want outputs on disk, by setting it under `build:ci` and running CI builds with `--config=ci`:

```bazel title=".bazelrc" theme={null}
build:ci --remote_download_minimal
```

## Seeing what it does

Every build that streams to the [Build Results UI](/docs/aspect-workflows/platform/features/webui) shows how many actions hit the cache and how many ran. [Compare](/docs/aspect-workflows/platform/features/webui#compare-two-builds) puts the cache hits of two invocations side by side and flags the likely cause when one misses where the other hit.

## Standard protocol

The cache implements the [Remote Execution API](https://github.com/bazelbuild/remote-apis) (REAPI) v2 over gRPC. Any build system that speaks it can use the cache, including:

* Bazel
* Buck2
* Pants
* reclient, used by Chromium and Android