Build Cache Node migration checklist for Gradle

A short checklist for moving builds from the Develocity Build Cache Node to FosterStack Cache, with a real run to back it: the same project built against an old node, then against FosterStack Cache 0.2.1, then back. Read why the node is going away in Build Cache Node end of life.

What I tested

Gradle 9.8.0 and a small Java project, built twice against each server. The old side was a Build Cache Node image (version 21.2, built June 2025), run locally and set up to allow anonymous reads and writes for the test. The new side was a FosterStack Cache 0.2.1 server with no password. I did not test Maven in this run; for Maven see the setup page.

The checklist

1. Find every place your builds point at the old node

Search your repositories and CI settings for HttpBuildCache and for the node's address. The old node's address ends in /cache/. Write the list down: each entry is one line to change.

2. Start the new server

Follow your first 15 minutes. Turn on a password before other machines can reach it.

3. Change one line

buildCache {
    remote<HttpBuildCache> {
-       url = uri("http://old-node.example.com:5071/cache/")
+       url = uri("https://cache.example.com/")
        isPush = true
    }
}

If the new server has a password, also add a credentials block. See authentication and 401 errors.

4. Expect the first build to miss

Nothing is copied over, and nothing needs to be: a cache holds results your builds can always rebuild. The first build on the new server runs everything and fills it; the second hits.

5. Decide about the /cache/ part of the URL

You can drop it, as above, or keep it. FosterStack Cache uses the whole request path as the key, so a prefix works. Entries under different paths are separate, so pick one and use it everywhere.

6. Keep the old node running until you are sure

With Gradle, rolling back is the same one-line change in reverse; I tested that.

7. Retire the old node, and check the new one

When builds are hitting the new server, stop the old node. Watch the new one with monitoring, and size its disk with server sizing.

What happened in the run

Each row is two builds of the same project with gradle clean in between and Gradle's own local cache turned off, so a hit can only come from the server:

The new server's status page agreed: two entries stored, two hits, two misses. One small difference you may notice: a successful upload returns 200 from the old node and 201 from FosterStack Cache. Gradle accepted both.

Related: questions and answers and what to check in a replacement build cache.