From 8abf5e4f79ab50e84f289b7571eb104477807a44 Mon Sep 17 00:00:00 2001
From: FosterStack Admin <317177128+fosterstack-admin@users.noreply.github.com>
Date: Thu, 8 Oct 2026 20:36:06 -0400
Subject: [PATCH 1/5] Home + llms.txt: Maven stated without the in-progress
hedge (owner cold-read edit)
---
index.html | 2 +-
llms.txt | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/index.html b/index.html
index 185979b..63a7924 100644
--- a/index.html
+++ b/index.html
@@ -93,7 +93,7 @@
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 implements the Apache Maven Build Cache Extension's
- remote HTTP mode (Maven acceptance coverage is in progress), so a mixed Gradle and Maven
+ 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.
diff --git a/llms.txt b/llms.txt
index 624e4c1..828e185 100644
--- a/llms.txt
+++ b/llms.txt
@@ -12,7 +12,7 @@ distribution, support, or updates after 2026-12-31. Teams running it on open-sou
Gradle, with no Develocity licence, are orphaned on 2027-01-01. FosterStack Cache
speaks Gradle's documented `HttpBuildCache` protocol — acceptance-tested against a
real multi-module Gradle build in CI — and implements the Apache Maven Build Cache
-Extension's remote HTTP mode (Maven acceptance coverage is in progress). Same server,
+Extension's remote HTTP mode. Same server,
same core.
It is a single static Go binary (`CGO_ENABLED=0`), MIT-licensed, distributed as bare
From d4b3bffbda92a6f2105c6d0e78f675275378ad58 Mon Sep 17 00:00:00 2001
From: FosterStack Admin <317177128+fosterstack-admin@users.noreply.github.com>
Date: Thu, 8 Oct 2026 20:37:55 -0400
Subject: [PATCH 2/5] Home: Security is the difference (v0.2.1 facts, each with
evidence)
---
index.html | 16 ++++++++++++++++
1 file changed, 16 insertions(+)
diff --git a/index.html b/index.html
index 63a7924..4d866c0 100644
--- a/index.html
+++ b/index.html
@@ -135,6 +135,22 @@ What you get that a bare HTTP endpoint doesn't give you
30-minute migration
A step-by-step guide for existing Build Cache Node deployments. Same protocol, same CI config shape — migrating is mostly a URL change.
+ Security is the difference
+ Security is what sets this product apart. Everything below ships in the current release, and you can check each item yourself.
+
+ - 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.
+ - 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.
+ - Reproducible. Each image is assembled a second time on a separate machine, and the digests must match or the release fails.
+ - 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.
+
+
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:
From aa2ca997b9e6b4779c6c20fa456cfba1d6a782db Mon Sep 17 00:00:00 2001
From: FosterStack Admin <317177128+fosterstack-admin@users.noreply.github.com>
Date: Thu, 8 Oct 2026 20:39:15 -0400
Subject: [PATCH 3/5] Security section: Signed and verifiable / Supply chain
groups, v0.2.1 facts only
---
index.html | 11 ++++++++++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/index.html b/index.html
index 4d866c0..12f39e9 100644
--- a/index.html
+++ b/index.html
@@ -137,14 +137,23 @@ What you get that a bare HTTP endpoint doesn't give you
Security is the difference
Security is what sets this product apart. Everything below ships in the current release, and you can check each item 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 the container base image is pinned by digest.
+ - Watched for updates. Dependabot watches our Actions, Go modules and the base image.
- 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.
- - Reproducible. Each image is assembled a second time on a separate machine, and the digests must match or the release fails.
+
+ 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.
From c3bd5121ddd7780c140603a796b0aca9adbe1803 Mon Sep 17 00:00:00 2001
From: FosterStack Admin <317177128+fosterstack-admin@users.noreply.github.com>
Date: Thu, 8 Oct 2026 20:39:50 -0400
Subject: [PATCH 4/5] Security section: supply-chain practice items (7-day
wait, hash-checked installs, daily check, pins), verified on cache main
---
index.html | 8 +++++---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/index.html b/index.html
index 12f39e9..3c97e78 100644
--- a/index.html
+++ b/index.html
@@ -136,7 +136,7 @@ What you get that a bare HTTP endpoint doesn't give you
Security is the difference
- Security is what sets this product apart. Everything below ships in the current release, and you can check each item yourself.
+ Security is what sets this product apart. 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.
@@ -147,8 +147,10 @@ Signed and verifiable
Supply chain
- - Pinned build steps. Every GitHub Action our releases use is pinned to an exact commit, and the container base image is pinned by digest.
- - Watched for updates. Dependabot watches our Actions, Go modules and the base image.
+ - 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.
From 1da8fe8d5cc23ade16f5ee192a804fce78823d15 Mon Sep 17 00:00:00 2001
From: FosterStack Admin <317177128+fosterstack-admin@users.noreply.github.com>
Date: Thu, 8 Oct 2026 20:50:16 -0400
Subject: [PATCH 5/5] llms.txt: cut the "nobody runs it" sentence (owner
cold-read edit)
---
llms.txt | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/llms.txt b/llms.txt
index 828e185..41c491e 100644
--- a/llms.txt
+++ b/llms.txt
@@ -55,8 +55,7 @@ published schedule for what follows; the roadmap below says direction, not dates
Not yet shipped:
-- Production use beyond the project's own CI. Nobody runs this in a real build
- pipeline yet except the maintainer.
+- Production use beyond the project's own CI.
- A Helm chart. Deploying to Kubernetes today means applying plain manifests.
- The paid tiers. Team ($49/mo: multi-user access control, SSO, per-project
analytics, email support), Business ($199/mo: adds HA/replication, priority