← All posts
6 min readThe Cachely team

Announcing Gradle remote cache support in Cachely

Cachely now supports Gradle remote build caching. If your JVM builds run in CI and on developer machines, you can now share Gradle task outputs across both with the same Cachely workspace token you already use for Nx and Turborepo.

What this unlocks for Gradle teams

Gradle's local build cache helps on one machine. A remote cache extends that across your team and CI. When one machine executes a cacheable task, every other machine can reuse that result instead of recomputing it.

With Cachely as the remote endpoint, you get a managed HTTP build cache backend with token auth and no infrastructure to run. The protocol is Gradle-native, so setup is just standard HttpBuildCache configuration.

Setup: point Gradle at Cachely

Add remote cache config in your root settings.gradle.kts (or settings.gradle), then provide your Cachely token as the password in HTTP Basic auth.

buildCache {
  local {
    // Optional but recommended for CI cache validation.
    isEnabled = false
  }
  remote<HttpBuildCache> {
    url = uri("https://remote.cachely.dev")
    isPush = true
    credentials {
      username = ""
      password = providers.environmentVariable("GRADLE_CACHE_TOKEN").orElse("").get()
    }
  }
}

Generate the token in the Cachely dashboard and set it in your shell or CI as GRADLE_CACHE_TOKEN. Cachely accepts Gradle's Basic auth and maps it to your workspace token.

How to verify it is working

1. Run a cacheable task once to populate

GRADLE_CACHE_TOKEN=<token> ./gradlew build --build-cache

2. Run it again and look for cache hits

GRADLE_CACHE_TOKEN=<token> ./gradlew build --build-cache --info

On the second run you should see tasks resolved FROM-CACHE. In CI, this means warmer builds after the first successful pipeline on the same inputs.

How Cachely handles Gradle artifacts

  • Keys are content-addressed and immutable.
  • Artifacts are scoped to your workspace, so one team cannot read another team's cache.
  • Authentication uses your existing workspace token model.
  • The endpoint supports standard Gradle HTTP Build Cache read and write flows.

Gradle can only send HTTP Basic credentials, so Cachely accepts that format in addition to Bearer tokens used by Nx and Turborepo. You can keep one cache service for polyglot monorepos.

Troubleshooting checklist

  • Confirm --build-cache is enabled in your CI command.
  • Use --info once to verify tasks are marked cacheable and you see FROM-CACHE on reruns.
  • Check that GRADLE_CACHE_TOKEN is set in the CI environment where Gradle runs.
  • Keep task inputs deterministic: non-deterministic tasks do not cache well on any backend.

If you are new to remote caching strategy, the remote cache guide explains key design, trust boundaries, and rollout patterns in more detail.

Connect Gradle in minutes

Use Cachely as your Gradle remote cache endpoint and share build outputs across local dev and CI with one workspace token.

Put a shared build cache behind your builds
Free tier, no credit card - connect Nx, Turborepo, Gradle, or Bazel in about five minutes.
Start freeSee pricing