Remote build cache CI setup
Connect your CI provider to Cachely through the build tool you already use. Store a token as a CI secret, configure the tool, and verify a remote cache hit.
Choose your CI provider
Each guide covers Nx, Lerna, Turborepo, Gradle, and Bazel, with one read-write token for trusted pipelines and optional read-only access.
- GitHub Actions build cache setup - repository secrets, workflow examples, and remote-hit verification.
- CircleCI build cache setup - contexts and build commands for your executor.
- Jenkins build cache setup - credential binding and cache reuse across agents.
GitLab CI and other providers
The same configuration works with GitLab CI, Buildkite, Woodpecker, Drone, and self-hosted runners. Store your token in the provider's secret store and expose it to the build step. In GitLab CI, use a masked CI/CD variable; choose whether to protect it based on which refs should receive it.
Follow your tool's configuration: Nx, Lerna, Turborepo, Gradle, or Bazel. Keep the token out of committed files and build logs.
Choose which builds may write
One read-write token is enough when you trust the users and code in your pipeline, including trusted pull requests. If users you do not trust can run or modify builds, give those builds read-only access when they may download private outputs, or no token when they should not access them. Provider guides explain how to keep write credentials out of untrusted jobs.
See tokens and access control for token scopes and rotation.
Confirm CI is hitting the remote cache
Populate the cache, then repeat the same revision and tasks on a fresh runner without restoring the local task cache. Check your build tool's remote-hit report and matching reads in the Cachely dashboard. A dependency-cache hit from actions/cache does not prove task outputs came from Cachely.
For missing activity or errors, see troubleshooting. For the differences between directory caches, artifacts, and task caching, read the GitHub Actions cache guide.