Configure Sbt Remote Cache
Last updated: August 19, 2026
What is Sbt Remote Cache
sbt 2.0.0 introduced a hybrid local and remote caching system that can reuse cached task results and file outputs when a task's tracked inputs have not changed.
By default, cacheable tasks can reuse results through sbt local disk cache. Configuring Sbt Remote Cache allows to share the cache across machines.
Importantly: like Gradle and Bazel, Sbt also caches Test runs, this allows teams to save significant CI time and cost.
sbt 2.x comes with built-in Bazel-compatible gRPC REAPI Remote Cache implementation. Under the hood, sbt calls gRPC Remote Cache as per Bazel Remote Execution API spec:
- Action Cache (AC) — stores cached task result metadata keyed by
sbt'scached-taskdigest - Content-Addressable Storage (CAS) — stores output files and other content by digest
- ByteStream — transfers larger CAS blobs over gRPC
BuildFetch Cache implements gRPC REAPI APIs natively, identifies sbt as a dedicated API client, and maintains a comprehensive end-to-end integration test suite to ensure full sbt Remote Cache compatibility across versions and workloads.
Schematic example: say a first run of Compile / compile misses both reusable local state and the shared Remote Cache, spends time compiling a module, then stores its cached task result and output blobs:
Compile / compile
Tracked task inputs
+-----------------------------+
| source / file hashes |
| dependent task values |
| relevant settings |
| compiler inputs |
| ... |
+-------------+---------------+
|
v
Compute cached-task digest
|
v
+-----------------------------+
| BuildFetch Remote Cache |
| task key: a3f9...c2 |
| status: MISS |
+-------------+---------------+
|
v
Run task locally
|
v
Result + declared file outputs
|
v
Store cache result + CAS blobsLater builds with the same tracked inputs compute the same cached-task key and can restore the task result and file outputs from the shared cache instead of running the task again:
Compile / compile (same inputs)
Tracked inputs unchanged
sources · dependencies · settings · ...
|
v
Same cached-task digest
|
v
+-----------------------------+
| BuildFetch Remote Cache |
| task key: a3f9...c2 |
| status: HIT |
+-------------+---------------+
|
v
Restore cached task result
+ declared file outputs
|
v
Skip local task execution
Build graph continues soonerBuildFetch Cache is specifically optimized to serve Action Cache metadata and CAS blobs quickly through its NVMe → SSD tiered storage system.
BuildFetch Cache correctly preserves AC → CAS references when entries are evicted via LRU GC, avoiding the failure mode where an Action Cache entry is still present but one or more referenced CAS blobs have already been removed.
When Sbt Remote Cache helps most
Sbt Remote Cache is especially valuable in ephemeral, autoscalable CI environments where build agents are frequently recreated without durable local disk state.
An actively developed repository can continuously warm the shared Remote Cache from CI as the codebase evolves. Engineer workstations, CI jobs, and AI agent environments then reuse compatible task results rather than spending time to execute tasks locally on every machine.
Configure Sbt Remote Cache
Before setting up Remote Cache, ensure you have created a BuildFetch Project and Token(s).
Official sbt 2.x Remote Cache documentation: https://www.scala-sbt.org/2.x/docs/en/reference/remote-cache-setup.html
The configuration on this page is specifically for sbt 2.x; sbt 1.x used a different Remote Cache mechanism.
Generate Tokens
We recommend starting with a cache:readwrite Token for CI and other trusted, reproducible environments that should populate the shared Sbt Remote Cache.
Generating cache:readwrite Tokens requires Project/Org Admin scope.
For Open Source Projects, we do not recommend storing Remote Cache Tokens as publicly accessible, doing so could result in unintended exhaustion of monthly Project limits.
Enable sbt Remote Cache
sbt 2.x requires its Remote Cache plugin to be enabled explicitly.
Add the following to project/plugins.sbt:
addRemoteCachePluginThis enables the settings used by sbt's built-in gRPC Remote Cache client.
Configure BuildFetch Remote Cache
From the Project Cache Setup tab, take the HTTPS project cache host — for example cache.region.buildfetch.com — together with your Project ID and generated Token.
Set these environment variables in CI or another secret-managed environment:
export BUILDFETCH_SBT_REMOTE_CACHE_HOST="cache.region.buildfetch.com"
export BUILDFETCH_SBT_PROJECT_ID="project-id"
export BUILDFETCH_SBT_REMOTE_CACHE_TOKEN="..."Then configure build.sbt:
val buildfetchCacheHost =
sys.env("BUILDFETCH_SBT_REMOTE_CACHE_HOST")
val buildfetchProjectId =
sys.env("BUILDFETCH_SBT_PROJECT_ID")
val buildfetchToken =
sys.env("BUILDFETCH_SBT_REMOTE_CACHE_TOKEN")
ThisBuild / allowMachinePath := false
Global / remoteCache := Some(
uri(s"grpcs://$buildfetchCacheHost/reapi/sbt/$buildfetchProjectId")
)
Global / remoteCacheHeaders +=
s"authorization=Bearer $buildfetchToken"The settings above configure:
BUILDFETCH_SBT_REMOTE_CACHE_HOST— the BuildFetch Cache hostname, without protocol prefixBUILDFETCH_SBT_PROJECT_ID— namespace for Remote Cache isolationBUILDFETCH_SBT_REMOTE_CACHE_TOKEN— Bearer token used as gRPC metadatagrpcs://— TLS-enabled gRPC Remote Cache scheme/reapi/sbt/<PROJECT_ID>— REAPI instance name for thissbtprojectallowMachinePath := false— improves cache portability across machines
With the configuration loaded, use sbt normally:
sbt compileor:
sbt testCacheable tasks participate in sbt's caching system automatically. No BuildFetch-specific logic is required.