Does BoringCache replace Go's build cache?

No. It plugs into Go's cache program interface so the go command can ask an external process for cache entries.

How is the build cache different from the module cache?

GOCACHE holds build results; GOMODCACHE holds downloaded module source. GOCACHEPROG shares build and test results, so a warm module download alone does not provide the same reuse.

Why can a Go test still run with a warm cache?

Go decides whether a test result can be reused. Changes to inputs, non-cacheable test flags, or running with -count=1 can require the test to run again.

Go build cache

Reuse Go build and test results on the next machine.

Connect the Go build cache to shared storage. Fresh runners and developer machines can reuse results when the Go command’s cache rules allow it.

Set up Go See the product

.boringcache.toml

workspace = "my-org/app"

[adapters.go]
tag = "go-cache"
command = ["go", "test", "./..."]

boringcache go

permissions:
  contents: read
  id-token: write

steps:
  - uses: boringcache/one@f0fb9b2d926a32b10c543e92093ba00c5a291b79 # v1.33.0
    with:
      mode: go
      trust-policy: auto
  - run: go test ./...

steps:
  - label: Build
    command: >
      boringcache ci run
      --oidc-provider buildkite
      -- boringcache go

build:
  timeout: 1h
  id_tokens:
    BORINGCACHE_OIDC_TOKEN:
      aud: urn:boringcache:workload
  script:
    - boringcache ci run --oidc-provider gitlab -- boringcache go

How BoringCache fits your build.

Compilation results

Share build results through GOCACHEPROG.

Eligible test results

Reuse completed tests when Go considers them cacheable.

Your Go commands

Keep the commands that already build and test your project.

Share Go build and test results.

Downloaded module source and compiled build results are different caches. This integration shares build and test results, not merely the packages needed to produce them.

See cache activity for your Go builds.

Inspect build-cache reads, misses, transfers, and storage for each run.

Explore the workspace →

Hugo

Cache stored

BoringCache0.279 GiB

actions/cache1.457 GiB

81%

Less cache stored

Hugo · compared with actions/cache

Keep shared-cache publication in trusted jobs.

Give consumers restore access and publishers a separate permission. Connect supported CI through OIDC or use scoped credentials.

Connect your CI →

Separate readers and publishers

Trusted builds Publish shared cache for the next build Read + publish
Pull requests Restore cache without replacing it Read only
Local development Use a scoped credential for the workspace Scoped access

Before you connect.

Does BoringCache replace Go's build cache?: No. It plugs into Go's cache program interface so the go command can ask an external process for cache entries.
How is the build cache different from the module cache?: GOCACHE holds build results; GOMODCACHE holds downloaded module source. GOCACHEPROG shares build and test results, so a warm module download alone does not provide the same reuse.
Why can a Go test still run with a warm cache?: Go decides whether a test result can be reused. Changes to inputs, non-cacheable test flags, or running with -count=1 can require the test to run again.

Read the Go setup guide →

Use other tools in the same workspace.

Explore build cache →

Start with your next Go build.

Install the CLI. Run onboarding to connect your repository and configure your cache.

30 GB of cache free. No credit card required.

Set up Go Use GitHub Actions

curl -sSL https://install.boringcache.com/install.sh | sh
boringcache onboard
boringcache go