Gradle configuration cache vs build cache

They sound alike and they are not the same thing. One saves Gradle from working out your build again. The other saves your tasks from running again. You can use both, and only the second one uses a cache server. This is a real run of both together, on Gradle 9.8.0 and a 0.2.1 server.

The short answer

	Configuration cache	Build cache
What it saves	The work of reading your build files and planning the tasks	The work of running a task, by reusing its saved output
Where it lives	A folder in your project, on your machine	On your machine, and optionally on a server shared with a team
Turned on with	`--configuration-cache`	`--build-cache` (and a server URL for a shared one)
Thrown away when	A build file it depends on changes	A task's inputs change, so it gets a different key
Shows up as	"Reusing configuration cache."	`FROM-CACHE` next to a task

A remote cache server such as FosterStack Cache is for the build cache only. If Gradle suggests enabling the configuration cache, that is a separate local feature and has nothing to do with the server.

Both together, in a real run

The same small project, both flags on, the build cache pointed at a server:

gradle build --configuration-cache --build-cache

1. The first build. Nothing is cached anywhere yet:

Calculating task graph as no cached configuration is available for tasks: build
> Task :compileJava
BUILD SUCCESSFUL in 5s
Configuration cache entry stored.

2. The same build again. Both caches work, in different ways. The plan is reused, and the task is simply up to date on disk:

Reusing configuration cache.
> Task :compileJava UP-TO-DATE
BUILD SUCCESSFUL in 1s
Configuration cache entry reused.

3. After gradle clean. The build outputs are gone, so the task would have to run again. The plan is still reused, and the output now comes from the server:

Reusing configuration cache.
> Task :compileJava FROM-CACHE
BUILD SUCCESSFUL in 1s
Configuration cache entry reused.

The server's status page counted one hit for that, and it holds the compiled output only.

4. After editing build.gradle.kts, then gradle clean. Now the configuration cache is thrown away, because a build file changed, but the build cache still works, because the task's inputs did not change:

Calculating task graph as configuration cache cannot be reused because file 'build.gradle.kts' has changed.
> Task :compileJava FROM-CACHE
BUILD SUCCESSFUL in 2s
Configuration cache entry stored.

That fourth step is the clearest way to see they are separate: one was invalidated and the other was not.

Which should I turn on?

They solve different problems. The configuration cache helps most on large builds, where planning takes a while. The build cache helps most where the same work is done on many machines, such as CI runners and developer laptops. To set up a shared build cache, start with the Gradle build cache tutorial.

Gradle build cache tutorial FosterStack home