maintained continuity for build infrastructure
Gradle Inc. has deprecated the free Develocity Build Cache Node: it "will no longer be distributed, supported or available after December 31, 2026." The migration path they offer requires a commercial Develocity subscription.

Your build cache shouldn't die with its vendor.

FosterStack is a self-hosted remote build cache server — a Develocity Build Cache Node replacement that speaks the same Gradle remote build cache HTTP protocol, so migrating is mostly a URL change. The same server doubles as a Maven build cache through the Apache Maven Build Cache Extension's remote HTTP mode, so a mixed Gradle and Maven shop runs one deploy instead of two. Open source core, one-command deploy, and the thing that actually matters: it stays patched, on a promise.

Try it now

There is no signup, no waitlist, and no license key for the free tier. Pull the image and point your build at it:

docker run -d -p 8080:8080 ghcr.io/fosterstack/cache:latest
curl localhost:8080/healthz   # -> ok

Quickstart Migrate off Build Cache Node Read the source

Where it stands: v0.1 — early. The cache core, HTTP surface, and release pipeline work and are tested; nobody is running it in a production build pipeline yet except us. Bugs and questions go to GitHub issues, which is also where the roadmap gets argued with.

Stay in touch

We do not collect email addresses. To follow the project, star the repository or use Watch → Custom → Releases on GitHub — that notifies you on a new release and nothing else, and it is a subscription you control and can revoke without asking us.

What you get that a bare HTTP endpoint doesn't give you

Yes — Gradle's remote cache protocol is just GET and PUT, and you could point it at any object store. What you'd be rebuilding yourself is everything around that:

Cache management

Eviction policies, size limits, and TTLs that keep a busy CI cache healthy without hand-tending.

Access control

Read/write credentials for CI vs. developers, so laptops consume the cache but never poison it.

Metrics & UI

Hit rates, entry sizes, and top misses — visible, so you know the cache is earning its keep.

Maintenance on an SLA

Dependency CVEs remediated fast — target within 48 hours of disclosure — with a public changelog as proof.

Day-one compatibility

A CI matrix tests every new Gradle and JDK release the day it ships. Upgrades stop being a gamble.

30-minute migration

A guide and config translator for existing Build Cache Node deployments. Same protocol, same CI config shape.

Built to be verified, not trusted

We're a new vendor asking to sit in your build pipeline, so the burden of proof is on us. The answer is to make everything checkable:

What we do not collect

Deliberately not claiming "we never collect any personal data": billing a customer requires an email address, and a privacy claim that is convenient but false is worse than none.

Pricing

FreeTeamBusiness
The full cache server, MIT-licensed, self-hosted. Forever free. $49/month — access control, metrics UI, email support. $199/month — SSO, HA/replication, analytics, priority support with the CVE-response SLA.

Self-serve, credit card, cancel anytime. Priced so an engineering manager can expense it without a procurement cycle — the incumbent's median contract runs $57k/year.

Roadmap honesty

Gradle and Maven both run against the same server today; we maintain the cache server, while the Maven client side is Apache's own Build Cache Extension. An npm remote cache for CI — same core, a third protocol — is the next protocol on the list. What is not on the list yet is a Helm chart and the paid tiers below; those are described so you know where this is going, not sold as available. If you need something sooner, open an issue — that is what moves the roadmap.