Build Cache Node end of life: what happens and your options

The free Develocity Build Cache Node will no longer be distributed or supported after December 31, 2026. Here is what that means for your builds, and the three things a team can do.

What stops on December 31

Gradle Inc. says the free standalone Build Cache Node "will no longer be distributed, supported or available after December 31, 2026." In plain words:

• It will no longer be distributed.
• It will no longer be supported.
• It will no longer be available.

Source: the vendor's official notice.

What keeps working

What happens to a node you already run is for the vendor to say, so read their notice. What holds for any build cache: it only speeds builds up, so if it is slow, empty or down, the worst case is a slower build, not a wrong one.

What changes is that the vendor says it will no longer support it.

Your three options

What FosterStack Cache is today

• A self-hosted remote build cache for Gradle. It speaks Gradle's own HttpBuildCache protocol, so moving is mostly a URL change.
• Maven too, through the Apache Maven Build Cache Extension.
• MIT licensed. One static binary or one container image on GitHub's registry.
• Releases are signed, and the evidence (SBOM, build provenance, vulnerability statements) is public.

It is early. The paid tiers are not built. Everything you can download today is the free core.

Security is the difference

Security is what we are building this product around. The release items below ship in the current release. The supply-chain items describe how we work today, in our own build and CI. You can check each one yourself.

Signed and verifiable

• Signed releases. Images and the checksums file are signed with Sigstore, with no signing key stored anywhere. How to verify.
• Build provenance. Every image and binary archive carries a signed statement naming the CI run that built it.
• A bill of materials. Every binary archive ships with an SBOM.
• Published vulnerability statements. A VEX file with each release says which known vulnerabilities do and do not affect it.
• Reproducible. Each image is assembled a second time on a separate machine, and the digests must match or the release fails.

Supply chain

• Pinned build steps. Every GitHub Action our releases use is pinned to an exact commit, and a check in CI enforces it on every change. The container base image is pinned by digest.
• Hash-checked installs. Python tooling in our CI is installed with hash checking, so a swapped package is refused.
• A 7-day wait. Our CI holds new dependency versions for 7 days before adopting them, and Dependabot has the same cooling-off period.
• A daily supply-chain check. Once a day, everything our build and CI pull in (actions, tools, packages) is checked against public advisory databases and malicious-package reports. Any hit opens an issue.
• Scanned before release. Two independent scanners with different databases check every release candidate, and any finding blocks the release unless a published VEX statement explains it. RELEASING.md.
• Rescanned every day. Every published image is scanned again daily, so a new vulnerability in something we shipped raises an issue.

Small, quiet and patched

• Tiny and quiet. A distroless image with one static program and no shell. It sends no telemetry and makes no outbound connections.
• A FIPS build. A FIPS variant uses Go's validated FIPS 140-3 cryptographic module.
• Patched for everyone. We aim to ship dependency fixes within 48 hours of disclosure. That is a target, not a promise. Security patches are never withheld from the free tier.
• Report a problem privately. See the security policy.

Next step

Read the migration guide or the source on GitHub. There is no signup and no form.