Configure Sccache Remote Storage

What is Sccache

Sccacheis a compiler wrapper that speeds up builds by caching its work and reusing it, even on another machine.

Sccache includes support for caching the compilation of Rust, Assembler, C/C++, NVIDIA CUDA through nvcc and clang, and AMD ROCm HIP for AI and ML.

https://github.com/mozilla/sccache#sccache---shared-compilation-cache

Sccache can use both Local disk cache and Remote Storage. Local cache helps a single machine; Remote storage lets teams share compilation outputs across machines: CI & developer environments.

For each compiler invocation, Sccache quickly computes a cache key from compiler identity, flags, source inputs, and environment variables, then queries its Local and Remote cache.

On a Cache Hit Sccache reuses previously stored output (fast) and skips compiler invocation. On a Cache Miss Sccache runs the compiler locally (slow), stores the outputs in shared cache and makes them available for later builds.

Schematic example: say a first build of the libs/parser module misses the cache, spends about 1 minute compiling, and stores each resulting artifact under its computed key:

libs/parser  (module)

  Inputs
  +----------------------+
  | parser.rs/cpp        |
  | lexer.rs/cpp         |
  | ast.rs/cpp           |
  | token.rs/cpp         |
  | ...                  |
  | headers, flags, ...  |
  | compiler identity    |
  +----------+-----------+
             |
             v
  Sccache client -> local server
             |
             v
  Compute cache key per unit
             |
             v
  +----------------------+
  | Local cache miss     |
  | remote storage miss  |
  +----------+-----------+
             |
             v
  Compile module (~1m)
             |
             v
  Outputs: parser.o / .rlib
             |
             v
  Store artifacts under key

Later builds with the same inputs reuse those entries. Sccache computes the same cache keys, finds a local cache hit when possible, otherwise hits the BuildFetch remote storage, and restores the module outputs in seconds instead of recompiling.

libs/parser  (same inputs)

  Inputs unchanged
  parser.rs/cpp · lexer.rs/cpp · ast.rs/cpp · ...
             |
             v
  Same cache key per unit
             |
             v
  +----------------------+
  | Sccache              |
  | local cache: HIT     |
  | remote: fallback     |
  +----------+-----------+
             |
             v
  Restore outputs (~100ms)
             |
             v
  Skip ~1m compile
  Build continues sooner

Share Sccache Between Machines

Remote Sccache Storage

For Sccache outputs to be shared across machines, WebDAV remote storage can be configured as one of the natively supported protocol. Local cache only helps on a single machine.

BuildFetch Cache natively supports Sccache WebDAV backend and acts as an extremely fast shared remote cache for CI, engineers, and AI agents.

Remote Sccache storage lets teams share compiled outputs across engineer workstations, CI, and AI agent environments.

CI, having a more reproducible and controlled environment, typically both reads from and writes to the shared remote storage. Engineers and AI agents read those outputs without uploading new entries.

That keeps the cache warm from reproducible CI builds while reducing repeated compilation on other machines.

Sccache reuses an artifact only when compiler inputs and relevant configuration match. Keep compiler versions, flags, source inputs, and other build environment details consistent when sharing a cache.

Instead of recompiling the same translation units on every machine, Sccache restores cached artifacts, which turns builds that took minutes into cached builds that finish in seconds when hit rates are high.

Cached Sccache Build Example

First build, where there is no shared cache yet, ie takes about 10 minutes:

$ export RUSTC_WRAPPER=sccache
$ cargo build --release

   Compiling parser v0.1.0
   Compiling lexer v0.1.0
   Compiling ast v0.1.0
...
   Finished release [optimized] target(s) in 10m 4s

$ sccache --show-stats
Cache hits:               0
Cache misses:           842
Cacheable calls:        842

After CI populated Sccache Remote Storage, even a clean rebuild on another machine can resolve up to 100% of slow and resource-heavy compiles from cache:

$ export RUSTC_WRAPPER=sccache
$ cargo clean && cargo build --release

   Compiling parser v0.1.0
   Compiling lexer v0.1.0
   Compiling ast v0.1.0
...
   Finished release [optimized] target(s) in 12.3s

$ sccache --show-stats
Cache hits:             831
Cache misses:            11
Cacheable calls:        842

When Sccache helps most

Sccache remote storage is especially valuable in ephemeral, autoscalable CI environments, where CI agents are often recreated without durable local disk state.

It also helps in actively developed projects where CI continuously warms the shared Sccache remote storage for the whole team as the codebase evolves with each commit.

Enable Sccache

Install Sccache, then route compiler invocations through it. For Rust builds, the usual setup is setting RUSTC_WRAPPER=sccache. For other toolchains, configure your build system to invoke the compiler through Sccache.

Once compiles run through Sccache, the local cache works automatically. To share results across machines, configure Sccache remote storage with BuildFetch Cache.

Configure Sccache Remote Storage

Before setting up remote cache, ensure you have created Project and Token(s).

Official Sccache configuration documentation: https://github.com/mozilla/sccache/blob/main/docs/Configuration.md.

Sccache remote storage is configured with environment variables, or the equivalent keys in sccache.conf. BuildFetch projects use SCCACHE_WEBDAV_ENDPOINT, SCCACHE_WEBDAV_KEY_PREFIX, SCCACHE_WEBDAV_USERNAME, and SCCACHE_WEBDAV_PASSWORD as shown on the Project Cache Setup tab.

The BuildFetch Project Cache Setup tab generates the authenticated WebDAV endpoint and the project key prefix, so your Sccache environment can point to the correct remote storage path directly.

Settings and credentials

Generate Tokens

We recommend generating a cache:readwrite Token for CI and cache:readonly Token(s) for developer machines.

Generally, there are two ways to manage developer Tokens:

• For simpler setups, issuing and rotating a single cache:readonly Token could be sufficient.
• For precise access control, each developer should register in BuildFetch, then issue and rotate their own individual cache:readonly Token(s).

Generating cache:readwrite Tokens requires Project/Org Admin scope.

For Open Source Projects, we recommend not storing a cache:readonly Token in publicly accessible code because it could lead to misuse and unintended exhaustion of monthly Project limits.

Configure Sccache with the environment variables below before running your builds. Replace the placeholder values with the remote cache URL and Project ID shown in the Project Cache Setup tab:

export SCCACHE_WEBDAV_ENDPOINT="https://<project-cluster-cache-public-url>/<project-id>/sccache/"
export SCCACHE_WEBDAV_KEY_PREFIX="<project-id>"
export SCCACHE_WEBDAV_USERNAME="token-auth"
export SCCACHE_WEBDAV_PASSWORD="<generated-token>"

Keep the generated Token in your CI secret store or local credential environment; do not commit it to source control. If you want read-only developer access, use a cache:readonly Token in SCCACHE_WEBDAV_PASSWORD.

Export these variables in the shell or CI environment used for compilation, then run your build through Sccache. Use statistics to confirm the cache is active:

$ export RUSTC_WRAPPER=sccache
$ sccache --zero-stats
$ cargo build --release
$ sccache --show-stats