Fast builds from cache are worth keeping.

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 implements 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 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

Bugs and questions go to GitHub issues, which is also where the roadmap is settled.

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:

More than kept patched.

• Signed releases you can verify in minutes.
• Build record, parts list (SBOM) and vulnerability statements published with every release.
• Scanned before every release. The current release is rescanned every day.
• Images assembled twice on separate machines; the results must match.
• Minimal image, no telemetry. FIPS variant available.
• Vulnerable dependencies fixed fast — our target is 48 hours from disclosure (the scope is in SECURITY.md).

How we build · Security policy · Verify a release

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:

• MIT-licensed core. Read the code before you run it.
• One public container image. Free and paid users pull the identical bytes — scan exactly what you deploy.
• When the paid tiers ship, a license key will unlock them in the same public image — no private registry, no gated downloads. (They are not built; the pricing below is direction, not a shelf.)
• Security patches are never withheld from the free tier. Not delayed, not embargoed — never.
• Signed commits, signed releases, public release notes. The repository's SECURITY.md states exactly what the release evidence does and does not prove today.

What we do not collect

• No telemetry, and no required FosterStack connection. The server reports nothing to us — no usage data, no license check, no update ping — and today's free core makes no outbound connections at all: it works identically on a machine with no route to the internet. When the paid features ship, the only outbound traffic will be what you configure (your identity provider for SSO, your peer replicas for HA) — endpoints you choose, never FosterStack.
• This website collects no email addresses. There is no signup form, no waitlist, and no newsletter. It sets no cookies, runs no analytics, and loads nothing from a third party.
• The only personal data FosterStack LLC holds is the irreducible minimum required to bill a paying customer — handled by Stripe — and whatever you voluntarily put in an email to support.

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

Per product. Free is the full product.

Paid tiers are described here, not sold: checkout is not open, and SSO, multi-user access control, usage analytics, HA/replication and named-version LTS are not built.

No sales call. No per-seat tax. No enterprise pricing mystery.

The Compliance tier, plainly: the security evidence underneath — SBOMs, SLSA provenance, signatures, VEX statements, and the FIPS 140-3 validated module (CMVP certificate #5247) — is public and free, verifiable by anyone. What the tier describes is the authored analysis — a FIPS applicability statement mapping the validated module boundary onto this product — plus per-release attestation letters signed by FosterStack LLC, and time on your security questionnaires. FosterStack Cache is not "FedRAMP compliant" or "CMMC compliant"; those attach to your service and your organization, never to a component you deploy. It is validated crypto and publishable evidence for your compliance program.

Guides

• Build Cache Node end of life: what happens and your options
• Migrate from Build Cache Node: setup, checklist, checks
• Jenkins and CI build cache
• Gradle build cache not working or hit rate low: causes
• Maven remote build cache setup, on/off, and with Gradle
• Gradle build cache on Kubernetes
• Security policy: how to report a vulnerability
• How big a build cache server? CPU, RAM, disk and load
• Install on an air-gapped network
• How FosterStack Cache is built and signed
• Verify a release yourself: signature, provenance, SBOM, VEX
• FIPS 140-3 build cache: run the FIPS image and confirm it
• How to clear or reset a self-hosted build cache
• Changelog
• Build cache size limit, eviction and a full disk
• Your first 15 minutes with a self-hosted build cache
• Your Laptop Builds Reuse What CI Already Built
• Does a Remote Cache Slow Your Build When It Misses?
• How Do I Know My Build Cache Hit Rate?
• Can Someone Poison Our Shared Build Cache?
• What Happens to My Build When the Cache Server Is Down?
• Does the Build Cache Work With Kotlin and Android Builds?
• Can Feature Branches Share the Build Cache With Main?
• Use a Remote Build Cache in GitHub Actions
• Is My Build Cache Server Healthy? What to Alert On
• Can I Restart the Cache Server While Builds Run?
• Change the Build Cache Logins Without Breaking CI
• Can Several Projects Share One Build Cache Server?
• Can a Failed or Cancelled Build Poison the Cache?
• Does a Build Cache Entry Contain My Source Code or Secrets?
• Why Did This One Task Miss the Build Cache?
• Build Cache Server Won't Start: Errors and Fixes
• Let CI write, developers only read: Gradle and Maven cache
• Gradle remote build cache authentication and 401 errors
• Maven build cache extension not restoring: the causes
• Production build cache: Docker Compose, nginx and TLS
• Build cache behind a corporate proxy: Gradle and Maven
• Enable or Disable the Gradle Build Cache: Flag or Property
• Gradle build cache: monorepo, buildSrc and included builds
• NIST SP 800-204C, 800-204D and SLSA: Our Release Pipeline
• Maven Build Cache Extension in a Multi-Module Project
• Upgrade, back up and move a build cache server
• Skip tests that passed: Gradle and Maven build cache
• What does the build cache store? Gradle and Maven
• Use your Gradle build cache over HTTPS with a private CA
• Reuse Gradle results in Docker CI, even in fresh containers

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. A dependency cache — the same server restoring node_modules, ~/.m2, and ~/.gradle/caches by lockfile key, so ephemeral CI agents stop re-downloading the world — is next on the list, npm first. The Helm chart and the paid tiers above are not built; they are described so you can see the direction. Free is real and complete today. If you need something sooner, open an issue — that is what moves the roadmap.