Is a remote build cache safe? Who can write to it

A build cache speeds up builds, and if it is down or empty, builds are only slower. The risk is different: a cache that serves the wrong files. That depends on who can write to it.

Two kinds of failure

• Down, empty or unreachable. Builds run slower. Nothing is lost and nothing is wrong. A build cache is only slower in this case.
• Serving wrong files. If something untrusted can write to the cache, it can change what later builds use as task outputs. This is a different class of problem, and it is the one to plan for.

Treat it as part of your supply chain

Anyone who can write to the cache can influence your builds. So:

• Turn on Basic Auth anywhere untrusted parties could reach the port.
• Share the read-write password only with CI and the developers you already trust to change your code.
• Give everyone else the optional read-only login. A client using it can read cache entries, and any write gets a 403.
• Use HTTPS in real deployments. Gradle sends the password with every request.

"Push disabled" is not a permission

Setting isPush = false in a Gradle config is the client choosing not to upload. It is not a rule on the server. A client that holds the read-write password can still write. The server-side rule is the read-only login.

What is not built yet

There is no per-person identity. A read-write login is shared by whoever holds it, so you cannot tell which writer did what.

A simple setup

• CI holds the read-write login and uploads.
• Developer laptops hold the read-only login and download.
• The server sits behind HTTPS, on a network you control.

The Jenkins and CI page shows how to wire it: Jenkins and CI build cache.

Related: what to check in a replacement build cache and security policy.