diff --git a/air-gapped-build-cache-install/index.html b/air-gapped-build-cache-install/index.html
index 5d7ba34..365b061 100644
--- a/air-gapped-build-cache-install/index.html
+++ b/air-gapped-build-cache-install/index.html
@@ -92,10 +92,10 @@ <h1>Install a build cache on an air-gapped network</h1>
   <h2>What to bring across</h2>
   <p>On a machine with internet access, download these from the release page:</p>
   <ul class="trust">
-    <li>The archive for your platform, for example <code>fscache_X.Y.Z_linux_amd64.tar.gz</code>.</li>
+    <li>The archive for your platform, for example <code>fscache_X.Y.Z_linux_amd64.tar.gz</code>, or <code>fscache-fips_X.Y.Z_linux_amd64.tar.gz</code> for the FIPS build. From v0.3.0 the archives are for Linux only (amd64 and arm64). There is no macOS archive; on a Mac, use the Linux image under Docker Desktop.</li>
     <li><code>checksums.txt</code> and <code>checksums.txt.bundle</code>, which is the signature over the checksums.</li>
     <li><code>cosign</code>, the signature checker. It is one static binary and will not be on a fresh isolated machine.</li>
-    <li>If you run containers: the image as a tar file, for example <code>crane pull ghcr.io/fosterstack/cache:X.Y.Z fscache-X.Y.Z.tar</code>. Verify the image with <code>cosign verify</code> before you export it, while you still have registry access (the <a href="https://github.com/fosterstack/cache/blob/main/docs/verify-images.md">image verification guide</a> has the command). Images are published for both <code>linux/amd64</code> and <code>linux/arm64</code>. Across a gap you pick one by hand, so pull on a machine of the destination type, or add <code>--platform</code>.</li>
+    <li>If you run containers: the image as a tar file, for example <code>crane pull ghcr.io/fosterstack/cache:X.Y.Z fscache-X.Y.Z.tar</code>, and <code>:X.Y.Z-fips</code> for the FIPS image. There are two images, production and <code>-fips</code>; v0.3.0 has no <code>-debug</code> image. Verify the image with <code>cosign verify</code> before you export it, while you still have registry access (<a href="/verify-a-release/">verify a release yourself</a> has the command). Images are published for both <code>linux/amd64</code> and <code>linux/arm64</code>. Across a gap you pick one by hand, so pull on a machine of the destination type, or add <code>--platform</code>.</li>
   </ul>
 
   <h2>Verify before you cross the gap</h2>
@@ -103,13 +103,12 @@ <h2>Verify before you cross the gap</h2>
   <pre tabindex="0"><code># 1. Prove the checksums file is ours
 cosign verify-blob \
   --bundle checksums.txt.bundle \
-  --certificate-identity-regexp='^https://github.com/fosterstack/cache/' \
+  --certificate-identity='https://github.com/fosterstack/cache/.github/workflows/stage-promote.yml@refs/tags/vX.Y.Z' \
   --certificate-oidc-issuer='https://token.actions.githubusercontent.com' \
   checksums.txt
 
 # 2. Prove your archive matches it
-sha256sum -c &lt;(grep "fscache_X.Y.Z_linux_amd64.tar.gz" checksums.txt | grep -v sbom)</code></pre>
-  <p><code>grep -v sbom</code> drops the SBOM line, because that file is not carried across. Without it, <code>sha256sum</code> reports the file as missing and fails.</p>
+sha256sum -c &lt;(grep "fscache_X.Y.Z_linux_amd64.tar.gz" checksums.txt)</code></pre>
   <p>Both steps matter. The checksum alone only shows the archive matches a file you carried beside it. The signature is what ties that file to us.</p>
 
   <h2>Install on the isolated side</h2>
@@ -135,6 +134,7 @@ <h2>How we checked</h2>
     <a class="btn" href="/migrate-build-cache-node/">Gradle and Maven setup</a>
     <a class="btn btn-secondary" href="/">FosterStack home</a>
   </div>
+  <p class="muted-note">Moving off the free Build Cache Node? See <a href="/build-cache-node-end-of-life/">what the end of life means</a> and the <a href="/migrate-build-cache-node/">migration guide</a>.</p>
 </main>
 <footer>
   <div>
diff --git a/bin/check-site-rot.py b/bin/check-site-rot.py
index 0adcef7..cf53eff 100755
--- a/bin/check-site-rot.py
+++ b/bin/check-site-rot.py
@@ -227,7 +227,14 @@ def resolve(path):
     homelinks = {m for m in re.findall(r'href="/([a-z0-9-]+)/"', texts[""])}
     for p in sorted(homelinks - page_set):
         bad("home: links /%s/ which is not a page" % p)
-    for p in sorted(page_set - homelinks):
+    # The home page links a few guides and /guides/, which lists every guide: a page linked from /guides/ counts as linked from home.
+    reachable = set(homelinks)
+    if "guides" in page_set:
+        if "guides" in homelinks:
+            reachable |= {m for m in re.findall(r'href="/([a-z0-9-]+)/"', texts.get("guides", ""))}
+        else:
+            bad("home: does not link /guides/ (the page that lists every guide)")
+    for p in sorted(page_set - reachable):
         bad("home: does not link /%s/ (the Guides list or another section should)" % p)
 
     for line in problems:
diff --git a/bin/test-check-site-rot.sh b/bin/test-check-site-rot.sh
index 75cb2bb..8c8fbac 100755
--- a/bin/test-check-site-rot.sh
+++ b/bin/test-check-site-rot.sh
@@ -83,9 +83,69 @@ import sys
 p, slug = sys.argv[1:3]
 s = open(p).read().replace('href="/%s/"' % slug, 'href="/"')
 open(p, "w").write(s)
+# a site with a /guides/ page lists every guide there: take the page off that list too
+import os
+g = os.path.join(os.path.dirname(p), "guides", "index.html")
+if os.path.isfile(g):
+    gs = open(g).read()
+    open(g, "w").write(gs.replace('href="/%s/"' % slug, 'href="/"'))
 EOF
 expect_fail "a page the home page no longer links" "home: does not link"
 
+# /guides/ lists the guides. Built in the throwaway copy, so these cases run on every site, with or without a real /guides/.
+# The home page links /guides/ and not $first; /guides/ links $first.
+with_guides() {
+  fresh
+  python3 - "$site" "$first" "$second" <<'EOF'
+import os, re, sys
+site, first, second = sys.argv[1:4]
+real = os.path.join(site, "guides")
+if os.path.isfile(os.path.join(real, "index.html")):
+    # a real /guides/ page: keep it, and make sure it lists $first
+    src = open(os.path.join(real, "index.html")).read()
+else:
+    src = open(os.path.join(site, second, "index.html")).read()
+    src = re.sub(r"<title>.*?</title>", "<title>Guides</title>", src, count=1, flags=re.S)
+    src = src.replace("/%s/" % second, "/guides/")
+    os.makedirs(real, exist_ok=True)
+if 'href="/%s/"' % first not in src:
+    src = src.replace("</main>", '<p><a href="/%s/">listed guide</a></p></main>' % first, 1)
+open(os.path.join(real, "index.html"), "w").write(src)
+home = os.path.join(site, "index.html")
+h = open(home).read().replace('href="/%s/"' % first, 'href="/"')
+if 'href="/guides/"' not in h:
+    h = h.replace("</main>", '<p><a href="/guides/">All guides</a></p></main>', 1)
+open(home, "w").write(h)
+sm = os.path.join(site, "sitemap.xml")
+m = open(sm).read()
+if "/guides/</loc>" not in m:
+    open(sm, "w").write(m.replace("</urlset>", "<url><loc>https://fosterstack.com/guides/</loc></url></urlset>", 1))
+ll = os.path.join(site, "llms.txt")
+l = open(ll).read()
+if "fosterstack.com/guides/)" not in l:
+    open(ll, "w").write(l.rstrip("\n") + "\n- [Guides](https://fosterstack.com/guides/): all guides\n")
+EOF
+}
+
+with_guides; expect_pass "a page linked only from /guides/ counts as linked from home"
+
+with_guides; python3 - "$site/guides/index.html" "$first" <<'EOF'
+import sys
+p, slug = sys.argv[1:3]
+s = open(p).read()
+open(p, "w").write(s.replace('href="/%s/"' % slug, 'href="/"'))
+EOF
+expect_fail "a page on neither the home page nor /guides/" "home: does not link /$first/"
+
+with_guides; python3 - "$site/index.html" <<'EOF'
+import sys
+p = sys.argv[1]
+s = open(p).read()
+open(p, "w").write(s.replace('href="/guides/"', 'href="/"'))
+EOF
+expect_fail "a home page that does not link /guides/" "home: does not link /guides/"
+expect_fail "a /guides/ page the home page does not link lists nothing for home" "home: does not link /$first/"
+
 fresh; edit "$site/$first/index.html" "REGEX:<title>.*?</title>" "<title>This title is deliberately far too long to be a good page title for a search result</title>"
 expect_fail "a title over 60 characters" "characters (max 60)"
 
diff --git a/build-cache-docker-compose-production/index.html b/build-cache-docker-compose-production/index.html
index 1c5760f..fce893f 100644
--- a/build-cache-docker-compose-production/index.html
+++ b/build-cache-docker-compose-production/index.html
@@ -1,6 +1,7 @@
 <!doctype html>
 <html lang="en">
 <head>
+<meta name="robots" content="noindex, nofollow">
 <meta charset="utf-8">
 <meta name="viewport" content="width=device-width, initial-scale=1">
 <title>Docker Compose build cache: quick start and production</title>
@@ -88,7 +89,8 @@
 </header>
 <main>
   <h1>Docker Compose build cache: quick start and production</h1>
-  <p class="lede">Run a shared Gradle build cache for your team in one Compose file, with a password and a size limit. For real use, put an HTTPS proxy in front: Gradle sends the password with every request.</p>
+  <p class="lede">Run a shared Gradle build cache for your team in one Compose file, with a password and a size limit. For real use, serve HTTPS: Gradle sends the password with every request. Put a proxy in front (below), or set <code>FSCACHE_TLS_CERT</code> and <code>FSCACHE_TLS_KEY</code> and let the server answer HTTPS itself.</p>
+  <p class="muted-note"><strong>DRAFT for v0.3, private preview, not published and never merged before v0.3.0 is live.</strong></p>
 
   <h2 id="gradle-build-cache-docker-compose">Gradle build cache with Docker Compose</h2>
   <p>Our advice, not a test result. This is the shape we suggest once you go past a first trial.</p>
@@ -131,6 +133,10 @@ <h2>Point Gradle at it</h2>
   <h2>Health checks</h2>
   <p>The container image has no shell, so there is no health check inside the Compose file. Probe <code>/healthz</code> from outside: your orchestrator's HTTP check, a monitor, or <code>curl -f http://localhost:8080/healthz</code> from the host.</p>
 
+  <h2>Two ways to serve HTTPS</h2>
+  <p><strong>A proxy in front</strong> (the nginx setup below): the proxy holds the certificate and the server stays on plain HTTP behind it. <strong>TLS in the server:</strong> set <code>FSCACHE_TLS_CERT</code> and <code>FSCACHE_TLS_KEY</code> to a PEM certificate file (it may hold the chain) and its private key file, both or neither. The server then serves HTTPS only, on <code>FSCACHE_ADDR</code>, with TLS 1.2 as the minimum version. HTTP/2 is not offered, a plain-HTTP request to that port gets <code>400</code>, and your <code>/healthz</code> check moves to <code>https://</code>. Mount the files read-only. They are read only at startup, so replace them and restart.</p>
+  <p>If a client cannot connect, look from the client side with <code>openssl s_client -connect HOST:PORT -alpn http/1.1</code>: the server does not log handshake failures at the default log level.</p>
+
   <h2>Production: nginx and TLS in front</h2>
   <p>A Compose file for a shared build cache that only answers over HTTPS, with a password, behind nginx. It was run for real on FosterStack Cache 0.2.1 and Gradle 9.8.0. The file pins 0.2.2, a security-patch release whose release notes say it changes no behaviour.</p>
 
diff --git a/build-cache-server-sizing/index.html b/build-cache-server-sizing/index.html
index 0a0bf32..0ffad3c 100644
--- a/build-cache-server-sizing/index.html
+++ b/build-cache-server-sizing/index.html
@@ -225,6 +225,7 @@ <h3>Builds at once and the upload limit</h3>
     <a class="btn" href="/migrate-build-cache-node/">Gradle and Maven setup</a>
     <a class="btn btn-secondary" href="/">FosterStack home</a>
   </div>
+  <p class="muted-note">Moving off the free Build Cache Node? See <a href="/build-cache-node-end-of-life/">what the end of life means</a> and the <a href="/migrate-build-cache-node/">migration guide</a>.</p>
 </main>
 <footer>
   <div>
diff --git a/can-someone-poison-our-build-cache/index.html b/can-someone-poison-our-build-cache/index.html
index c825ced..758b532 100644
--- a/can-someone-poison-our-build-cache/index.html
+++ b/can-someone-poison-our-build-cache/index.html
@@ -1,6 +1,7 @@
 <!doctype html>
 <html lang="en">
 <head>
+<meta name="robots" content="noindex, nofollow">
 <meta charset="utf-8">
 <meta name="viewport" content="width=device-width, initial-scale=1">
 <title>Can Someone Poison Our Shared Build Cache?</title>
@@ -89,6 +90,7 @@
 <main>
   <h1>Can someone poison our shared build cache?</h1>
   <p class="lede">Anyone who holds the write login can change what every other build restores. FosterStack Cache does not stop that holder. It lets you give everyone else a read-only login, and in our runs the server refused their writes.</p>
+  <p class="muted-note"><strong>DRAFT for v0.3, private preview, not published and never merged before v0.3.0 is live.</strong></p>
 
   <h2>The short answer</h2>
   <p>The server has two logins. The write login lets a client store and replace entries. The read-only login lets a client only read them.</p>
@@ -115,7 +117,7 @@ <h2>What to do</h2>
     <li><strong>Give everyone else the optional read-only login.</strong> That includes laptops. The setup is on <a href="/gradle-build-cache-ci-writes-developers-read/">let CI write, developers only read</a>, and the CI wiring is on <a href="/jenkins-ci-build-cache/">Jenkins and CI build cache</a>.</li>
     <li><strong>Keep builds of untrusted code on the read-only login.</strong> An example is a pull request from a fork.</li>
     <li><strong>Do not count on <code>isPush = false</code>.</strong> It only controls whether your own build uploads. The login is what the server enforces.</li>
-    <li><strong>Use HTTPS, on a network you control.</strong> Gradle sends the login with its requests.</li>
+    <li><strong>Use HTTPS, on a network you control.</strong> Gradle sends the login with its requests. A proxy in front or the server's own certificate both work.</li>
     <li><strong>If you doubt an entry, clear the cache.</strong> See <a href="/reset-gradle-build-cache/">how to clear or reset a build cache</a>.</li>
   </ul>
   <p>FosterStack Cache has one write login and one read-only login. There is no per-person identity: a write login is shared by whoever holds it, so the login alone does not say which writer did what. We did not test whether the server records who wrote an entry.</p>
diff --git a/changelog/index.html b/changelog/index.html
index 367dc69..e7000e4 100644
--- a/changelog/index.html
+++ b/changelog/index.html
@@ -1,11 +1,12 @@
 <!doctype html>
 <html lang="en">
 <head>
+<meta name="robots" content="noindex, nofollow">
 <meta charset="utf-8">
 <meta name="viewport" content="width=device-width, initial-scale=1">
-<title>FosterStack Cache changelog: v0.1.0 to v0.2.2</title>
+<title>FosterStack Cache changelog</title>
 <meta name="description" content="Release notes for FosterStack Cache v0.1.0, v0.2.1 and v0.2.2, quoted from GitHub as published, and a note that no release was published for v0.2.0.">
-<meta property="og:title" content="FosterStack Cache changelog: v0.1.0 to v0.2.2">
+<meta property="og:title" content="FosterStack Cache changelog">
 <meta property="og:description" content="Release notes for FosterStack Cache v0.1.0, v0.2.1 and v0.2.2, quoted from GitHub as published, and a note that no release was published for v0.2.0.">
 <meta property="og:url" content="https://fosterstack.com/changelog/">
 <meta property="og:type" content="website">
@@ -87,9 +88,14 @@
   <div class="tag">Infrastructure worth keeping — and kept patched.</div>
 </header>
 <main>
-  <h1>FosterStack Cache changelog: v0.1.0 to v0.2.2</h1>
+  <h1>FosterStack Cache changelog</h1>
   <p class="lede">The release notes from GitHub, quoted as published. Newest first. For anything else, the <a href="https://github.com/fosterstack/cache/releases">releases page</a> is the source.</p>
 
+  <p class="muted-note"><strong>DRAFT for v0.3, private preview, not published and never merged before v0.3.0 is live.</strong></p>
+
+  <h2>v0.3.0</h2>
+  <p>The v0.3.0 release notes will be quoted here as published, like the others.</p>
+
   <h2>v0.2.2</h2>
   <p class="muted-note">Release name: fscache v0.2.2. Published 2026-10-09.</p>
   <blockquote>
@@ -106,7 +112,7 @@ <h2>v0.2.1</h2>
   <p><a href="https://github.com/fosterstack/cache/releases/tag/v0.2.1">v0.2.1 on GitHub</a></p>
 
   <h2>v0.2.0</h2>
-  <p>No release was published for v0.2.0: the tag exists, but its release run failed. Use v0.2.2, the latest release.</p>
+  <p>No release was published for v0.2.0: the tag exists, but its release run failed.</p>
 
   <h2>v0.1.0</h2>
   <p class="muted-note">Published 2026-08-22.</p>
@@ -115,7 +121,7 @@ <h2>v0.1.0</h2>
     <p><strong>Note on this release's evidence (added Sep 2026).</strong> v0.1.0 was built and published by the pre-remediation release pipeline: a snapshot build was scanned, and a separate build of the same commit was published, so these published images were not scanned before publication. They have been rescanned since at every severity with the published VEX applied — see the <a href="https://github.com/fosterstack/cache/actions/workflows/rescan-v010.yml">rescan runs</a> for verdicts against the exact published digests. The signatures and provenance on this release are accurate about what they say — which CI run produced which digest — and say nothing about scanning. The next release is the first to carry the full evidence chain: one build, scanned and tested by digest, promoted without a rebuild.</p>
   </blockquote>
   <p><a href="https://github.com/fosterstack/cache/releases/tag/v0.1.0">v0.1.0 on GitHub</a></p>
-  <p><strong>What changed since:</strong> the v0.2.1 and v0.2.2 release notes point to their <code>release-manifest.json</code> evidence bundle. The release process, as <a href="https://github.com/fosterstack/cache/blob/main/RELEASING.md">RELEASING.md</a> describes it, is "One build, one set of digests, promoted without a rebuild", with every scanner run "against the exact candidate digests".</p>
+  <p><strong>What changed since:</strong> the v0.2.1 and v0.2.2 release notes point to their <code>release-manifest.json</code> evidence bundle. The release process, as <a href="https://github.com/fosterstack/cache/blob/main/RELEASING.md">RELEASING.md</a> describes it, is "One build, one set of digests, promoted without a rebuild (the independent rebuild only checks them and is never published)", with every scanner run "against the exact candidate digests".</p>
 
   <p class="muted-note">Related: <a href="/how-we-build/">how releases are built and signed</a> and <a href="/security/">security policy</a>.</p>
   <div class="cta-row">
diff --git a/does-build-cache-entry-contain-source-code-or-secrets/index.html b/does-build-cache-entry-contain-source-code-or-secrets/index.html
index 11c2ca2..6718f5a 100644
--- a/does-build-cache-entry-contain-source-code-or-secrets/index.html
+++ b/does-build-cache-entry-contain-source-code-or-secrets/index.html
@@ -1,6 +1,7 @@
 <!doctype html>
 <html lang="en">
 <head>
+<meta name="robots" content="noindex, nofollow">
 <meta charset="utf-8">
 <meta name="viewport" content="width=device-width, initial-scale=1">
 <title>Does a Build Cache Entry Contain My Source Code or Secrets?</title>
@@ -89,6 +90,7 @@
 <main>
   <h1>Does a build cache entry contain my source code or secrets?</h1>
   <p class="lede">In our runs, FosterStack Cache stored what tasks produce, not your source files. That includes class files and anything a test prints, so a secret in an output is in the cache.</p>
+  <p class="muted-note"><strong>DRAFT for v0.3, private preview, not published and never merged before v0.3.0 is live.</strong></p>
 
   <h2>The short answer</h2>
   <ul class="trust">
@@ -108,7 +110,7 @@ <h2>What to do</h2>
     <li><strong>Keep secrets out of Java constants.</strong> A constant lives on in the class file, in the cache and in your jar.</li>
     <li><strong>Declare an environment variable as a task input if the task reads it.</strong> We changed one that a task read without declaring it, and the old result came back from the cache.</li>
     <li><strong>Give developers the read-only login and give CI the read-write login.</strong> See <a href="/gradle-build-cache-ci-writes-developers-read/">let CI write and developers read</a>. One login reaches every project on a server, so use one server per group that must not share. See <a href="/several-projects-share-one-build-cache-server/">several projects on one server</a>.</li>
-    <li><strong>Use HTTPS when the server is not on your own machine.</strong> Our runs used plain HTTP to a server on the same Mac. See <a href="/gradle-remote-build-cache-private-ca-https/">use your build cache over HTTPS with a private CA</a>.</li>
+    <li><strong>Use HTTPS when the server is not on your own machine.</strong> Our runs used plain HTTP to a server on the same Mac. See <a href="/gradle-remote-build-cache-private-ca-https/">use your build cache over HTTPS with a private CA</a>. The HTTPS can come from a proxy or from the server itself (<code>FSCACHE_TLS_CERT</code> and <code>FSCACHE_TLS_KEY</code>).</li>
   </ul>
   <p>What each task stores is on <a href="/what-gradle-stores-in-build-cache/">know what your Gradle build cache stores</a>. Who can change entries is on <a href="/can-someone-poison-our-build-cache/">can someone poison our shared build cache</a>.</p>
 
diff --git a/everything-we-do-for-security/index.html b/everything-we-do-for-security/index.html
new file mode 100644
index 0000000..adc478e
--- /dev/null
+++ b/everything-we-do-for-security/index.html
@@ -0,0 +1,171 @@
+<!doctype html>
+<html lang="en">
+<head>
+<meta name="robots" content="noindex, nofollow">
+<meta charset="utf-8">
+<meta name="viewport" content="width=device-width, initial-scale=1">
+<title>Everything FosterStack does for security</title>
+<meta name="description" content="DRAFT v0.3.0, not published: the security practices that run on FosterStack Cache, one line each, with where to check them.">
+<meta property="og:title" content="Everything FosterStack does for security">
+<meta property="og:description" content="DRAFT v0.3.0, not published: the security practices that run on FosterStack Cache, one line each, with where to check them.">
+<meta property="og:url" content="https://fosterstack.com/everything-we-do-for-security/">
+<meta property="og:type" content="website">
+<meta property="og:site_name" content="FosterStack">
+<link rel="canonical" href="https://fosterstack.com/everything-we-do-for-security/">
+<link rel="icon" href="/favicon.svg" type="image/svg+xml">
+<link rel="icon" href="/favicon.ico" sizes="any">
+<link rel="apple-touch-icon" href="/apple-touch-icon.png">
+<style>
+  :root {
+    --bg: #ffffff; --fg: #16181d; --muted: #5b6472; --line: #e4e7ec;
+    --accent: #0d7a5f; --accent-fg: #ffffff; --card: #f6f8f9; --warn-bg: #fff7ed; --warn-line: #fdba74;
+    --mark: #0f4d66;
+  }
+  @media (prefers-color-scheme: dark) {
+    :root {
+      --bg: #101318; --fg: #e8eaf0; --muted: #98a2b3; --line: #262c36;
+      --accent: #2fbf95; --accent-fg: #08110e; --card: #171c23; --warn-bg: #241a10; --warn-line: #7c4a12;
+      --mark: #e8eaf0;
+    }
+  }
+  * { margin: 0; padding: 0; box-sizing: border-box; }
+  body {
+    background: var(--bg); color: var(--fg);
+    font: 16px/1.6 system-ui, -apple-system, "Segoe UI", Roboto, sans-serif;
+    -webkit-font-smoothing: antialiased;
+  }
+  main { max-width: 44rem; margin: 0 auto; padding: 0 1.25rem 4rem; }
+  header.site { max-width: 44rem; margin: 0 auto; padding: 1.25rem; display: flex; align-items: baseline; gap: .6rem; }
+  .logo { font-weight: 700; font-size: 1.05rem; letter-spacing: -.01em; }
+  .logo span { color: var(--accent); }
+  .logo .mark { width: 1.2em; height: 1.2em; vertical-align: -.24em; margin-right: .4em; }
+  .tag { color: var(--muted); font-size: .85rem; }
+  .notice {
+    background: var(--warn-bg); border: 1px solid var(--warn-line); border-radius: 8px;
+    padding: .7rem 1rem; font-size: .92rem; margin: 1.5rem 0 2.5rem;
+  }
+  h1 { font-size: 2rem; line-height: 1.2; letter-spacing: -.02em; margin-bottom: 1rem; }
+  .lede { font-size: 1.12rem; color: var(--muted); margin-bottom: 2rem; }
+  h2 { font-size: 1.25rem; margin: 3rem 0 .9rem; letter-spacing: -.01em; }
+  p + p { margin-top: .8rem; }
+  .cards { display: grid; grid-template-columns: repeat(auto-fit, minmax(15rem, 1fr)); gap: .8rem; margin-top: 1rem; }
+  .card { background: var(--card); border: 1px solid var(--line); border-radius: 10px; padding: 1rem 1.1rem; }
+  .card h3 { font-size: .98rem; margin-bottom: .35rem; }
+  .card p { font-size: .9rem; color: var(--muted); }
+  ul.trust { list-style: none; margin-top: .5rem; }
+  ul.trust li { padding: .45rem 0 .45rem 1.6rem; position: relative; }
+  ul.trust li::before { content: "✓"; position: absolute; left: .2rem; color: var(--accent); font-weight: 700; }
+  code, pre { font-family: ui-monospace, "SF Mono", Menlo, monospace; font-size: .88em; }
+  code { background: var(--card); border: 1px solid var(--line); border-radius: 5px; padding: .1em .35em; }
+  pre code { background: none; border: 0; padding: 0; color: inherit; font-size: 1em; }
+  button {
+    padding: .7rem 1.3rem; font-size: 1rem; font-weight: 600; cursor: pointer;
+    background: var(--accent); color: var(--accent-fg); border: 0; border-radius: 8px;
+  }
+  button:disabled { opacity: .6; cursor: default; }
+  table { width: 100%; border-collapse: collapse; font-size: .92rem; margin-top: 1rem; }
+  th, td { text-align: left; padding: .55rem .6rem; border-bottom: 1px solid var(--line); vertical-align: top; }
+  th { font-size: .8rem; text-transform: uppercase; letter-spacing: .04em; color: var(--muted); }
+  pre { background: #0f172a; color: #e2e8f0; padding: .9rem 1rem; border-radius: 8px;
+        overflow-x: auto; font-size: .9rem; line-height: 1.5; }
+  .cta-row { display: flex; gap: .6rem; flex-wrap: wrap; margin-top: 1.1rem; }
+  .btn { display: inline-block; padding: .55rem 1rem; border-radius: 8px; font-weight: 600;
+         text-decoration: none; background: var(--accent); color: var(--accent-fg); }
+  .btn-secondary { background: transparent; color: inherit; border: 1px solid var(--muted); }
+  .muted-note { color: var(--muted); font-size: .93rem; margin-top: 1.1rem; }
+  footer { border-top: 1px solid var(--line); margin-top: 4rem; padding: 1.5rem 1.25rem 3rem; }
+  footer div { max-width: 44rem; margin: 0 auto; color: var(--muted); font-size: .82rem; }
+  a { color: var(--accent); }
+
+  ol.steps { margin: .6rem 0 0 1.3rem; }
+  ol.steps li { padding: .3rem 0; }
+  code { overflow-wrap: anywhere; }
+  pre code { overflow-wrap: normal; }
+  :focus-visible { outline: 3px solid var(--accent); outline-offset: 2px; }
+</style>
+</head>
+<body>
+<header class="site">
+  <div class="logo"><svg class="mark" viewBox="0 0 96 96" aria-hidden="true" focusable="false"><rect x="12" y="14" width="72" height="18" rx="5" fill="var(--mark)"/><rect x="12" y="39" width="48" height="18" rx="5" fill="var(--mark)"/><rect x="12" y="64" width="26" height="18" rx="5" fill="var(--accent)"/></svg>foster<span>stack</span></div>
+  <div class="tag">Infrastructure worth keeping — and kept patched.</div>
+</header>
+<main>
+  <h1>Everything FosterStack does for security</h1>
+  <p class="muted-note"><strong>DRAFT for v0.3, private preview, not published and never merged before v0.3.0 is live.</strong></p>
+  <p class="lede">This is the list of security practices that run on the FosterStack Cache repository today, one line each. Every line links to the place that goes deep: a page that explains it, or the file that does it. <a href="https://github.com/fosterstack/cache/blob/main/SECURITY.md">SECURITY.md</a> is the short policy (what we promise, including the patch target and how to report a vulnerability); this page is what we do.</p>
+  <h2>Source</h2>
+  <ul>
+    <li><strong>Signed commits.</strong> The <code>main</code> branch accepts only signed commits, under a repository ruleset that also requires the checks on every pull request (<a href="https://github.com/fosterstack/cache/rules">the repository's rules</a>, <a href="https://github.com/fosterstack/cache/blob/main/.github/policy/required-checks.json">required checks</a>).</li>
+    <li><strong>Signed release tags, checked first.</strong> The release chain starts by verifying the tag against a list of allowed signers kept on <code>main</code>, before any repository code runs (<a href="https://github.com/fosterstack/cache/blob/main/.github/workflows/stage-admission.yml">admission stage</a>, <a href="https://github.com/fosterstack/cache/blob/main/.github/policy/allowed_signers">allowed signers</a>).</li>
+    <li><strong>Release tags are protected.</strong> Creating a release tag is restricted by a repository rule, and a published release tag cannot be moved, updated or deleted (<a href="https://github.com/fosterstack/cache/rules">the repository's rules</a>).</li>
+    <li><strong>The merge gate runs from <code>main</code>.</strong> The check that judges a pull request is the copy on <code>main</code>, not the copy in the pull request, so a change cannot edit the rule that judges it (<a href="https://github.com/fosterstack/cache/blob/main/.github/workflows/agent-review-gate.yml">review gate</a>).</li>
+    <li><strong>CI runs a fork's code without secrets.</strong> The CI workflow runs on <code>pull_request</code>, never <code>pull_request_target</code>, so a fork's code runs with GitHub's no-secrets treatment (<a href="https://github.com/fosterstack/cache/blob/main/.github/workflows/ci.yml">CI</a>).</li>
+    <li><strong>A reserved branch for the automated auditor.</strong> Only the auditor's delivery identity may push to its branch prefix, and any other pusher fails the check (<a href="https://github.com/fosterstack/cache/blob/main/.github/workflows/reserved-branch-guard.yml">guard</a>).</li>
+  </ul>
+  <h2>Dependencies</h2>
+  <ul>
+    <li><strong>Every action in every workflow is pinned to a full commit digest.</strong> A tag or a branch reference fails the check on every pull request, and the check also reads the tag each digest claims to be (<a href="https://github.com/fosterstack/cache/blob/main/.github/agent/bin/check-action-pins.py">pin checker</a>).</li>
+    <li><strong>Container images are named by digest.</strong> An image a workflow runs, pulls or passes to an action must be a digest, never a tag, and the same checker fails the pull request otherwise (<a href="https://github.com/fosterstack/cache/blob/main/.github/agent/bin/check-action-pins.py">pin checker</a>).</li>
+    <li><strong>A new version waits seven days.</strong> A pull request that moves a pinned version is held until that version has been public for seven days, by a server-side time (<a href="https://github.com/fosterstack/cache/blob/main/.github/workflows/supply-chain.yml">supply-chain workflow</a>).</li>
+    <li><strong>Everything we pin is checked daily.</strong> The inventory of pinned actions and packages is checked once a day against published advisories and malicious-package reports (<a href="https://github.com/fosterstack/cache/blob/main/.github/workflows/supply-chain.yml">supply-chain workflow</a>).</li>
+    <li><strong>Automated dependency review on every pull request.</strong> Newly added dependencies and their advisories are listed and checked before merge (<a href="https://github.com/fosterstack/cache/blob/main/.github/workflows/ci.yml">CI</a>).</li>
+    <li><strong>Updates are automated and judged.</strong> Patch and minor updates merge after the full gate; a major update is read against the upstream release notes and our usage by an automated reviewer before anyone merges it (<a href="https://github.com/fosterstack/cache/blob/main/.github/workflows/dependabot-auto-merge.yml">auto-merge</a>, <a href="https://github.com/fosterstack/cache/blob/main/.github/workflows/dependabot-reviewer.yml">reviewer</a>).</li>
+    <li><strong>The Go toolchain stays on the newest patch of a supported minor.</strong> A daily job proposes the bump when a newer supported release exists (<a href="https://github.com/fosterstack/cache/blob/main/.github/workflows/go-freshness.yml">freshness job</a>).</li>
+    <li><strong>Go vulnerability analysis on every change.</strong> <code>govulncheck</code> runs on every pull request and push; <code>gosec</code> and CodeQL read the code (<a href="https://github.com/fosterstack/cache/blob/main/.github/workflows/ci.yml">CI</a>, <a href="https://github.com/fosterstack/cache/blob/main/.github/workflows/codeql.yml">CodeQL</a>).</li>
+    <li><strong>Posture is measured in public.</strong> OpenSSF Scorecard runs weekly and its badge is on the README (<a href="https://github.com/fosterstack/cache/blob/main/.github/workflows/scorecard.yml">Scorecard</a>).</li>
+  </ul>
+  <h2>Build</h2>
+  <ul>
+    <li><strong>One build, promoted by digest.</strong> The release is built once; the same bytes are scanned, tested and promoted, and the promoted digest is asserted equal to the scanned digest after every copy (<a href="https://github.com/fosterstack/cache/blob/main/.github/workflows/release.yml">release chain</a>).</li>
+    <li><strong>Every stage signs what it did.</strong> Admission, build, image assembly, reproducibility, each scan and acceptance each sign a statement naming the exact digests, and the next stage verifies it on entry (<a href="https://github.com/fosterstack/cache/blob/main/RELEASING.md">RELEASING.md</a>).</li>
+    <li><strong>Pinned toolchain.</strong> The build uses the Go version from <code>go.mod</code> with downloads of a newer toolchain disabled, and module manifests are verified, never rewritten (<a href="https://github.com/fosterstack/cache/blob/main/.github/workflows/stage-build.yml">build stage</a>).</li>
+    <li><strong>Distroless image, assembled by copy.</strong> Each image variant is a base image digest plus the binary bytes, with no build step inside the image; the production and FIPS images have no shell and no package manager (<a href="https://github.com/fosterstack/cache/blob/main/.github/workflows/stage-image.yml">image stage</a>).</li>
+    <li><strong>Assembled twice and compared.</strong> The image assembly is repeated on a fresh runner and the digests must be equal (<a href="https://github.com/fosterstack/cache/blob/main/.github/workflows/stage-reproducibility.yml">reproducibility stage</a>).</li>
+    <li><strong>A FIPS variant.</strong> A <code>-fips</code> build uses Go's FIPS 140-3 validated cryptographic module, announces itself at startup, and the whole test suite runs in <code>fips140=only</code> mode on every commit (<a href="https://github.com/fosterstack/cache/blob/main/SECURITY.md#approved-only-cryptography">SECURITY.md</a>).</li>
+    <li><strong>Approved-only cryptography is checked by lint too.</strong> A lint rule denies the third-party cryptographic packages we name, such as <code>golang.org/x/crypto</code>, so code reaches for the validated module instead (<a href="https://github.com/fosterstack/cache/blob/main/.golangci.yml"><code>.golangci.yml</code></a>).</li>
+  </ul>
+  <h2>Scanning</h2>
+  <ul>
+    <li><strong>Scanners with different databases block every release.</strong> The set is one list in the repository, each scanner blocks at every severity including unknown, and nothing hard-codes a name or a count (<a href="https://github.com/fosterstack/cache/blob/main/.github/policy/scanners.json">scanner list</a>, <a href="https://github.com/fosterstack/cache/blob/main/SECURITY.md#nothing-ships-with-a-known-cve">SECURITY.md</a>).</li>
+    <li><strong>Scanned on every pull request.</strong> The pull request gate builds the same image the release would ship and scans it (<a href="https://github.com/fosterstack/cache/blob/main/.github/workflows/scan.yml">scan workflow</a>).</li>
+    <li><strong>Four scanners, every day.</strong> The daily rescan builds main's candidate and scans it with four independent scanners, then tallies how many saw each finding (<a href="https://github.com/fosterstack/cache/blob/main/.github/workflows/main-candidate-rescan.yml">daily rescan</a>).</li>
+    <li><strong>Published images are rescanned daily.</strong> A CVE disclosed against bytes we already shipped raises a tracked issue (<a href="https://github.com/fosterstack/cache/blob/main/docs/scanning.md">scanning.md</a>).</li>
+    <li><strong>An automated audit reads every finding.</strong> Each day an automated auditor reads every scanner finding against the code and the published VEX, and writes up what each one needs (<a href="https://github.com/fosterstack/cache/blob/main/.github/workflows/auditor.yml">daily auditor</a>).</li>
+    <li><strong>Exceptions are published statements.</strong> The only way to except a finding is an OpenVEX statement with a justification, kept in the repository and published with each release (<a href="https://github.com/fosterstack/cache/tree/main/.vex/"><code>.vex/</code></a>, <a href="https://github.com/fosterstack/cache/blob/main/docs/scanning.md">scanning.md</a>).</li>
+    <li><strong>Scanner verdicts are signed.</strong> Each scanner's verdict is a signed statement bound to the digests it scanned (<a href="https://github.com/fosterstack/cache/blob/main/docs/verify-images.md">verify-images.md</a>).</li>
+  </ul>
+  <h2>Release</h2>
+  <ul>
+    <li><strong>Signed images.</strong> Every image is signed keylessly by the promotion workflow, in both registries (<a href="https://github.com/fosterstack/cache/blob/main/docs/verify-images.md">verify-images.md</a>).</li>
+    <li><strong>Signed provenance.</strong> Archives, SBOMs and the checksums file carry build provenance naming the CI run that made them (<a href="https://github.com/fosterstack/cache/blob/main/docs/verify-images.md">verify-images.md</a>).</li>
+    <li><strong>An SBOM for every archive</strong>, published with the release (<a href="https://github.com/fosterstack/cache/blob/main/RELEASING.md">RELEASING.md</a>).</li>
+    <li><strong>The VEX document ships with every release</strong> as <code>fosterstack-cache.openvex.json</code> (<a href="https://github.com/fosterstack/cache/blob/main/RELEASING.md#vex-statements">RELEASING.md</a>).</li>
+    <li><strong>One authorization before anything goes public.</strong> A single stage verifies the whole graph, fails closed on anything missing, and signs the approval that promotion requires (<a href="https://github.com/fosterstack/cache/blob/main/.github/workflows/stage-authorize.yml">authorization stage</a>).</li>
+    <li><strong>The release is checked as a customer would.</strong> After promotion the public digests are verified and pulled anonymously, and only then is the release published (<a href="https://github.com/fosterstack/cache/blob/main/.github/workflows/stage-promote.yml">promotion stage</a>).</li>
+    <li><strong>Acceptance runs against the exact artifacts.</strong> The archives and images that ship run the customer scenarios first: Gradle, Maven, Kubernetes and the artifact checks (<a href="https://github.com/fosterstack/cache/blob/main/.github/workflows/acceptance.yml">acceptance</a>, <a href="https://github.com/fosterstack/cache/blob/main/.github/workflows/stage-acceptance-artifacts.yml">artifact acceptance</a>).</li>
+  </ul>
+  <h2>Runtime</h2>
+  <ul>
+    <li><strong>No telemetry and no outbound connections.</strong> The server sends nothing anywhere, and a release test traces the candidate from its first instruction with egress denied to prove it (<a href="https://github.com/fosterstack/cache/blob/main/.github/workflows/stage-acceptance-egress.yml">egress acceptance</a>, <a href="https://github.com/fosterstack/cache/blob/main/SECURITY.md#data-handling">SECURITY.md</a>).</li>
+    <li><strong>No request access log.</strong> The only per-request logging is on failure, and it never carries a body, a credential or a client address (<a href="https://github.com/fosterstack/cache/blob/main/SECURITY.md#data-handling">SECURITY.md</a>).</li>
+  </ul>
+  <h2>Watch</h2>
+  <ul>
+    <li><strong>A daily watch of what we depend on.</strong> Newly published advisories and malicious-package reports about anything we pin are read every day (<a href="https://github.com/fosterstack/cache/blob/main/.github/workflows/supply-chain.yml">supply-chain workflow</a>).</li>
+  </ul>
+  <p class="muted-note">Related: <a href="/how-we-build/">how releases are built and signed</a>, <a href="/verify-a-release/">verify a release yourself</a> and <a href="/security/">the security policy</a>.</p>
+  <p class="muted-note">Moving off the free Build Cache Node? See <a href="/build-cache-node-end-of-life/">what the end of life means</a> and the <a href="/migrate-build-cache-node/">migration guide</a>.</p>
+</main>
+<footer>
+  <div>
+    <p>FosterStack is not affiliated with, endorsed by, or sponsored by Gradle Inc.
+    "Gradle" and "Develocity" are trademarks of Gradle Inc., used here only to identify
+    compatibility. FosterStack contains no Gradle Inc. code; it is a clean-room implementation
+    of the documented remote build cache HTTP protocol. Apache Maven is a trademark of the
+    Apache Software Foundation; the Maven Build Cache Extension is Apache's project, not
+    ours.</p>
+    <p style="margin-top:.6rem">© 2026 FosterStack · <a href="/regulated/">For regulated markets</a> · <a href="https://github.com/fosterstack/cache">github.com/fosterstack/cache</a> · <a href="mailto:hello@fosterstack.com">hello@fosterstack.com</a></p>
+  </div>
+</footer>
+</body>
+</html>
diff --git a/faq/index.html b/faq/index.html
new file mode 100644
index 0000000..6ddf1fe
--- /dev/null
+++ b/faq/index.html
@@ -0,0 +1,134 @@
+<!doctype html>
+<html lang="en">
+<head>
+<meta name="robots" content="noindex, nofollow">
+<meta charset="utf-8">
+<meta name="viewport" content="width=device-width, initial-scale=1">
+<title>FosterStack Cache FAQ: Gradle, Maven, licence, security</title>
+<meta name="description" content="Short answers about FosterStack Cache: what it is, which Gradle and Maven setups it works with, its licence, how to verify a release, and what happens if it is down.">
+<meta property="og:title" content="FosterStack Cache FAQ: Gradle, Maven, licence, security">
+<meta property="og:description" content="Short answers about FosterStack Cache: what it is, which Gradle and Maven setups it works with, its licence, how to verify a release, and what happens if it is down.">
+<meta property="og:url" content="https://fosterstack.com/faq/">
+<meta property="og:type" content="website">
+<meta property="og:site_name" content="FosterStack">
+<link rel="canonical" href="https://fosterstack.com/faq/">
+<link rel="icon" href="/favicon.svg" type="image/svg+xml">
+<link rel="icon" href="/favicon.ico" sizes="any">
+<link rel="apple-touch-icon" href="/apple-touch-icon.png">
+<style>
+  :root {
+    --bg: #ffffff; --fg: #16181d; --muted: #5b6472; --line: #e4e7ec;
+    --accent: #0d7a5f; --accent-fg: #ffffff; --card: #f6f8f9; --warn-bg: #fff7ed; --warn-line: #fdba74;
+    --mark: #0f4d66;
+  }
+  @media (prefers-color-scheme: dark) {
+    :root {
+      --bg: #101318; --fg: #e8eaf0; --muted: #98a2b3; --line: #262c36;
+      --accent: #2fbf95; --accent-fg: #08110e; --card: #171c23; --warn-bg: #241a10; --warn-line: #7c4a12;
+      --mark: #e8eaf0;
+    }
+  }
+  * { margin: 0; padding: 0; box-sizing: border-box; }
+  body {
+    background: var(--bg); color: var(--fg);
+    font: 16px/1.6 system-ui, -apple-system, "Segoe UI", Roboto, sans-serif;
+    -webkit-font-smoothing: antialiased;
+  }
+  main { max-width: 44rem; margin: 0 auto; padding: 0 1.25rem 4rem; }
+  header.site { max-width: 44rem; margin: 0 auto; padding: 1.25rem; display: flex; align-items: baseline; gap: .6rem; }
+  .logo { font-weight: 700; font-size: 1.05rem; letter-spacing: -.01em; }
+  .logo span { color: var(--accent); }
+  .logo .mark { width: 1.2em; height: 1.2em; vertical-align: -.24em; margin-right: .4em; }
+  .tag { color: var(--muted); font-size: .85rem; }
+  .notice {
+    background: var(--warn-bg); border: 1px solid var(--warn-line); border-radius: 8px;
+    padding: .7rem 1rem; font-size: .92rem; margin: 1.5rem 0 2.5rem;
+  }
+  h1 { font-size: 2rem; line-height: 1.2; letter-spacing: -.02em; margin-bottom: 1rem; }
+  .lede { font-size: 1.12rem; color: var(--muted); margin-bottom: 2rem; }
+  h2 { font-size: 1.25rem; margin: 3rem 0 .9rem; letter-spacing: -.01em; }
+  p + p { margin-top: .8rem; }
+  .cards { display: grid; grid-template-columns: repeat(auto-fit, minmax(15rem, 1fr)); gap: .8rem; margin-top: 1rem; }
+  .card { background: var(--card); border: 1px solid var(--line); border-radius: 10px; padding: 1rem 1.1rem; }
+  .card h3 { font-size: .98rem; margin-bottom: .35rem; }
+  .card p { font-size: .9rem; color: var(--muted); }
+  ul.trust { list-style: none; margin-top: .5rem; }
+  ul.trust li { padding: .45rem 0 .45rem 1.6rem; position: relative; }
+  ul.trust li::before { content: "✓"; position: absolute; left: .2rem; color: var(--accent); font-weight: 700; }
+  code, pre { font-family: ui-monospace, "SF Mono", Menlo, monospace; font-size: .88em; }
+  code { background: var(--card); border: 1px solid var(--line); border-radius: 5px; padding: .1em .35em; }
+  pre code { background: none; border: 0; padding: 0; color: inherit; font-size: 1em; }
+  button {
+    padding: .7rem 1.3rem; font-size: 1rem; font-weight: 600; cursor: pointer;
+    background: var(--accent); color: var(--accent-fg); border: 0; border-radius: 8px;
+  }
+  button:disabled { opacity: .6; cursor: default; }
+  table { width: 100%; border-collapse: collapse; font-size: .92rem; margin-top: 1rem; }
+  th, td { text-align: left; padding: .55rem .6rem; border-bottom: 1px solid var(--line); vertical-align: top; }
+  th { font-size: .8rem; text-transform: uppercase; letter-spacing: .04em; color: var(--muted); }
+  pre { background: #0f172a; color: #e2e8f0; padding: .9rem 1rem; border-radius: 8px;
+        overflow-x: auto; font-size: .9rem; line-height: 1.5; }
+  .cta-row { display: flex; gap: .6rem; flex-wrap: wrap; margin-top: 1.1rem; }
+  .btn { display: inline-block; padding: .55rem 1rem; border-radius: 8px; font-weight: 600;
+         text-decoration: none; background: var(--accent); color: var(--accent-fg); }
+  .btn-secondary { background: transparent; color: inherit; border: 1px solid var(--muted); }
+  .muted-note { color: var(--muted); font-size: .93rem; margin-top: 1.1rem; }
+  footer { border-top: 1px solid var(--line); margin-top: 4rem; padding: 1.5rem 1.25rem 3rem; }
+  footer div { max-width: 44rem; margin: 0 auto; color: var(--muted); font-size: .82rem; }
+  a { color: var(--accent); }
+  code { overflow-wrap: anywhere; }
+  pre code { overflow-wrap: normal; }
+  main h3 { font-size: 1.05rem; margin: 2rem 0 .6rem; }
+  .table-scroll { max-width: 100%; overflow-x: auto; }
+  :focus-visible { outline: 3px solid var(--accent); outline-offset: 2px; }
+</style>
+</head>
+<body>
+<header class="site">
+  <div class="logo"><svg class="mark" viewBox="0 0 96 96" aria-hidden="true" focusable="false"><rect x="12" y="14" width="72" height="18" rx="5" fill="var(--mark)"/><rect x="12" y="39" width="48" height="18" rx="5" fill="var(--mark)"/><rect x="12" y="64" width="26" height="18" rx="5" fill="var(--accent)"/></svg>foster<span>stack</span></div>
+  <div class="tag">Infrastructure worth keeping — and kept patched.</div>
+</header>
+<main>
+  <h1>FosterStack Cache FAQ</h1>
+  <p class="lede">Short answers, each with a link to the page that has the detail.</p>
+  <h2>What is FosterStack Cache?</h2>
+  <p>A self-hosted remote build cache for Gradle, and for Maven through the Apache Maven Build Cache Extension. It ships as one static binary or a distroless container image, under the MIT licence. See the <a href="/first-15-minutes-build-cache/">first 15 minutes</a>.</p>
+  <h2>Which Gradle and Maven setups does it work with?</h2>
+  <p>Gradle talks to it with its normal remote build cache setting, so the change is mostly a URL. Maven works through Apache's Build Cache Extension. Our CI builds a real multi-module project with each and checks that the second build restores from the remote cache. See <a href="/maven-remote-build-cache-setup/">Maven setup</a> and <a href="/github-actions-remote-build-cache/">GitHub Actions</a>.</p>
+  <h2>Does it work with Jenkins and other CI systems?</h2>
+  <p>Any runner that can reach the server can use it. It is a plain web server. See <a href="/jenkins-ci-build-cache/">Jenkins and CI build cache</a>.</p>
+  <h2>How do I move from the free Build Cache Node?</h2>
+  <p>Start the new server empty and point your builds at it. A build cache only holds results your build can rebuild, so there is nothing to copy. See the <a href="/migrate-build-cache-node/">migration guide</a> and <a href="/build-cache-node-end-of-life/">what the end of life means</a>.</p>
+  <h2>Is it free?</h2>
+  <p>Yes. Everything you can download today is the free MIT core, including eviction, size limits and metrics. Paid tiers are coming; checkout isn't open yet. See <a href="/#pricing">pricing</a>.</p>
+  <h2>What happens if the cache is down or empty?</h2>
+  <p>Builds are slower, not wrong. Gradle and Maven rebuild what they cannot restore. See <a href="/build-cache-server-down-what-happens/">what happens when the server is down</a>.</p>
+  <h2>Who can write to the cache?</h2>
+  <p>Anyone holding the read-write password. Turn on Basic Auth anywhere untrusted people could reach the port. You can also set a read-only login that can read but never write. See <a href="/gradle-build-cache-ci-writes-developers-read/">CI writes, developers read</a>.</p>
+  <h2>Can someone poison our shared cache?</h2>
+  <p>Only someone who can write to it, so the write login is the control. Read <a href="/can-someone-poison-our-build-cache/">Can someone poison our build cache?</a> for what to restrict.</p>
+  <h2>How do I know a release is the real one?</h2>
+  <p>Every image is keylessly signed, and every binary archive is covered by a signed checksums file. Both carry SLSA provenance. No account is needed. See <a href="/verify-a-release/">Verify a release</a>.</p>
+  <h2>Does it send anything out?</h2>
+  <p>No. The server sends no telemetry and needs no connection to FosterStack. It can run on a network with no route to the internet. See <a href="/air-gapped-build-cache-install/">air-gapped install</a>.</p>
+  <h2>How are security fixes handled?</h2>
+  <p>The current release's images are rescanned daily, so a vulnerability disclosed against bytes we already shipped raises an issue. The policy is in <a href="https://github.com/fosterstack/cache/blob/main/SECURITY.md">SECURITY.md</a>, and <a href="/everything-we-do-for-security/">everything we do for security</a> lists the practices.</p>
+  <h2>Can I run it on Kubernetes or Docker?</h2>
+  <p>Yes. Docker and Kubernetes guides are public, with plain manifests for Kubernetes. There is no Helm chart. See <a href="/gradle-build-cache-kubernetes/">Kubernetes</a> and <a href="/build-cache-docker-compose-production/">Docker Compose with TLS</a>.</p>
+  <h2>Where do I report a problem or ask for something?</h2>
+  <p>Open an issue on <a href="https://github.com/fosterstack/cache/issues">GitHub</a>. There is no signup, form or mailing list.</p>
+  <div class="cta-row"><a class="btn" href="/first-15-minutes-build-cache/">First 15 minutes</a> <a class="btn btn-secondary" href="/guides/">All guides</a></div>
+</main>
+<footer>
+  <div>
+    <p>FosterStack is not affiliated with, endorsed by, or sponsored by Gradle Inc.
+    "Gradle" and "Develocity" are trademarks of Gradle Inc., used here only to identify
+    compatibility. FosterStack contains no Gradle Inc. code; it is a clean-room implementation
+    of the documented remote build cache HTTP protocol. Apache Maven is a trademark of the
+    Apache Software Foundation; the Maven Build Cache Extension is Apache's project, not
+    ours.</p>
+    <p style="margin-top:.6rem">© 2026 FosterStack · <a href="/build-cache-node-end-of-life/">Build Cache Node end of life</a> · <a href="/migrate-build-cache-node/">Migrate</a> · <a href="/build-cache-node-end-of-life/#build-cache-node-faq">FAQ</a> · <a href="/jenkins-ci-build-cache/">CI setup</a> · <a href="/how-we-build/">How we build</a> · <a href="/regulated/">For regulated markets</a> · <a href="https://github.com/fosterstack/cache">github.com/fosterstack/cache</a> · <a href="mailto:hello@fosterstack.com">hello@fosterstack.com</a></p>
+  </div>
+</footer>
+</body>
+</html>
diff --git a/fips-140-3-build-cache/index.html b/fips-140-3-build-cache/index.html
index 5f19091..333dc8a 100644
--- a/fips-140-3-build-cache/index.html
+++ b/fips-140-3-build-cache/index.html
@@ -1,6 +1,7 @@
 <!doctype html>
 <html lang="en">
 <head>
+<meta name="robots" content="noindex, nofollow">
 <meta charset="utf-8">
 <meta name="viewport" content="width=device-width, initial-scale=1">
 <title>FIPS 140-3 build cache: run the FIPS image and confirm it</title>
@@ -87,10 +88,11 @@
 </header>
 <main>
   <h1>FIPS 140-3 build cache: run the FIPS image and confirm it</h1>
-  <p class="lede">FosterStack Cache has a FIPS build that uses Go's validated FIPS 140-3 cryptographic module. This page shows how to run it and how to see for yourself that it is in FIPS mode. The outputs below are from the real 0.2.2 images.</p>
+  <p class="lede">Your contract asks for FIPS-validated cryptography, and you have to show what your build cache actually runs. FosterStack Cache has a FIPS build that uses Go's validated FIPS 140-3 cryptographic module. This page shows how to run it and how to see for yourself that it is in FIPS mode. The outputs below are from the real 0.2.2 images.</p>
+  <p class="muted-note"><strong>DRAFT for v0.3, private preview, not published and never merged before v0.3.0 is live.</strong></p>
 
   <h2>What the FIPS build is</h2>
-  <p>It is the same source as the standard build, compiled so that it uses Go's validated FIPS 140-3 module (CMVP certificate #5247). It is available as a container image tag ending in <code>-fips</code>, and as Linux binaries for amd64 and arm64. There is no macOS FIPS build.</p>
+  <p>It is the same source as the production build, compiled so that it uses Go's validated FIPS 140-3 module (CMVP certificate #5247). It is available as a container image tag ending in <code>-fips</code>, and as Linux binaries for amd64 and arm64, named <code>fscache-fips_X.Y.Z_linux_amd64.tar.gz</code> and <code>fscache-fips_X.Y.Z_linux_arm64.tar.gz</code>. The FIPS image has no shell. There is no macOS FIPS build.</p>
 
   <h2>Run it</h2>
   <pre tabindex="0"><code>docker run -d -p 127.0.0.1:8080:8080 -v fscache-data:/home/nonroot \
@@ -106,7 +108,7 @@ <h2>Confirm it is in FIPS mode</h2>
   &quot;version&quot;: &quot;v0.2.2&quot;,
   &quot;fips140&quot;: true,
   &quot;fips140_note&quot;: &quot;active (Go validated module v1.0.0, CMVP cert #5247)&quot;,</code></pre>
-  <p>The standard image, for comparison, reports it as off:</p>
+  <p>The production image, for comparison, reports it as off:</p>
   <pre tabindex="0"><code>$ curl -s localhost:8080/statusz | grep -E &#x27;version|fips140&#x27;
   &quot;version&quot;: &quot;v0.2.2&quot;,
   &quot;fips140&quot;: false,
@@ -115,8 +117,8 @@ <h2>Confirm it is in FIPS mode</h2>
   <h2>What this tells you, and what it does not</h2>
   <ul class="trust">
     <li>It shows the running program is using Go's validated module. The validation is of that cryptographic module.</li>
-    <li>Our own tests run the whole suite against the FIPS build with the module set to refuse any algorithm it does not approve. That proves the code paths the tests reach. Before publishing, the release runs the released FIPS binary (Linux, amd64) and requires its status page to show the <code>active (Go validated module ...)</code> line. It also starts the FIPS image and stores and fetches a test entry through it. No test yet reads the status page of the running FIPS image, so checking it yourself, as shown above, is still worth doing.</li>
-    <li>FosterStack Cache is not "FedRAMP compliant" or "CMMC compliant". Those attach to your service and your organisation, never to a component you deploy. The FIPS build is validated crypto for your compliance program, not a substitute for it.</li>
+    <li>Our own tests run the whole suite against the FIPS build with the module set to refuse any algorithm it does not approve. That proves the code paths the tests reach. Before a release is published, its pipeline starts both candidate images and reads each status page: the <code>-fips</code> image must report FIPS mode active with module v1.0.0, and the production image must report it off. A release that fails this check is not published. The certificate number is our documented mapping for module v1.0.0, not something a binary reports about itself. Checking it yourself, as shown above, is still worth doing.</li>
+    <li>FosterStack Cache is not "FedRAMP compliant" or "CMMC compliant". Those attach to your service and your organization, never to a component you deploy. The FIPS build is validated crypto for your compliance program, not a substitute for it.</li>
   </ul>
 
   <p class="muted-note">Related: <a href="/regulated/">for teams entering regulated markets</a> and <a href="/security/">security policy</a>. Details: <a href="https://github.com/fosterstack/cache/blob/main/SECURITY.md">SECURITY.md</a>.</p>
@@ -124,6 +126,7 @@ <h2>What this tells you, and what it does not</h2>
     <a class="btn" href="/verify-a-release/">Verify a release yourself</a>
     <a class="btn btn-secondary" href="/">FosterStack home</a>
   </div>
+  <p class="muted-note">Moving off the free Build Cache Node? See <a href="/build-cache-node-end-of-life/">what the end of life means</a> and the <a href="/migrate-build-cache-node/">migration guide</a>.</p>
 </main>
 <footer>
   <div>
diff --git a/first-15-minutes-build-cache/index.html b/first-15-minutes-build-cache/index.html
index 3d92347..393ef93 100644
--- a/first-15-minutes-build-cache/index.html
+++ b/first-15-minutes-build-cache/index.html
@@ -1,6 +1,7 @@
 <!doctype html>
 <html lang="en">
 <head>
+<meta name="robots" content="noindex, nofollow">
 <meta charset="utf-8">
 <meta name="viewport" content="width=device-width, initial-scale=1">
 <title>Your first 15 minutes with a self-hosted build cache</title>
@@ -90,6 +91,7 @@
 <main>
   <h1>Your first 15 minutes with a self-hosted build cache</h1>
   <p class="lede">A checklist from nothing to your first <code>FROM-CACHE</code>, the line Gradle prints when it reuses a stored result. The commands take 20 seconds or less; we timed them on a clean GitHub-hosted machine that had Gradle and Java. Still, plan on about 15 minutes in all, because reading, choosing your values and pointing your own project at the server take you longer than the commands.</p>
+  <p class="muted-note"><strong>DRAFT for v0.3, private preview, not published and never merged before v0.3.0 is live.</strong></p>
 
   <h2>What we timed</h2>
   <div class="table-scroll" role="region" aria-label="Scrollable table" tabindex="0"><table>
@@ -106,7 +108,7 @@ <h2>The checklist</h2>
   <h3>1. Decide where it will run</h3>
   <ul class="trust">
     <li>A machine your CI runners and developers can reach. The server is one small program, and disk is what matters. See <a href="/build-cache-server-sizing/">server sizing</a>.</li>
-    <li>Plan on HTTPS for anything beyond a first try. Gradle sends the password with every request.</li>
+    <li>Plan on HTTPS for anything beyond a first try. Gradle sends the password with every request. Either put a proxy in front, or give the server its own certificate with <code>FSCACHE_TLS_CERT</code> and <code>FSCACHE_TLS_KEY</code> (both or neither).</li>
   </ul>
 
   <h3>2. Download it and check it is ours</h3>
@@ -158,7 +160,7 @@ <h3>6. Build twice and look for FROM-CACHE</h3>
 
   <h3>7. Before you roll it out to a team</h3>
   <ul class="trust">
-    <li>Put it behind HTTPS and give CI the read-write login and everyone else the read-only one: <a href="/gradle-build-cache-ci-writes-developers-read/">let CI write, developers only read</a>.</li>
+    <li>Serve it over HTTPS (a proxy in front, or the server's own TLS) and give CI the read-write login and everyone else the read-only one: <a href="/gradle-build-cache-ci-writes-developers-read/">let CI write, developers only read</a>.</li>
     <li>Watch it: <a href="/is-the-build-cache-server-healthy-what-to-alert-on/#monitor-build-cache-prometheus-grafana">monitoring</a>. Know how it forgets: <a href="/build-cache-eviction-size-limit/">eviction</a>.</li>
     <li>Know how to empty it: <a href="/reset-gradle-build-cache/">reset</a>, and how to move it: <a href="/upgrade-build-cache-server/#back-up-and-restore-build-cache">back up and restore</a>.</li>
   </ul>
diff --git a/gradle-build-cache-ci-writes-developers-read/index.html b/gradle-build-cache-ci-writes-developers-read/index.html
index f0e589d..8fea8f4 100644
--- a/gradle-build-cache-ci-writes-developers-read/index.html
+++ b/gradle-build-cache-ci-writes-developers-read/index.html
@@ -1,6 +1,7 @@
 <!doctype html>
 <html lang="en">
 <head>
+<meta name="robots" content="noindex, nofollow">
 <meta charset="utf-8">
 <meta name="viewport" content="width=device-width, initial-scale=1">
 <title>Let CI write, developers only read: Gradle and Maven cache</title>
@@ -90,6 +91,7 @@
 <main>
   <h1>Let CI write, developers only read the build cache</h1>
   <p class="lede">Anything that can write to your build cache can change what later builds use, so give the right to write to as few machines as possible. This page sets up a cache where CI uploads and developers only download, in Gradle and in Maven, with a read-only login the server enforces.</p>
+  <p class="muted-note"><strong>DRAFT for v0.3, private preview, not published and never merged before v0.3.0 is live.</strong></p>
 
   <h2>Give the server two logins</h2>
   <p>The server takes one read-write login and, optionally, a second read-only login. A client using the read-only one can read cache entries, and any write is refused with a 403.</p>
@@ -174,7 +176,7 @@ <h3>If a developer has no login</h3>
 
   <h2>What this does not give you</h2>
   <p>There is no per-person identity. Everyone who holds the read-write login is the same writer to the server, so keep it to CI. See <a href="/can-someone-poison-our-build-cache/#remote-build-cache-security">who can write to a remote build cache</a> and <a href="/gradle-remote-build-cache-authentication/#gradle-build-cache-http-status-codes">the HTTP status codes</a>. To see why laptops then reuse CI's work, see <a href="/laptop-builds-reuse-ci-build-cache/">your laptop builds reuse what CI already built</a>.</p>
-  <p>Our advice, not a test result: use HTTPS, keep the CI password in your CI secret store and never in the repository.</p>
+  <p>Our advice, not a test result: use HTTPS (behind a proxy, or with the server's own certificate: <code>FSCACHE_TLS_CERT</code> and <code>FSCACHE_TLS_KEY</code>), keep the CI password in your CI secret store and never in the repository.</p>
 
   <h2>How we checked</h2>
   <h3>Gradle run</h3>
diff --git a/gradle-build-cache-corporate-proxy/index.html b/gradle-build-cache-corporate-proxy/index.html
index 0fe4930..af06def 100644
--- a/gradle-build-cache-corporate-proxy/index.html
+++ b/gradle-build-cache-corporate-proxy/index.html
@@ -1,6 +1,7 @@
 <!doctype html>
 <html lang="en">
 <head>
+<meta name="robots" content="noindex, nofollow">
 <meta charset="utf-8">
 <meta name="viewport" content="width=device-width, initial-scale=1">
 <title>Build cache behind a corporate proxy: Gradle and Maven</title>
@@ -90,6 +91,7 @@
 <main>
   <h1>Build cache behind a corporate proxy: Gradle and Maven</h1>
   <p class="lede">Many companies make builds reach the network through a proxy. This page shows how the remote build cache behaves behind one, in Gradle and in Maven: the settings, the ways it goes wrong, and how to tell a proxy problem from a cache problem.</p>
+  <p class="muted-note"><strong>DRAFT for v0.3, private preview, not published and never merged before v0.3.0 is live.</strong></p>
   <p>In our runs Maven behaved differently from Gradle: it did not skip the proxy for loopback addresses. If you test on 127.0.0.1 with Maven, list it in <code>nonProxyHosts</code>: see <a href="#maven-build-cache-corporate-proxy">the Maven section</a>.</p>
 
   <h2>Checklist for Gradle</h2>
@@ -97,7 +99,7 @@ <h2>Checklist for Gradle</h2>
   <ul class="trust">
     <li>Ask for the cache's host and port to be allowed through the proxy (HTTPS).</li>
     <li>Put the proxy lines in <code>gradle.properties</code>, with the <code>systemProp.</code> prefix, and list internal hosts in <code>nonProxyHosts</code>.</li>
-    <li>Use HTTPS to the cache. See <a href="/build-cache-docker-compose-production/">a production setup with nginx and TLS</a>.</li>
+    <li>Use HTTPS to the cache: <a href="/build-cache-docker-compose-production/">a production setup with nginx and TLS</a>, or the server's own certificate (<code>FSCACHE_TLS_CERT</code> and <code>FSCACHE_TLS_KEY</code>).</li>
     <li>If the proxy re-signs TLS, Java will need your company's certificate authority.</li>
   </ul>
 
diff --git a/gradle-build-cache-kubernetes/index.html b/gradle-build-cache-kubernetes/index.html
index c06bf8e..db046da 100644
--- a/gradle-build-cache-kubernetes/index.html
+++ b/gradle-build-cache-kubernetes/index.html
@@ -1,6 +1,7 @@
 <!doctype html>
 <html lang="en">
 <head>
+<meta name="robots" content="noindex, nofollow">
 <meta charset="utf-8">
 <meta name="viewport" content="width=device-width, initial-scale=1">
 <title>Gradle build cache on Kubernetes (no Helm chart yet)</title>
@@ -88,6 +89,7 @@
 <main>
   <h1>Gradle build cache on Kubernetes: plain manifests, no Helm chart yet</h1>
   <p class="lede">Run a shared build cache in your cluster with plain manifests: one Deployment, one volume, one Service. There is no Helm chart yet. It has not been through a beta on a production cluster, so treat it that way.</p>
+  <p class="muted-note"><strong>DRAFT for v0.3, private preview, not published and never merged before v0.3.0 is live.</strong></p>
 
   <h2>Is there a Helm chart?</h2>
   <p>Not yet. Today the supported way to deploy on Kubernetes is the plain manifests in the <a href="https://github.com/fosterstack/cache/blob/main/docs/kubernetes.md">Kubernetes guide</a>: a Secret, a volume claim, a Deployment and a Service. Copy them into one file and apply it with <code>kubectl apply -f</code>.</p>
@@ -114,6 +116,8 @@ <h2>Locked down by default</h2>
 
   <h2>Runners in the same cluster</h2>
   <p>If your CI runners already run in this cluster, including Jenkins agents, GitHub Actions runner controller and GitLab runners, you need no load balancer and no ingress. Point Gradle at the cluster-internal name, for example <code>http://fscache.fscache-ns.svc.cluster.local/</code>, with <code>isAllowInsecureProtocol = true</code>. Gradle requires that for plain <code>http://</code> addresses. In our test with Gradle 9.8.0, only the literal <code>127.0.0.1</code> was let through without it. Here it is reasonable because the traffic never leaves the cluster network. See <a href="/jenkins-ci-build-cache/">Jenkins and CI build cache</a>.</p>
+  <h2>HTTPS: in front, or in the server</h2>
+  <p>There are two ways to serve HTTPS, and neither is preferred. <strong>TLS in front:</strong> a load balancer, Gateway or ingress terminates TLS and forwards plain HTTP to the Service, as in the manifests above; the server needs no certificate. <strong>TLS in the server:</strong> set <code>FSCACHE_TLS_CERT</code> and <code>FSCACHE_TLS_KEY</code> to a PEM certificate file and its private key file; the server then serves HTTPS only, on the same port, with TLS 1.2 as the minimum version. A missing, unreadable or mismatched file stops the start with a message naming the variable. Put the certificate in a Secret of type <code>kubernetes.io/tls</code>, mount it read-only, and make it readable by the container's non-root user (65532 in the guide's manifest). We tested neither route on the throwaway cluster.</p>
 
   <h2>Get the manifests</h2>
   <p>The four manifests (Secret, volume claim, Deployment, Service) and the steps to reach the cache from outside the cluster are in the <a href="https://github.com/fosterstack/cache/blob/main/docs/kubernetes.md">Kubernetes guide</a> on GitHub. Copy them into one file and apply it.</p>
@@ -136,6 +140,7 @@ <h2>How we checked</h2>
     <a class="btn" href="https://github.com/fosterstack/cache/blob/main/docs/kubernetes.md">Kubernetes guide</a>
     <a class="btn btn-secondary" href="/migrate-build-cache-node/">Gradle and Maven setup</a>
   </div>
+  <p class="muted-note">Moving off the free Build Cache Node? See <a href="/build-cache-node-end-of-life/">what the end of life means</a> and the <a href="/migrate-build-cache-node/">migration guide</a>.</p>
 </main>
 <footer>
   <div>
diff --git a/gradle-remote-build-cache-authentication/index.html b/gradle-remote-build-cache-authentication/index.html
index 39cdf36..e80b522 100644
--- a/gradle-remote-build-cache-authentication/index.html
+++ b/gradle-remote-build-cache-authentication/index.html
@@ -1,6 +1,7 @@
 <!doctype html>
 <html lang="en">
 <head>
+<meta name="robots" content="noindex, nofollow">
 <meta charset="utf-8">
 <meta name="viewport" content="width=device-width, initial-scale=1">
 <title>Gradle build cache authentication: 401 and status codes</title>
@@ -88,10 +89,11 @@
 <main>
   <h1>Gradle build cache authentication: 401 and status codes</h1>
   <p class="lede">Gradle does not fail the build when the cache refuses it, so a wrong password or a refused upload often shows up only as a status code. FosterStack Cache takes an optional password, and this page shows how to set it, how to give Gradle the right one, and what each status code means.</p>
+  <p class="muted-note"><strong>DRAFT for v0.3, private preview, not published and never merged before v0.3.0 is live.</strong></p>
 
   <h2>Our advice, not a test result</h2>
   <ul class="trust">
-    <li><strong>Use HTTPS.</strong> Gradle sends the password with every request, so over plain HTTP it travels in the clear. Put real servers behind HTTPS.</li>
+    <li><strong>Use HTTPS.</strong> Gradle sends the password with every request, so over plain HTTP it travels in the clear. Serve real servers over HTTPS: behind a proxy, or with the server's own <code>FSCACHE_TLS_CERT</code> and <code>FSCACHE_TLS_KEY</code>.</li>
     <li><strong>Keep the <code>credentials</code> block even where the server has no password.</strong> One config then works against both a test server and a real one.</li>
     <li><strong>Give laptops the read-only login.</strong> That is the intended way to give laptops a cache they can read and not change. Use the read-write login for machines that upload, or set the client not to upload.</li>
   </ul>
diff --git a/gradle-remote-build-cache-private-ca-https/index.html b/gradle-remote-build-cache-private-ca-https/index.html
index ec2df72..d922303 100644
--- a/gradle-remote-build-cache-private-ca-https/index.html
+++ b/gradle-remote-build-cache-private-ca-https/index.html
@@ -1,6 +1,7 @@
 <!doctype html>
 <html lang="en">
 <head>
+<meta name="robots" content="noindex, nofollow">
 <meta charset="utf-8">
 <meta name="viewport" content="width=device-width, initial-scale=1">
 <title>Use your Gradle build cache over HTTPS with a private CA</title>
@@ -89,6 +90,7 @@
 <main>
   <h1>Use your Gradle build cache over HTTPS with a private CA</h1>
   <p class="lede">With the right trust store, Gradle uses a cache behind HTTPS with your own certificate authority, and in our runs the cache hits worked. We ran real builds with a private CA and saw the exact error without it. With the standard Java settings we used, a trust store that held only our CA made Java ignore its normal list of trusted CAs. Our downloads from Maven Central then failed, until we put the normal list into the store as well.</p>
+  <p class="muted-note"><strong>DRAFT for v0.3, private preview, not published and never merged before v0.3.0 is live.</strong></p>
 
   <h2>The short answer</h2>
   <ul class="trust">
@@ -149,7 +151,7 @@ <h2>How we made the test certificates</h2>
   <p>The certificate has to name the address your builds use. We did not test a certificate that names a different host, an expired certificate, the Gradle wrapper (<code>./gradlew</code>), or Linux or Windows.</p>
 
   <h2>If it still does not work</h2>
-  <p>Work through <a href="/gradle-remote-cache-not-working/">Gradle remote build cache not working</a>. For the server side of HTTPS, see <a href="/build-cache-docker-compose-production/">production Docker Compose with nginx and TLS</a>.</p>
+  <p>Work through <a href="/gradle-remote-cache-not-working/">Gradle remote build cache not working</a>. For the server side of HTTPS, see <a href="/build-cache-docker-compose-production/">production Docker Compose with nginx and TLS</a>, which also covers the server's own certificate (<code>FSCACHE_TLS_CERT</code> and <code>FSCACHE_TLS_KEY</code>). The runs on this page used a test TLS proxy; we did not run the server's own TLS.</p>
 
   <p class="muted-note">Run on Gradle 9.8.0 with FosterStack Cache 0.2.1 behind a test TLS proxy, macOS (arm64), Java 27 (Homebrew), OpenSSL 3.6.5.</p>
   <p class="muted-note">We repeated the six runs on a GitHub-hosted Linux machine with release 0.2.2, Gradle 9.8.0, Java 27 (Temurin 27+35) and a small TLS proxy written in Python. All six runs matched the table, including run 5, which fails as expected. The combined store there held 121 certificates, including ours: the count depends on which Java build you use. <a href="https://github.com/fosterstack/www/actions/runs/38037262366">The run and its log are public</a>.</p>
diff --git a/guides/index.html b/guides/index.html
new file mode 100644
index 0000000..2f550a0
--- /dev/null
+++ b/guides/index.html
@@ -0,0 +1,174 @@
+<!doctype html>
+<html lang="en">
+<head>
+<meta name="robots" content="noindex, nofollow">
+<meta charset="utf-8">
+<meta name="viewport" content="width=device-width, initial-scale=1">
+<title>Guides</title>
+<meta name="description" content="DRAFT v0.3.0, not published: every FosterStack Cache guide, grouped by topic.">
+<meta property="og:title" content="Guides">
+<meta property="og:description" content="DRAFT v0.3.0, not published: every FosterStack Cache guide, grouped by topic.">
+<meta property="og:url" content="https://fosterstack.com/guides/">
+<meta property="og:type" content="website">
+<meta property="og:site_name" content="FosterStack">
+<link rel="canonical" href="https://fosterstack.com/guides/">
+<link rel="icon" href="/favicon.svg" type="image/svg+xml">
+<link rel="icon" href="/favicon.ico" sizes="any">
+<link rel="apple-touch-icon" href="/apple-touch-icon.png">
+<style>
+  :root {
+    --bg: #ffffff; --fg: #16181d; --muted: #5b6472; --line: #e4e7ec;
+    --accent: #0d7a5f; --accent-fg: #ffffff; --card: #f6f8f9; --warn-bg: #fff7ed; --warn-line: #fdba74;
+    --mark: #0f4d66;
+  }
+  @media (prefers-color-scheme: dark) {
+    :root {
+      --bg: #101318; --fg: #e8eaf0; --muted: #98a2b3; --line: #262c36;
+      --accent: #2fbf95; --accent-fg: #08110e; --card: #171c23; --warn-bg: #241a10; --warn-line: #7c4a12;
+      --mark: #e8eaf0;
+    }
+  }
+  * { margin: 0; padding: 0; box-sizing: border-box; }
+  body {
+    background: var(--bg); color: var(--fg);
+    font: 16px/1.6 system-ui, -apple-system, "Segoe UI", Roboto, sans-serif;
+    -webkit-font-smoothing: antialiased;
+  }
+  main { max-width: 44rem; margin: 0 auto; padding: 0 1.25rem 4rem; }
+  header.site { max-width: 44rem; margin: 0 auto; padding: 1.25rem; display: flex; align-items: baseline; gap: .6rem; }
+  .logo { font-weight: 700; font-size: 1.05rem; letter-spacing: -.01em; }
+  .logo span { color: var(--accent); }
+  .logo .mark { width: 1.2em; height: 1.2em; vertical-align: -.24em; margin-right: .4em; }
+  .tag { color: var(--muted); font-size: .85rem; }
+  .notice {
+    background: var(--warn-bg); border: 1px solid var(--warn-line); border-radius: 8px;
+    padding: .7rem 1rem; font-size: .92rem; margin: 1.5rem 0 2.5rem;
+  }
+  h1 { font-size: 2rem; line-height: 1.2; letter-spacing: -.02em; margin-bottom: 1rem; }
+  .lede { font-size: 1.12rem; color: var(--muted); margin-bottom: 2rem; }
+  h2 { font-size: 1.25rem; margin: 3rem 0 .9rem; letter-spacing: -.01em; }
+  p + p { margin-top: .8rem; }
+  .cards { display: grid; grid-template-columns: repeat(auto-fit, minmax(15rem, 1fr)); gap: .8rem; margin-top: 1rem; }
+  .card { background: var(--card); border: 1px solid var(--line); border-radius: 10px; padding: 1rem 1.1rem; }
+  .card h3 { font-size: .98rem; margin-bottom: .35rem; }
+  .card p { font-size: .9rem; color: var(--muted); }
+  ul.trust { list-style: none; margin-top: .5rem; }
+  ul.trust li { padding: .45rem 0 .45rem 1.6rem; position: relative; }
+  ul.trust li::before { content: "✓"; position: absolute; left: .2rem; color: var(--accent); font-weight: 700; }
+  code, pre { font-family: ui-monospace, "SF Mono", Menlo, monospace; font-size: .88em; }
+  code { background: var(--card); border: 1px solid var(--line); border-radius: 5px; padding: .1em .35em; }
+  pre code { background: none; border: 0; padding: 0; color: inherit; font-size: 1em; }
+  button {
+    padding: .7rem 1.3rem; font-size: 1rem; font-weight: 600; cursor: pointer;
+    background: var(--accent); color: var(--accent-fg); border: 0; border-radius: 8px;
+  }
+  button:disabled { opacity: .6; cursor: default; }
+  table { width: 100%; border-collapse: collapse; font-size: .92rem; margin-top: 1rem; }
+  th, td { text-align: left; padding: .55rem .6rem; border-bottom: 1px solid var(--line); vertical-align: top; }
+  th { font-size: .8rem; text-transform: uppercase; letter-spacing: .04em; color: var(--muted); }
+  pre { background: #0f172a; color: #e2e8f0; padding: .9rem 1rem; border-radius: 8px;
+        overflow-x: auto; font-size: .9rem; line-height: 1.5; }
+  .cta-row { display: flex; gap: .6rem; flex-wrap: wrap; margin-top: 1.1rem; }
+  .btn { display: inline-block; padding: .55rem 1rem; border-radius: 8px; font-weight: 600;
+         text-decoration: none; background: var(--accent); color: var(--accent-fg); }
+  .btn-secondary { background: transparent; color: inherit; border: 1px solid var(--muted); }
+  .muted-note { color: var(--muted); font-size: .93rem; margin-top: 1.1rem; }
+  footer { border-top: 1px solid var(--line); margin-top: 4rem; padding: 1.5rem 1.25rem 3rem; }
+  footer div { max-width: 44rem; margin: 0 auto; color: var(--muted); font-size: .82rem; }
+  a { color: var(--accent); }
+
+  ol.steps { margin: .6rem 0 0 1.3rem; }
+  ol.steps li { padding: .3rem 0; }
+  code { overflow-wrap: anywhere; }
+  pre code { overflow-wrap: normal; }
+  :focus-visible { outline: 3px solid var(--accent); outline-offset: 2px; }
+</style>
+</head>
+<body>
+<header class="site">
+  <div class="logo"><svg class="mark" viewBox="0 0 96 96" aria-hidden="true" focusable="false"><rect x="12" y="14" width="72" height="18" rx="5" fill="var(--mark)"/><rect x="12" y="39" width="48" height="18" rx="5" fill="var(--mark)"/><rect x="12" y="64" width="26" height="18" rx="5" fill="var(--accent)"/></svg>foster<span>stack</span></div>
+  <div class="tag">Infrastructure worth keeping — and kept patched.</div>
+</header>
+<main>
+  <h1>Guides</h1>
+  <h2>Start here</h2>
+  <ul class="trust">
+    <li><a href="/what-to-verify-in-a-replacement-build-cache/">What to verify in a replacement build cache</a></li>
+    <li><a href="/is-a-remote-build-cache-worth-it/">Is a remote build cache worth it? What we measured</a></li>
+    <li><a href="/faq/">FosterStack Cache FAQ: Gradle, Maven, licence, security</a></li>
+    <li><a href="/first-15-minutes-build-cache/">Your first 15 minutes with a self-hosted build cache</a></li>
+    <li><a href="/migrate-build-cache-node/">Migrate from Build Cache Node: setup, checklist, checks</a></li>
+    <li><a href="/build-cache-node-end-of-life/">Build Cache Node end of life: what happens and your options</a></li>
+    <li><a href="/air-gapped-build-cache-install/">Install on an air-gapped network</a></li>
+    <li><a href="/whats-new-fosterstack-cache-v0-3-0/">What changes in v0.3.0 (draft)</a></li>
+    <li><a href="/changelog/">Changelog</a></li>
+  </ul>
+  <h2>Set it up</h2>
+  <ul class="trust">
+    <li><a href="/github-actions-remote-build-cache/">Use a Remote Build Cache in GitHub Actions</a></li>
+    <li><a href="/jenkins-ci-build-cache/">Jenkins and CI build cache</a></li>
+    <li><a href="/maven-remote-build-cache-setup/">Maven remote build cache setup, on/off, and with Gradle</a></li>
+    <li><a href="/gradle-build-cache-enable-disable/">Enable or Disable the Gradle Build Cache: Flag or Property</a></li>
+    <li><a href="/gradle-build-cache-monorepo/">Gradle build cache: monorepo, buildSrc and included builds</a></li>
+    <li><a href="/maven-build-cache-extension-multi-module/">Maven Build Cache Extension in a Multi-Module Project</a></li>
+    <li><a href="/kotlin-android-gradle-build-cache/">Does the Build Cache Work With Kotlin and Android Builds?</a></li>
+    <li><a href="/gradle-build-cache-docker-ci-fresh-container/">Reuse Gradle results in Docker CI, even in fresh containers</a></li>
+    <li><a href="/gradle-build-cache-ci-writes-developers-read/">Let CI write, developers only read: Gradle and Maven cache</a></li>
+    <li><a href="/feature-branches-share-build-cache-with-main/">Can Feature Branches Share the Build Cache With Main?</a></li>
+    <li><a href="/laptop-builds-reuse-ci-build-cache/">Your Laptop Builds Reuse What CI Already Built</a></li>
+    <li><a href="/several-projects-share-one-build-cache-server/">Can Several Projects Share One Build Cache Server?</a></li>
+  </ul>
+  <h2>Run it</h2>
+  <ul class="trust">
+    <li><a href="/build-cache-docker-compose-production/">Production build cache: Docker Compose, nginx and TLS</a></li>
+    <li><a href="/gradle-build-cache-kubernetes/">Gradle build cache on Kubernetes</a></li>
+    <li><a href="/gradle-build-cache-corporate-proxy/">Build cache behind a corporate proxy: Gradle and Maven</a></li>
+    <li><a href="/gradle-remote-build-cache-private-ca-https/">Use your Gradle build cache over HTTPS with a private CA</a></li>
+    <li><a href="/build-cache-server-sizing/">How big a build cache server? CPU, RAM, disk and load</a></li>
+    <li><a href="/build-cache-eviction-size-limit/">Build cache size limit, eviction and a full disk</a></li>
+    <li><a href="/is-the-build-cache-server-healthy-what-to-alert-on/">Is My Build Cache Server Healthy? What to Alert On</a></li>
+    <li><a href="/upgrade-build-cache-server/">Upgrade, back up and move a build cache server</a></li>
+    <li><a href="/restart-build-cache-server-while-builds-run/">Can I Restart the Cache Server While Builds Run?</a></li>
+    <li><a href="/change-build-cache-logins-without-breaking-ci/">Change the Build Cache Logins Without Breaking CI</a></li>
+    <li><a href="/reset-gradle-build-cache/">How to clear or reset a self-hosted build cache</a></li>
+    <li><a href="/build-cache-server-down-what-happens/">What Happens to My Build When the Cache Server Is Down?</a></li>
+    <li><a href="/build-cache-server-wont-start-errors/">Build Cache Server Won't Start: Errors and Fixes</a></li>
+  </ul>
+  <h2>When it misses or fails</h2>
+  <ul class="trust">
+    <li><a href="/gradle-remote-cache-not-working/">Gradle build cache not working or hit rate low: causes</a></li>
+    <li><a href="/build-cache-hit-rate-how-to-measure/">How Do I Know My Build Cache Hit Rate?</a></li>
+    <li><a href="/remote-build-cache-miss-cost/">Does a Remote Cache Slow Your Build When It Misses?</a></li>
+    <li><a href="/why-did-this-task-miss-the-build-cache/">Why Did This One Task Miss the Build Cache?</a></li>
+    <li><a href="/maven-build-cache-extension-not-restoring/">Maven build cache extension not restoring: the causes</a></li>
+    <li><a href="/gradle-remote-build-cache-authentication/">Gradle remote build cache authentication and 401 errors</a></li>
+    <li><a href="/gradle-test-task-from-cache/">Skip tests that passed: Gradle and Maven build cache</a></li>
+  </ul>
+  <h2>Trust it</h2>
+  <ul class="trust">
+    <li><a href="/verify-a-release/">Verify a release yourself: signature, provenance, SBOM, VEX</a></li>
+    <li><a href="/everything-we-do-for-security/">Everything FosterStack does for security</a></li>
+    <li><a href="/scan-fosterstack-cache-image/">Scanning FosterStack in your compliance pipeline</a></li>
+    <li><a href="/how-we-build/">How FosterStack Cache is built and signed</a></li>
+    <li><a href="/how-our-pipeline-maps-to-nist-and-slsa/">NIST SP 800-204C, 800-204D and SLSA: Our Release Pipeline</a></li>
+    <li><a href="/security/">Security policy: how to report a vulnerability</a></li>
+    <li><a href="/fips-140-3-build-cache/">FIPS 140-3 build cache: run the FIPS image and confirm it</a></li>
+    <li><a href="/can-someone-poison-our-build-cache/">Can Someone Poison Our Shared Build Cache?</a></li>
+    <li><a href="/failed-or-cancelled-build-bad-results-in-cache/">Can a Failed or Cancelled Build Poison the Cache?</a></li>
+    <li><a href="/does-build-cache-entry-contain-source-code-or-secrets/">Does a Build Cache Entry Contain My Source Code or Secrets?</a></li>
+    <li><a href="/what-gradle-stores-in-build-cache/">What does the build cache store? Gradle and Maven</a></li>
+  </ul>
+</main>
+<footer>
+  <div>
+    <p>FosterStack is not affiliated with, endorsed by, or sponsored by Gradle Inc.
+    "Gradle" and "Develocity" are trademarks of Gradle Inc., used here only to identify
+    compatibility. FosterStack contains no Gradle Inc. code; it is a clean-room implementation
+    of the documented remote build cache HTTP protocol. Apache Maven is a trademark of the
+    Apache Software Foundation; the Maven Build Cache Extension is Apache's project, not
+    ours.</p>
+    <p style="margin-top:.6rem">© 2026 FosterStack · <a href="/regulated/">For regulated markets</a> · <a href="https://github.com/fosterstack/cache">github.com/fosterstack/cache</a> · <a href="mailto:hello@fosterstack.com">hello@fosterstack.com</a></p>
+  </div>
+</footer>
+</body>
+</html>
diff --git a/how-our-pipeline-maps-to-nist-and-slsa/index.html b/how-our-pipeline-maps-to-nist-and-slsa/index.html
index d01decc..01417e1 100644
--- a/how-our-pipeline-maps-to-nist-and-slsa/index.html
+++ b/how-our-pipeline-maps-to-nist-and-slsa/index.html
@@ -1,12 +1,13 @@
 <!doctype html>
 <html lang="en">
 <head>
+<meta name="robots" content="noindex, nofollow">
 <meta charset="utf-8">
 <meta name="viewport" content="width=device-width, initial-scale=1">
-<title>NIST SP 800-204C, 800-204D and SLSA: Our Release Pipeline</title>
-<meta name="description" content="How the FosterStack Cache release pipeline maps to NIST SP 800-204C and 800-204D, stage by stage, and why we assess v0.2.2 at SLSA Build Level 2, not Level 3.">
-<meta property="og:title" content="NIST SP 800-204C, 800-204D and SLSA: Our Release Pipeline">
-<meta property="og:description" content="How the FosterStack Cache release pipeline maps to NIST SP 800-204C and 800-204D, stage by stage, and why we assess v0.2.2 at SLSA Build Level 2, not Level 3.">
+<title>How our release pipeline maps to NIST and SLSA (draft)</title>
+<meta name="description" content="DRAFT v0.3.0: how the new release pipeline maps to NIST SP 800-204C and 800-204D and SLSA. Not published.">
+<meta property="og:title" content="How our release pipeline maps to NIST and SLSA (draft)">
+<meta property="og:description" content="DRAFT v0.3.0: how the new release pipeline maps to NIST SP 800-204C and 800-204D and SLSA. Not published.">
 <meta property="og:url" content="https://fosterstack.com/how-our-pipeline-maps-to-nist-and-slsa/">
 <meta property="og:type" content="website">
 <meta property="og:site_name" content="FosterStack">
@@ -87,156 +88,27 @@
   <div class="tag">Infrastructure worth keeping — and kept patched.</div>
 </header>
 <main>
-  <h1>How our release pipeline maps to NIST SP 800-204C, 800-204D and SLSA</h1>
-  <p class="lede">This page takes the release pipeline that built FosterStack Cache v0.2.2 and puts each stage next to the NIST practice it maps to. It says where a stage only partly implements a practice, and it says which SLSA Build level we assess v0.2.2 at: Level 2, not Level 3.</p>
-  <p><strong>This is guidance we followed when designing the pipeline. It is not a certification.</strong></p>
-  <p class="muted-note">Words used here:</p>
-  <ul class="muted-note">
-    <li><strong>SBOM</strong>: a parts list of what is inside a build.</li>
-    <li><strong>VEX</strong>: a note on whether a known flaw affects us.</li>
-    <li><strong>Provenance</strong>: a signed record of how and where something was built.</li>
-    <li><strong>Digest</strong>: the fingerprint of a file or image.</li>
-    <li><strong>SLSA</strong>: a public scale for how far you can trust the way software was built. Its Build track runs from Level 0 to Level 3.</li>
-  </ul>
-  
-
-  <h2>The two NIST documents</h2>
-  <ul>
-    <li><strong>NIST SP 800-204C</strong>, Implementation of DevSecOps for a Microservices-based Application with Service Mesh. We use its pipeline sections, mainly sections 4.6 and 4.8.</li>
-    <li><strong>NIST SP 800-204D</strong>, Strategies for the Integration of Software Supply Chain Security in DevSecOps CI/CD Pipelines. We use sections 4 and 5, mainly sections 5.1.1 and 5.2.</li>
-  </ul>
-  <p>Parts of both documents cover running services in your own cluster, such as service mesh and GitOps. That is your environment, not our release pipeline, so this page does not map it.</p>
-
-  <h2>Stage by stage: what runs, and which practice it maps to</h2>
-  <p>This describes the workflow files as they were at the v0.2.2 tag. What changed since v0.2.1 is listed after the table. "Signs" means the stage records what it did and signs it, with a short-lived key and no stored signing key. The signature is tied to that stage's own workflow and logged in a public transparency log.</p>
+  <h1>How the v0.3.0 release pipeline maps to NIST and SLSA</h1>
+  <p>If you have to explain our release pipeline to a security reviewer, start here. This page does two jobs: how each stage lines up with NIST SP 800-204C and 800-204D, and how the pipeline lines up with SLSA.</p>
+  <p class="muted-note"><strong>DRAFT for v0.3.0, not published and never merged before v0.3.0 is live.</strong></p>
+  <h2>How we line up with NIST</h2>
+  <p>We used two documents: SP 800-204C (<em>Implementation of DevSecOps for a Microservices-based Application with Service Mesh</em>), mainly sections 3.3, 4.6 and 4.8, and SP 800-204D (<em>Strategies for the Integration of Software Supply Chain Security in DevSecOps CI/CD Pipelines</em>), mainly sections 5.1.1 and 5.2. Both also cover running services in your own cluster; that is your environment, so the table covers our release pipeline only.</p>
+  <p>The stages are described step by step on <a href="/how-we-build/">how we build</a>. "Signs" means the stage records what it did and signs it with a short-lived key, under its own workflow identity, logged in a public transparency log.</p>
   <div class="table-scroll" role="region" aria-label="Scrollable table" tabindex="0"><table>
-    <thead>
-      <tr><th>Stage</th><th>What it does in v0.2.2</th><th>NIST practice</th><th>How much</th></tr>
-    </thead>
+    <thead><tr><th>Stage</th><th>What it does</th><th>NIST practice</th><th>How much</th></tr></thead>
     <tbody>
-      <tr>
-        <td>Source admission</td>
-        <td>The tag must be annotated, signed and strictly named: signed by the owner's key or, for an automatic patch tag only, by the release workflow's own keyless identity. The commit must be signed (by the owner's key, or GitHub's own key for merges made on github.com) and be on <code>main</code>. Every required check must pass on that exact commit or, for the checks that run only on pull requests, on the pull request that produced it. An owner-approved requirements list must exist for the version. The lists of allowed signers and required checks are read from <code>main</code>, not from the tagged commit. Signs.</td>
-        <td>800-204D 5.1.4 "Secure Code Commits" (commit-signing enforcement, COMMIT-REQ-2); 5.1.2 "Secure Pull-Push Operations on Repositories" (automated checks before code is trusted)</td>
-        <td>Partly. There is one maintainer, so no second person reviews or approves a change.</td>
-      </tr>
-      <tr>
-        <td>Build</td>
-        <td>Builds the binaries once on a fresh GitHub-hosted machine with the toolchain pinned, and checks that the dependency files did not change. Writes checksums and an SBOM per archive. Signs a build statement and SLSA provenance.</td>
-        <td>800-204D 5.1.1 "Secure Build"; 800-204C 3.3.3 (SBOM generation and code signing as pipeline tasks)</td>
-        <td>Partly. The signing runs in the same job as the build steps, not in a separate, more trusted process as 5.1.1 asks.</td>
-      </tr>
-      <tr>
-        <td>Image assembly</td>
-        <td>Checks every archive against the signed build statement before opening it. Adds one binary to a base image pinned by digest, with no commands run inside the image, using a BuildKit image that is also pinned by digest. Pushes by digest only, with no version tags, to a separate candidates package. Signs, recording the base digest and binary hashes, plus SLSA provenance.</td>
-        <td>800-204D 4.2: "The inputs and outputs of each build step should be verified"</td>
-        <td>Matches the practice as we read it.</td>
-      </tr>
-      <tr>
-        <td>Reproducibility check</td>
-        <td>Assembles the images again on a separate machine. The digests must match, or the release fails. Signs.</td>
-        <td>No direct match in either document.</td>
-        <td>Not mapped. It repeats the image assembly; it does not rebuild the binaries from source.</td>
-      </tr>
-      <tr>
-        <td>Scans</td>
-        <td>Two scanners with different vulnerability databases run, each on its own machine. They first check the image-assembly and reproducibility statements, then scan every platform image of every variant. One also scans the archives, the other the Go module files. Any finding blocks the release, even the lowest-rated one. For one of the two scanners, a published VEX statement can clear a finding. Each scanner signs its verdict for the exact digests.</td>
-        <td>800-204C 4.8 and 4.8.1 (container image scans, software composition analysis); 800-204D 5.2, DEPLOY_REQ-4 (evidence the image was scanned)</td>
-        <td>Partly. The release pipeline runs no static or dynamic application security testing itself. The signed verdict records a pass, not the full scan report.</td>
-      </tr>
-      <tr>
-        <td>Acceptance tests</td>
-        <td>Run against the exact candidate images: the Linux archives and binaries (macOS archives are checked, not run), the images on both CPU architectures, the image variants, the Gradle and Maven test suites, the Kubernetes setup from our docs, and a test that the server makes no outbound connections. A final job checks that every release-blocking acceptance test in the approved list passed, then signs one statement.</td>
-        <td>800-204C 3.3.1 (tests run in the pipeline; an organisation may choose to stop the pipeline when a test fails); 4.6 (stop further pipeline tasks if a test fails)</td>
-        <td>Matches the practice as we read it. The individual test jobs do not sign their own results.</td>
-      </tr>
-      <tr>
-        <td>Release authorization</td>
-        <td>Verifies every earlier statement: signed by the expected stage, naming this commit and these digests, scan verdicts pass, acceptance results complete. Anything missing stops the release. It also stops the release if a VEX statement says a flaw affects us and no owner acceptance of that risk is recorded. Records each statement's transparency-log entry. Signs the approval.</td>
-        <td>800-204C 4.6: "verify that all required signatures … are present to ensure that no one bypasses the pipeline"; 800-204D 5.1.1 (policy checks that the required attestations are found)</td>
-        <td>Partly. The policy is code in the workflow file, not a separate signed policy document as 5.1.1 describes.</td>
-      </tr>
-      <tr>
-        <td>Promotion and publish</td>
-        <td>Will not start without the signed approval. Copies the approved digests to GitHub's registry and the Docker Hub mirror with no rebuild, and checks the digests did not change. Signs the public images and the checksums file. Publishes the VEX statements in three forms: OpenVEX, scanner suppression rules and CSAF 2.0. Uploads the release files, re-checks the image signatures, the signed checksums and every tag the way a customer would, without credentials, then makes the release page public.</td>
-        <td>800-204D 5.2, DEPLOY-REQ-3 (only an artifact made by the approved build process is cleared)</td>
-        <td>Partly. Promotion only copies the digests named in the signed approval. Enforcing that at deploy time is up to your own environment.</td>
-      </tr>
-      <tr>
-        <td>Signing, across all stages</td>
-        <td>Keyless signing: a short-lived signing identity per stage, no stored signing key, every signature logged publicly.</td>
-        <td>800-204C 4.6: "signing the release artifact during each required CI/CD stage (preferably multi-party signing)"; 800-204D 5.1.1 (attestations signed, stored tamper-proof)</td>
-        <td>Partly. Not multi-party: every signature is made by automation in one repository, run by one maintainer.</td>
-      </tr>
-      <tr>
-        <td>Evidence bundle</td>
-        <td><code>release-manifest.json</code> lists every digest, the hash of the approved requirements list, per-test results, and the transparency-log entry of every statement the authorization verified. It is attached to each image in GitHub's registry as a signed statement and published with the SBOMs, VEX file and signed checksums.</td>
-        <td>800-204D 4 (record provenance, with a way to verify and authenticate it)</td>
-        <td>Matches the practice as we read it. Neither document has a section on VEX.</td>
-      </tr>
+      <tr><td>Build</td><td>Checks that the tag is signed, then builds the binaries and both images once. The image is assembled from those packages, with no base image.</td><td>800-204D 5.1.1 "Secure Build"; 800-204C 3.3.3 (SBOM generation and code signing as pipeline tasks)</td><td>Matches the practice as we read it.</td></tr>
+      <tr><td>Sign</td><td>A separate stage records the build and signs it under its own identity, from the build's digest list only.</td><td>800-204D 5.1.1 (signing outside the build steps); 800-204C 4.6 (signing during each required stage)</td><td>Partly. 4.6 prefers multi-party signing; every signature here is made by automation in one repository.</td></tr>
+      <tr><td>Rebuild</td><td>Assembles the image again, independently, on a separate machine. The digests must match or the release fails.</td><td>No direct match in either document.</td><td>Not mapped. It repeats the image assembly; it does not rebuild the binaries from source.</td></tr>
+      <tr><td>Check</td><td>Scans and acceptance tests run against the exact candidate images, and the stage signs a verdict for those digests.</td><td>800-204C 4.8 and 800-204D 5.2</td><td>Partly. The pipeline runs no static or dynamic application security testing itself, and the signed verdict records a pass, not the full scan report.</td></tr>
+      <tr><td>Release</td><td>Verifies every stage's signature together, then publishes the same digests.</td><td>800-204C 4.6 (verify that all required signatures are present); 800-204D 5.1.1 (policy checks that the required attestations are found) and 5.2 DEPLOY-REQ-3</td><td>Partly. The policy is code in the workflow file, not a separate signed policy document as 5.1.1 describes.</td></tr>
     </tbody>
   </table></div>
-
-  <h2>What changed from v0.2.1 to v0.2.2</h2>
-  <p>The v0.2.2 tag changed 31 workflow files. The build stage and the scan stage did not change. These did:</p>
-  <ul>
-    <li><strong>Admission.</strong> A tag can be signed two ways: with the owner's key, as before, or, for an automatic patch tag only, with the release workflow's own keyless signature, whose certificate must name <code>release.yml</code> on <code>main</code> of this repository for the tagged commit. For such a patch tag the approved requirements list must be byte for byte the one from the line's latest owner-signed tag.</li>
-    <li><strong>Image assembly and reproducibility.</strong> The BuildKit image is pinned by digest.</li>
-    <li><strong>Authorization.</strong> It reads the requirements list that admission chose, and it has the new VEX risk-acceptance check described in the table.</li>
-    <li><strong>Promotion.</strong> It publishes the VEX statements in three forms, takes the release notes of an automatic patch release from the tag message, and records the requirements list it used in the manifest.</li>
-    <li><strong>Acceptance tests.</strong> The two test workflows were merged into one file. The suites are the same, and the four acceptance stage files had small edits.</li>
-    <li><strong>The release workflow.</strong> It also runs on pushes to <code>main</code> and once a day, but on those runs only the new <code>decide</code> and <code>patch-notes</code> jobs can run. A new <code>patch-failed</code> job opens an issue when a release run fails. The release run for v0.2.2 has 19 jobs where the v0.2.1 run had 16, and the three new jobs are not on the build, sign and promote path.</li>
-  </ul>
-
-  <h2>Which SLSA Build level do we assess v0.2.2 at?</h2>
-  <p>We assess v0.2.2 at <strong>SLSA Build Level 2</strong>, against the <a href="https://slsa.dev/spec/v1.0/requirements">SLSA v1.0 requirements</a> and <a href="https://slsa.dev/spec/v1.0/levels">levels</a>. We do not claim Build Level 3.</p>
-  <ul class="trust">
-    <li><strong>Consistent build process (L1).</strong> Met, by our reading. One workflow builds every v0.2 release. Only a tag push starts the build job, and the first stage stops any tag not signed by the owner's key or, for an automatic patch tag, the release workflow's own identity.</li>
-    <li><strong>Provenance exists (L1).</strong> Met, by our reading. SLSA v1 provenance covers the binary archives, their SBOMs, <code>checksums.txt</code>, and the three container images, naming each digest, the source commit and the workflow run.</li>
-    <li><strong>Distribute provenance (L1).</strong> Met, by our reading. It is in GitHub's attestation store, and <code>gh attestation verify</code> returns it.</li>
-    <li><strong>Hosted build platform (L2).</strong> Met, by our reading. The build and image jobs ran on GitHub-hosted <code>ubuntu-latest</code> machines, never on a workstation. The build job's log shows image ubuntu-24.04, version 20261004.327.1.</li>
-    <li><strong>Provenance is authentic (L2).</strong> Met, by our reading. The provenance is signed with a short-lived certificate issued to the building workflow, and the signature is logged in a public transparency log. The image, reproducibility and scan stages check who signed the statement before them. The acceptance tests do not. The build, the release authorization and the publishing step also check the source commit and the tag. You can check them yourself.</li>
-  </ul>
-  <p>Level 3 is not claimed. It asks the build platform to "prevent runs from influencing one another, even within the same project" and to "prevent secret material used to sign the provenance from being accessible to the user-defined build steps". We have not shown either. In v0.2.2 the build job can ask for a signing identity for the whole job, and it also runs this repository's build configuration and compiles its code: the goreleaser hooks and the Go build. The image job can ask for a signing identity too, and it builds this repository's Dockerfiles. So the build steps could reach the signing, and Level 3 needs that kept apart. The build job also restored a GitHub Actions cache written by earlier runs, and we have not shown that other workflows or branches cannot write to it. The spec calls that "cache poisoning" under its "Isolated" requirement. Build Level 3 is not claimed for v0.2.2.</p>
-
-  <h2>What we do not meet</h2>
-  <ul>
-    <li>SLSA Build Level 3.</li>
-    <li>We rely on GitHub-hosted machines being a fresh, isolated machine for each job. We have not checked that ourselves.</li>
-    <li>The promotion job holds the Docker Hub token and also runs helper scripts from this repository, in the same job that signs the public images. We do not describe promotion as isolated.</li>
-    <li>Evidence made by a separate, more trusted process than the build itself (800-204D 5.1.1).</li>
-    <li>A second person: one maintainer writes, approves and releases every change. No review by another person, and no multi-party signing (800-204D 5.1.2, 800-204C 4.6).</li>
-    <li>All signing is automated. 800-204D 5.1.3, written for software update systems, points the same way: multiple keys with threshold trust, and automated keys kept out of roles customers rely on.</li>
-    <li>The acceptance test jobs pass their results to the job that signs them; they do not sign or verify statements themselves.</li>
-    <li>No dynamic application security testing, and no static testing inside the release pipeline.</li>
-    <li>The release policy is workflow code, not a separate signed policy document.</li>
-    <li>The reproducibility check covers image assembly, not a second build of the binaries from source.</li>
-    <li>Promoted images are in the public registries a few steps before the final customer-style checks finish. Only the release page waits for those checks.</li>
-    <li>Scan verdicts are signed, but the full scan reports are not published as release files.</li>
-    <li>Checking provenance with <code>gh attestation verify</code> needs a GitHub token. The <code>cosign</code> checks need no account.</li>
-  </ul>
-
-  <h2>Check it yourself</h2>
-  <p>This checks the SLSA provenance of the v0.2.2 image and the workflow that signed it:</p>
-  <pre tabindex="0"><code>$ gh attestation verify oci://ghcr.io/fosterstack/cache:0.2.2 \
-  --repo fosterstack/cache \
-  --signer-workflow fosterstack/cache/.github/workflows/stage-image.yml</code></pre>
-  <ul class="trust">
-    <li><a href="/verify-a-release/">Verify a release</a>: every check we ran against v0.2.2, with its real output.</li>
-    <li><a href="https://github.com/fosterstack/cache/actions/runs/37957120550">The v0.2.2 release run</a>: 19 jobs, in three attempts. The images were built and authorized in attempt 2, and attempt 3 published them (see <a href="/verify-a-release/">Verify a release</a>).</li>
-    <li><a href="https://github.com/fosterstack/cache/actions/runs/35554556056">The v0.2.1 release run</a>: all 16 jobs.</li>
-    <li><a href="https://github.com/fosterstack/cache/compare/v0.2.1...v0.2.2">What changed from v0.2.1 to v0.2.2</a>, including the workflow files.</li>
-    <li><a href="https://github.com/fosterstack/cache/releases/tag/v0.2.2">The v0.2.2 release</a>: SBOMs, VEX files, signed checksums and <code>release-manifest.json</code>.</li>
-    <li><a href="https://github.com/fosterstack/cache/blob/v0.2.2/RELEASING.md">RELEASING.md at v0.2.2</a>: the pipeline in the maintainer's words.</li>
-    <li><a href="https://github.com/fosterstack/cache/tree/v0.2.2/.github/workflows">The workflow files at v0.2.2</a>, starting with <a href="https://github.com/fosterstack/cache/blob/v0.2.2/.github/workflows/release.yml">release.yml</a> and <a href="https://github.com/fosterstack/cache/blob/v0.2.2/.github/workflows/stage-authorize.yml">stage-authorize.yml</a>.</li>
-  </ul>
-
-  <p class="muted-note">Section numbers refer to the final published versions of NIST SP 800-204C and NIST SP 800-204D. <strong>This is guidance we followed when designing the pipeline. It is not a certification.</strong></p>
-
-  <div class="cta-row">
-    <a class="btn" href="/verify-a-release/">Verify a release</a>
-    <a class="btn btn-secondary" href="/how-we-build/">How we build</a>
-  </div>
+  <p>In one line: signed at every stage, verified together at release.</p>
+  <h2>How we line up with SLSA</h2>
+  <p>SLSA is a public scale for how far you can trust the way software was built. Its Build track runs from Level 0 to Level 3. We assess v0.3.0 at Build Level 3.</p>
+  <p>Level 3 asks that the build runs on a hosted platform and that its provenance, the signed record of how the build ran, cannot be forged by the build itself. Here, the Build stage runs on a hosted CI platform and does not hold the signing identity. The Sign stage receives only the build's digest list, records the build and signs it under its own identity. The Release stage accepts a build only if that signature verifies. You can check this yourself: see <a href="/verify-a-release/">verify a release yourself</a>.</p>
+  <p class="muted-note">Related: <a href="/verify-a-release/">verify a release yourself</a> and <a href="/how-we-build/">how releases are built and signed</a>.</p>
 </main>
 
 <footer>
diff --git a/how-we-build/index.html b/how-we-build/index.html
index 8d171a1..6e9eeca 100644
--- a/how-we-build/index.html
+++ b/how-we-build/index.html
@@ -1,12 +1,13 @@
 <!doctype html>
 <html lang="en">
 <head>
+<meta name="robots" content="noindex, nofollow">
 <meta charset="utf-8">
 <meta name="viewport" content="width=device-width, initial-scale=1">
 <title>How FosterStack Cache is built and signed</title>
-<meta name="description" content="How each release is built in CI, checked, scanned, signed and published, what files you get to verify it, and what we do not claim.">
+<meta name="description" content="DRAFT v0.3.0, not published: how a FosterStack Cache release is built, signed and checked, and how to verify it yourself.">
 <meta property="og:title" content="How FosterStack Cache is built and signed">
-<meta property="og:description" content="How each release is built in CI, checked, scanned, signed and published, what files you get to verify it, and what we do not claim.">
+<meta property="og:description" content="DRAFT v0.3.0, not published: how a FosterStack Cache release is built, signed and checked, and how to verify it yourself.">
 <meta property="og:url" content="https://fosterstack.com/how-we-build/">
 <meta property="og:type" content="website">
 <meta property="og:site_name" content="FosterStack">
@@ -90,20 +91,23 @@
 </header>
 <main>
   <h1>How FosterStack Cache is built and signed</h1>
-  <p class="lede">Every release is built by an automated pipeline, checked, signed, and published with files you can verify yourself. This page says what that means today.</p>
+  <p class="lede">You are about to run our software inside your build pipeline. How do you know the files you run are the ones we built? Every release is signed and checked at every step, and you can verify it yourself. This page says how.</p>
+  <p class="muted-note"><strong>DRAFT for v0.3, private preview, not published and never merged before v0.3.0 is live.</strong></p>
+
+  <h2>We do it to our own pipeline first</h2>
+  <p>We started with a build cache, and we secure our own release pipeline the same way before we ask you to run it.</p>
 
   <h2>Releases are built only in CI</h2>
-  <p>No release file is ever made on a person's laptop, ours included. A release starts when a signed tag is pushed, and there is no manual release path. That is what makes the signatures mean something: nobody can forge a release that GitHub's own build machines never built.</p>
+  <p>No release file is ever made on a person's laptop, ours included. A release starts when a signed tag is pushed, and there is no manual release path. That is what lets the signatures mean something: a release that our CI workflow did not build does not carry its signature.</p>
 
-  <h2>The steps a release goes through</h2>
+  <h2>The stages a release goes through</h2>
+  <p>Signed at every stage, verified together at release. Each stage signs a statement about what it did, each stage checks the one before it, and the Release stage verifies them all together. A signature shows who signed these exact files; it does not show the software has no bugs.</p>
   <ol class="steps">
-    <li><strong>Source check.</strong> The tag and the commit must be signed by an allowed signer, sit on the main branch, and have every required check green.</li>
-    <li><strong>Build.</strong> The binaries are built, with checksums and a software bill of materials for each archive.</li>
-    <li><strong>Container images.</strong> Each image is assembled once, from the unmodified distroless base plus one binary.</li>
-    <li><strong>Reproducibility check.</strong> The image is assembled a second time on a separate machine. The results must be identical, or the release fails.</li>
-    <li><strong>Scans and tests.</strong> Every scanner on our list runs against the exact images. A finding blocks the release unless a published VEX statement explains why it does not apply. The Gradle and Maven acceptance tests run against the same images.</li>
-    <li><strong>Authorization.</strong> One step checks that every earlier step produced signed proof for these exact files. Anything missing stops the release.</li>
-    <li><strong>Publish.</strong> The published images are the same digests that were scanned and tested, promoted without a rebuild, and checked again the way a customer would check them.</li>
+    <li><strong>Build.</strong> The stage first checks that the tag is signed, then builds the binaries and both images, for amd64 and arm64, once. It signs what it built.</li>
+    <li><strong>Sign.</strong> A separate stage, with its own identity, receives only the build's digests, records the build and signs it.</li>
+    <li><strong>Rebuild.</strong> The same commit is built again on a fresh machine and every digest is compared with the first build. Any difference stops the release. It signs its result.</li>
+    <li><strong>Check.</strong> The scanners we list (the list is in the repository), the Gradle and Maven tests and the no-phone-home test run against the exact images, and the stage signs its verdict for those digests. A finding blocks the release unless a published VEX statement explains why it does not apply.</li>
+    <li><strong>Release.</strong> The only stage that can publish. It verifies every earlier signature together, then publishes the same digests that were built and judged, with no rebuild.</li>
   </ol>
   <p class="muted-note">The full description, as the pipeline actually runs, is in <a href="https://github.com/fosterstack/cache/blob/main/RELEASING.md">RELEASING.md</a>.</p>
 
@@ -115,21 +119,22 @@ <h2>What you get with each release</h2>
     <li>A VEX file saying which known vulnerabilities do and do not affect the release.</li>
     <li>A <code>release-manifest.json</code> listing every file and its digest.</li>
   </ul>
-  <p>All of it is public. You do not need an account or a purchase to check any of it. The commands are under "Verifying a release" in <a href="https://github.com/fosterstack/cache/blob/main/RELEASING.md">RELEASING.md</a>.</p>
+  <p>All of it is public. You do not need an account or a purchase to check any of it. The commands are on <a href="/verify-a-release/">verify a release yourself</a>.</p>
 
   <h2>Kept patched</h2>
-  <p>The current release's images are scanned again every day, so a vulnerability disclosed against something we already shipped raises an issue without anyone having to remember to look.</p>
+  <p>The current release's images are scanned again every day, so a vulnerability disclosed against something we already shipped raises an issue without anyone having to remember to look. We keep it patched. Our target for vulnerable dependencies is 48 hours from disclosure (<a href="https://github.com/fosterstack/cache/blob/main/SECURITY.md">the scope is in SECURITY.md</a>); more on the <a href="/security/">security page</a>.</p>
 
   <h2>What we do not claim</h2>
   <ul class="trust">
-    <li>Vulnerable dependencies fixed fast — our target is 48 hours from disclosure (<a href="https://github.com/fosterstack/cache/blob/main/SECURITY.md">the scope is in SECURITY.md</a>).</li>
+        <li>A signature shows who signed these exact files. It does not show the software has no bugs, and it is not a certification by anyone.</li>
     <li>The paid tiers are not built. Everything here is the free MIT core.</li>
   </ul>
 
   <div class="cta-row">
-    <a class="btn" href="https://github.com/fosterstack/cache">FosterStack Cache on GitHub</a>
-    <a class="btn btn-secondary" href="/">FosterStack home</a>
+    <a class="btn" href="/verify-a-release/">Verify a release yourself</a>
+    <a class="btn btn-secondary" href="/how-our-pipeline-maps-to-nist-and-slsa/">How each stage maps to NIST and SLSA</a>
   </div>
+  <p class="muted-note">Moving off the free Build Cache Node? See <a href="/build-cache-node-end-of-life/">what the end of life means</a> and the <a href="/migrate-build-cache-node/">migration guide</a>.</p>
 </main>
 <footer>
   <div>
diff --git a/index.html b/index.html
index 9869a9e..4e10dd0 100644
--- a/index.html
+++ b/index.html
@@ -87,6 +87,10 @@
   <div class="tag">Infrastructure worth keeping — and kept patched.</div>
 </header>
 <main>
+  <p class="lede">
+    We build tools that help you secure your build pipeline. It made sense to start with the build cache. We built FosterStack Cache by meticulously following the security guidance that matters: CISA Secure by Design, NIST SP 800-204C and 800-204D, and SLSA. Where the guidance stops, we kept going: hermetic, reproducible builds, a distroless image, and more. <a href="/everything-we-do-for-security/">Read the full list</a>.
+  </p>
+
   <div class="notice">
     Gradle Inc. has deprecated the free Develocity Build Cache Node: it "will no longer be
     distributed, supported or available after December&nbsp;31,&nbsp;2026." The migration path they
@@ -94,6 +98,7 @@
     <a href="/build-cache-node-end-of-life/">What that means and your options</a>.
   </div>
 
+
   <h1>Fast builds from cache are worth keeping.</h1>
   <p class="lede">
     FosterStack is a self-hosted remote build cache server — a Develocity Build Cache Node
@@ -116,13 +121,6 @@ <h2 id="try">Try it now</h2>
   </p>
   <p class="muted-note">Bugs and questions go to <a href="https://github.com/fosterstack/cache/issues">GitHub issues</a>, which is also where the roadmap is settled.</p>
 
-  <h2>Stay in touch</h2>
-  <p>We do not collect email addresses. To follow the project,
-  <a href="https://github.com/fosterstack/cache">star the repository</a> or use
-  <strong>Watch → Custom → Releases</strong> 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.</p>
-
   <h2>What you get that a bare HTTP endpoint doesn't give you</h2>
   <p>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:</p>
@@ -130,55 +128,14 @@ <h2>What you get that a bare HTTP endpoint doesn't give you</h2>
     <div class="card"><h3>Cache management</h3><p>Size-capped LRU eviction that keeps a busy CI cache healthy without hand-tending — set the cap, and the oldest-unused entries make room.</p></div>
     <div class="card"><h3>Authentication</h3><p>HTTP Basic Auth over TLS, wired the way Gradle and Maven already expect credentials. Constant-time comparison, no credential ever logged.</p></div>
     <div class="card"><h3>Metrics &amp; status</h3><p>Prometheus metrics, a read-only status page with hit rates and size-vs-cap, and a Grafana dashboard in the repo — so you know the cache is earning its keep.</p></div>
-    <div class="card"><h3>Maintenance target</h3><p>Vulnerable dependencies fixed fast — our target is 48 hours from disclosure (<a href="https://github.com/fosterstack/cache/blob/main/SECURITY.md">the scope is in SECURITY.md</a>).</p></div>
-    <div class="card"><h3>Designed against NIST guidance</h3><p>Our release pipeline is designed against NIST SP 800-204C and 800-204D: each stage's result is recorded in a signed statement, and nothing is promoted to the public registries until a signed release authorization has verified every earlier statement. Guidance we designed against, not a certification we hold. <a href="/how-our-pipeline-maps-to-nist-and-slsa/">See how each stage maps</a>.</p></div>
     <div class="card"><h3>30-minute migration</h3><p>A step-by-step guide for existing Build Cache Node deployments. Same protocol, same CI config shape — migrating is mostly a URL change.</p></div>
+    <div class="card"><h3>Verify every release</h3><p>Every step of our release produces signed provenance. When a FosterStack signature verifies, you know it's FosterStack code, a FosterStack build and a FosterStack image, and everything in between. <a href="/how-our-pipeline-maps-to-nist-and-slsa/">See how each stage maps</a>.</p></div>
+    <div class="card"><h3>Air-gapped ready</h3><p>No telemetry. Nothing outbound. It runs the same air-gapped.</p></div>
   </div>
 
-  <h2>More than kept patched.</h2>
-  <ul class="trust">
-    <li>Signed releases you can verify in minutes.</li>
-    <li>Build record, parts list (SBOM) and vulnerability statements published with every release.</li>
-    <li>Scanned before every release. The current release is rescanned every day.</li>
-    <li>Images assembled twice on separate machines; the results must match.</li>
-    <li>Minimal image, no telemetry. FIPS variant available.</li>
-    <li>Vulnerable dependencies fixed fast — our target is 48 hours from disclosure (<a href="https://github.com/fosterstack/cache/blob/main/SECURITY.md">the scope is in SECURITY.md</a>).</li>
-  </ul>
-  <p><a href="/how-we-build/">How we build</a> · <a href="/security/">Security policy</a> · <a href="/verify-a-release/">Verify a release</a></p>
-
-  <h2>Built to be verified, not trusted</h2>
-  <p>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:</p>
-  <ul class="trust">
-    <li>MIT-licensed core. Read the code before you run it.</li>
-    <li>One public container image. Free and paid users pull the identical bytes — scan exactly what you deploy.</li>
-    <li>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.)</li>
-    <li>Security patches are never withheld from the free tier. Not delayed, not embargoed — never.</li>
-    <li>Signed commits, signed releases, public release notes. The repository's SECURITY.md states exactly what the release evidence does and does not prove today.</li>
-  </ul>
-
-  <h2>What we do not collect</h2>
-  <ul class="trust">
-    <li><strong>No telemetry, and no required FosterStack connection.</strong> 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.</li>
-    <li><strong>This website collects no email addresses.</strong> There is no signup
-    form, no waitlist, and no newsletter. It sets no cookies, runs no analytics, and
-    loads nothing from a third party.</li>
-    <li><strong>The only personal data FosterStack LLC holds</strong> is the irreducible
-    minimum required to bill a paying customer — handled by Stripe — and whatever you
-    voluntarily put in an email to support.</li>
-  </ul>
-  <p class="muted-note">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.</p>
-
   <h2 id="pricing">Pricing</h2>
   <p>Per product. Free is the full product.</p>
-  <p>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.</p>
+  <p>Paid tiers are coming; checkout isn't open yet.</p>
   <div class="table-scroll" role="region" aria-label="Scrollable table" tabindex="0"><table>
     <tr><th>Free</th><th>Team</th><th>Business</th><th>Compliance</th></tr>
     <tr>
@@ -189,83 +146,32 @@ <h2 id="pricing">Pricing</h2>
       <td>$199/month — everything in Team, plus HA/replication and priority support with
       the CVE-response target.</td>
       <td>$499/month, billed annually — everything in Business, plus the FIPS 140-3
-      applicability statement, signed per-release attestation letters addressed to you,
-      security-questionnaire support up to 8 hours per year (async), and named-version
-      LTS. <a href="/regulated/">Who this is for.</a></td>
+      applicability statement, a signed monthly attestation letter addressed to you, covering every release that month,
+      and security-questionnaire support up to 8 hours per year (async).
+      <a href="/regulated/">Who this is for.</a></td>
     </tr>
   </table></div>
   <p><strong>No sales call. No per-seat tax. No enterprise pricing mystery.</strong></p>
-  <p style="color:var(--muted); font-size:.95rem">
-    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 <em>for</em> your compliance program.
-  </p>
 
   <h2>Guides</h2>
+  <h3>Start here</h3>
   <ul class="trust">
-    <li><a href="/build-cache-node-end-of-life/">Build Cache Node end of life: what happens and your options</a></li>
-    <li><a href="/migrate-build-cache-node/">Migrate from Build Cache Node: setup, checklist, checks</a></li>
-    <li><a href="/jenkins-ci-build-cache/">Jenkins and CI build cache</a></li>
-    <li><a href="/gradle-remote-cache-not-working/">Gradle build cache not working or hit rate low: causes</a></li>
-    <li><a href="/maven-remote-build-cache-setup/">Maven remote build cache setup, on/off, and with Gradle</a></li>
-    <li><a href="/gradle-build-cache-kubernetes/">Gradle build cache on Kubernetes</a></li>
-    <li><a href="/security/">Security policy: how to report a vulnerability</a></li>
-    <li><a href="/build-cache-server-sizing/">How big a build cache server? CPU, RAM, disk and load</a></li>
-    <li><a href="/air-gapped-build-cache-install/">Install on an air-gapped network</a></li>
-    <li><a href="/how-we-build/">How FosterStack Cache is built and signed</a></li>
-    <li><a href="/verify-a-release/">Verify a release yourself: signature, provenance, SBOM, VEX</a></li>
-    <li><a href="/fips-140-3-build-cache/">FIPS 140-3 build cache: run the FIPS image and confirm it</a></li>
-    <li><a href="/reset-gradle-build-cache/">How to clear or reset a self-hosted build cache</a></li>
-    <li><a href="/changelog/">Changelog</a></li>
-    <li><a href="/build-cache-eviction-size-limit/">Build cache size limit, eviction and a full disk</a></li>
     <li><a href="/first-15-minutes-build-cache/">Your first 15 minutes with a self-hosted build cache</a></li>
-    <li><a href="/laptop-builds-reuse-ci-build-cache/">Your Laptop Builds Reuse What CI Already Built</a></li>
-    <li><a href="/remote-build-cache-miss-cost/">Does a Remote Cache Slow Your Build When It Misses?</a></li>
-    <li><a href="/build-cache-hit-rate-how-to-measure/">How Do I Know My Build Cache Hit Rate?</a></li>
-    <li><a href="/can-someone-poison-our-build-cache/">Can Someone Poison Our Shared Build Cache?</a></li>
-    <li><a href="/build-cache-server-down-what-happens/">What Happens to My Build When the Cache Server Is Down?</a></li>
-    <li><a href="/kotlin-android-gradle-build-cache/">Does the Build Cache Work With Kotlin and Android Builds?</a></li>
-    <li><a href="/feature-branches-share-build-cache-with-main/">Can Feature Branches Share the Build Cache With Main?</a></li>
-    <li><a href="/github-actions-remote-build-cache/">Use a Remote Build Cache in GitHub Actions</a></li>
-    <li><a href="/is-the-build-cache-server-healthy-what-to-alert-on/">Is My Build Cache Server Healthy? What to Alert On</a></li>
-    <li><a href="/restart-build-cache-server-while-builds-run/">Can I Restart the Cache Server While Builds Run?</a></li>
-    <li><a href="/change-build-cache-logins-without-breaking-ci/">Change the Build Cache Logins Without Breaking CI</a></li>
-    <li><a href="/several-projects-share-one-build-cache-server/">Can Several Projects Share One Build Cache Server?</a></li>
-    <li><a href="/failed-or-cancelled-build-bad-results-in-cache/">Can a Failed or Cancelled Build Poison the Cache?</a></li>
-    <li><a href="/does-build-cache-entry-contain-source-code-or-secrets/">Does a Build Cache Entry Contain My Source Code or Secrets?</a></li>
-    <li><a href="/why-did-this-task-miss-the-build-cache/">Why Did This One Task Miss the Build Cache?</a></li>
-    <li><a href="/build-cache-server-wont-start-errors/">Build Cache Server Won't Start: Errors and Fixes</a></li>
-    <li><a href="/gradle-build-cache-ci-writes-developers-read/">Let CI write, developers only read: Gradle and Maven cache</a></li>
-    <li><a href="/gradle-remote-build-cache-authentication/">Gradle remote build cache authentication and 401 errors</a></li>
-    <li><a href="/maven-build-cache-extension-not-restoring/">Maven build cache extension not restoring: the causes</a></li>
+    <li><a href="/migrate-build-cache-node/">Migrate from Build Cache Node</a></li>
+    <li><a href="/build-cache-node-end-of-life/">Build Cache Node end of life</a></li>
+  </ul>
+  <h3>Run it</h3>
+  <ul class="trust">
     <li><a href="/build-cache-docker-compose-production/">Production build cache: Docker Compose, nginx and TLS</a></li>
-    <li><a href="/gradle-build-cache-corporate-proxy/">Build cache behind a corporate proxy: Gradle and Maven</a></li>
-    <li><a href="/gradle-build-cache-enable-disable/">Enable or Disable the Gradle Build Cache: Flag or Property</a></li>
-    <li><a href="/gradle-build-cache-monorepo/">Gradle build cache: monorepo, buildSrc and included builds</a></li>
-    <li><a href="/how-our-pipeline-maps-to-nist-and-slsa/">NIST SP 800-204C, 800-204D and SLSA: Our Release Pipeline</a></li>
-    <li><a href="/maven-build-cache-extension-multi-module/">Maven Build Cache Extension in a Multi-Module Project</a></li>
-    <li><a href="/upgrade-build-cache-server/">Upgrade, back up and move a build cache server</a></li>
-    <li><a href="/gradle-test-task-from-cache/">Skip tests that passed: Gradle and Maven build cache</a></li>
-    <li><a href="/what-gradle-stores-in-build-cache/">What does the build cache store? Gradle and Maven</a></li>
-    <li><a href="/gradle-remote-build-cache-private-ca-https/">Use your Gradle build cache over HTTPS with a private CA</a></li>
-    <li><a href="/gradle-build-cache-docker-ci-fresh-container/">Reuse Gradle results in Docker CI, even in fresh containers</a></li>
+    <li><a href="/gradle-build-cache-kubernetes/">Gradle build cache on Kubernetes</a></li>
+    <li><a href="/air-gapped-build-cache-install/">Install on an air-gapped network</a></li>
   </ul>
-
-  <h2>Roadmap honesty</h2>
-  <p>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 <code>node_modules</code>, <code>~/.m2</code>, and
-  <code>~/.gradle/caches</code> 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,
-  <a href="https://github.com/fosterstack/cache/issues">open an issue</a> — that is what
-  moves the roadmap.</p>
+  <h3>Trust it</h3>
+  <ul class="trust">
+    <li><a href="/verify-a-release/">Verify a release yourself</a></li>
+    <li><a href="/everything-we-do-for-security/">Everything FosterStack does for security</a></li>
+  </ul>
+  <p><a href="/guides/">All guides →</a></p>
 </main>
 <footer>
   <div>
@@ -275,7 +181,7 @@ <h2>Roadmap honesty</h2>
     of the documented remote build cache HTTP protocol. Apache Maven is a trademark of the
     Apache Software Foundation; the Maven Build Cache Extension is Apache's project, not
     ours.</p>
-    <p style="margin-top:.6rem">© 2026 FosterStack · <a href="/build-cache-node-end-of-life/">Build Cache Node end of life</a> · <a href="/migrate-build-cache-node/">Migrate</a> · <a href="/build-cache-node-end-of-life/#build-cache-node-faq">FAQ</a> · <a href="/jenkins-ci-build-cache/">CI setup</a> · <a href="/how-we-build/">How we build</a> · <a href="/regulated/">For regulated markets</a> · <a href="https://github.com/fosterstack/cache">github.com/fosterstack/cache</a> · <a href="mailto:hello@fosterstack.com">hello@fosterstack.com</a></p>
+    <p style="margin-top:.6rem">© 2026 FosterStack · <a href="/build-cache-node-end-of-life/">Build Cache Node end of life</a> · <a href="/migrate-build-cache-node/">Migrate</a> · <a href="/build-cache-node-end-of-life/#build-cache-node-faq">FAQ</a> · <a href="/jenkins-ci-build-cache/">CI setup</a> · <a href="/how-we-build/">How we build</a> · <a href="/regulated/">For regulated markets</a> · <a href="/roadmap/">Roadmap</a> · <a href="https://github.com/fosterstack/cache">github.com/fosterstack/cache</a> · <a href="mailto:hello@fosterstack.com">hello@fosterstack.com</a></p>
   </div>
 </footer>
 </body>
diff --git a/is-a-remote-build-cache-worth-it/index.html b/is-a-remote-build-cache-worth-it/index.html
new file mode 100644
index 0000000..acd213a
--- /dev/null
+++ b/is-a-remote-build-cache-worth-it/index.html
@@ -0,0 +1,139 @@
+<!doctype html>
+<html lang="en">
+<head>
+<meta name="robots" content="noindex, nofollow">
+<meta charset="utf-8">
+<meta name="viewport" content="width=device-width, initial-scale=1">
+<title>Is a remote build cache worth it? What we measured</title>
+<meta name="description" content="Measured numbers for a self-hosted remote build cache: Gradle build times with no cache, an empty cache and a filled one, and what Maven restores, each with a public run.">
+<meta property="og:title" content="Is a remote build cache worth it? What we measured">
+<meta property="og:description" content="Measured numbers for a self-hosted remote build cache: Gradle build times with no cache, an empty cache and a filled one, and what Maven restores, each with a public run.">
+<meta property="og:url" content="https://fosterstack.com/is-a-remote-build-cache-worth-it/">
+<meta property="og:type" content="website">
+<meta property="og:site_name" content="FosterStack">
+<link rel="canonical" href="https://fosterstack.com/is-a-remote-build-cache-worth-it/">
+<link rel="icon" href="/favicon.svg" type="image/svg+xml">
+<link rel="icon" href="/favicon.ico" sizes="any">
+<link rel="apple-touch-icon" href="/apple-touch-icon.png">
+<style>
+  :root {
+    --bg: #ffffff; --fg: #16181d; --muted: #5b6472; --line: #e4e7ec;
+    --accent: #0d7a5f; --accent-fg: #ffffff; --card: #f6f8f9; --warn-bg: #fff7ed; --warn-line: #fdba74;
+    --mark: #0f4d66;
+  }
+  @media (prefers-color-scheme: dark) {
+    :root {
+      --bg: #101318; --fg: #e8eaf0; --muted: #98a2b3; --line: #262c36;
+      --accent: #2fbf95; --accent-fg: #08110e; --card: #171c23; --warn-bg: #241a10; --warn-line: #7c4a12;
+      --mark: #e8eaf0;
+    }
+  }
+  * { margin: 0; padding: 0; box-sizing: border-box; }
+  body {
+    background: var(--bg); color: var(--fg);
+    font: 16px/1.6 system-ui, -apple-system, "Segoe UI", Roboto, sans-serif;
+    -webkit-font-smoothing: antialiased;
+  }
+  main { max-width: 44rem; margin: 0 auto; padding: 0 1.25rem 4rem; }
+  header.site { max-width: 44rem; margin: 0 auto; padding: 1.25rem; display: flex; align-items: baseline; gap: .6rem; }
+  .logo { font-weight: 700; font-size: 1.05rem; letter-spacing: -.01em; }
+  .logo span { color: var(--accent); }
+  .logo .mark { width: 1.2em; height: 1.2em; vertical-align: -.24em; margin-right: .4em; }
+  .tag { color: var(--muted); font-size: .85rem; }
+  .notice {
+    background: var(--warn-bg); border: 1px solid var(--warn-line); border-radius: 8px;
+    padding: .7rem 1rem; font-size: .92rem; margin: 1.5rem 0 2.5rem;
+  }
+  h1 { font-size: 2rem; line-height: 1.2; letter-spacing: -.02em; margin-bottom: 1rem; }
+  .lede { font-size: 1.12rem; color: var(--muted); margin-bottom: 2rem; }
+  h2 { font-size: 1.25rem; margin: 3rem 0 .9rem; letter-spacing: -.01em; }
+  p + p { margin-top: .8rem; }
+  .cards { display: grid; grid-template-columns: repeat(auto-fit, minmax(15rem, 1fr)); gap: .8rem; margin-top: 1rem; }
+  .card { background: var(--card); border: 1px solid var(--line); border-radius: 10px; padding: 1rem 1.1rem; }
+  .card h3 { font-size: .98rem; margin-bottom: .35rem; }
+  .card p { font-size: .9rem; color: var(--muted); }
+  ul.trust { list-style: none; margin-top: .5rem; }
+  ul.trust li { padding: .45rem 0 .45rem 1.6rem; position: relative; }
+  ul.trust li::before { content: "✓"; position: absolute; left: .2rem; color: var(--accent); font-weight: 700; }
+  code, pre { font-family: ui-monospace, "SF Mono", Menlo, monospace; font-size: .88em; }
+  code { background: var(--card); border: 1px solid var(--line); border-radius: 5px; padding: .1em .35em; }
+  pre code { background: none; border: 0; padding: 0; color: inherit; font-size: 1em; }
+  button {
+    padding: .7rem 1.3rem; font-size: 1rem; font-weight: 600; cursor: pointer;
+    background: var(--accent); color: var(--accent-fg); border: 0; border-radius: 8px;
+  }
+  button:disabled { opacity: .6; cursor: default; }
+  table { width: 100%; border-collapse: collapse; font-size: .92rem; margin-top: 1rem; }
+  th, td { text-align: left; padding: .55rem .6rem; border-bottom: 1px solid var(--line); vertical-align: top; }
+  th { font-size: .8rem; text-transform: uppercase; letter-spacing: .04em; color: var(--muted); }
+  pre { background: #0f172a; color: #e2e8f0; padding: .9rem 1rem; border-radius: 8px;
+        overflow-x: auto; font-size: .9rem; line-height: 1.5; }
+  .cta-row { display: flex; gap: .6rem; flex-wrap: wrap; margin-top: 1.1rem; }
+  .btn { display: inline-block; padding: .55rem 1rem; border-radius: 8px; font-weight: 600;
+         text-decoration: none; background: var(--accent); color: var(--accent-fg); }
+  .btn-secondary { background: transparent; color: inherit; border: 1px solid var(--muted); }
+  .muted-note { color: var(--muted); font-size: .93rem; margin-top: 1.1rem; }
+  footer { border-top: 1px solid var(--line); margin-top: 4rem; padding: 1.5rem 1.25rem 3rem; }
+  footer div { max-width: 44rem; margin: 0 auto; color: var(--muted); font-size: .82rem; }
+  a { color: var(--accent); }
+  code { overflow-wrap: anywhere; }
+  pre code { overflow-wrap: normal; }
+  main h3 { font-size: 1.05rem; margin: 2rem 0 .6rem; }
+  .table-scroll { max-width: 100%; overflow-x: auto; }
+  :focus-visible { outline: 3px solid var(--accent); outline-offset: 2px; }
+</style>
+</head>
+<body>
+<header class="site">
+  <div class="logo"><svg class="mark" viewBox="0 0 96 96" aria-hidden="true" focusable="false"><rect x="12" y="14" width="72" height="18" rx="5" fill="var(--mark)"/><rect x="12" y="39" width="48" height="18" rx="5" fill="var(--mark)"/><rect x="12" y="64" width="26" height="18" rx="5" fill="var(--accent)"/></svg>foster<span>stack</span></div>
+  <div class="tag">Infrastructure worth keeping — and kept patched.</div>
+</header>
+<main>
+  <h1>Is a remote build cache worth it?</h1>
+  <p class="lede">On the small projects we measured, a filled cache took about a quarter off a Gradle build, and an empty one cost about a second. Here are the numbers and the runs that produced them. They are from our test projects on a CI machine, so measure your own.</p>
+
+  <h2>Gradle: what a cache saved and what a miss cost</h2>
+  <p>We ran the same Gradle build three ways, seven times each, and timed the whole command.</p>
+  <div class="table-scroll" role="region" aria-label="Scrollable table" tabindex="0"><table>
+    <tr><th>Setup</th><th>Fastest</th><th>Median</th><th>Slowest</th></tr>
+    <tr><td>No remote cache</td><td>17.06 s</td><td>17.54 s</td><td>18.17 s</td></tr>
+    <tr><td>Remote cache, empty (a miss)</td><td>16.83 s</td><td>18.54 s</td><td>18.67 s</td></tr>
+    <tr><td>Remote cache, filled (a hit)</td><td>12.79 s</td><td>13.41 s</td><td>13.60 s</td></tr>
+  </table></div>
+  <p>By the medians, a miss cost about one second (about 6%) and a hit saved about four (about 24%). The miss build was slower in 6 of 7 rounds. <a href="https://github.com/fosterstack/www/actions/runs/37991659900">The run and its log are public</a>.</p>
+  <p class="muted-note">What we ran: a GitHub-hosted CI machine, 4 vCPUs, 16 GB; Gradle 9.8.0, Java 21; FosterStack Cache 0.2.1 on the same machine. The project had 4 modules of 150 generated classes each, and only the compile tasks ran. It compiles quickly and every build also paid Gradle's start-up, so a bigger project may show different percentages. Details: <a href="/remote-build-cache-miss-cost/">does a remote cache slow your build when it misses?</a></p>
+
+  <h2>Maven: what gets restored</h2>
+  <p>For Maven we recorded which modules were restored from the cache and which were built, on a three-module project with Apache's Build Cache Extension. We have not published a Maven timing table, so there is no Maven time saving on this page.</p>
+  <div class="table-scroll" role="region" aria-label="Scrollable table" tabindex="0"><table>
+    <tr><th>Build</th><th>core</th><th>util</th><th>app</th></tr>
+    <tr><td>First build, as CI would do it</td><td>built</td><td>built</td><td>built</td></tr>
+    <tr><td>Another machine, same code</td><td>restored</td><td>restored</td><td>restored</td></tr>
+    <tr><td>Edit inside a method in core</td><td>built</td><td>built</td><td>built</td></tr>
+    <tr><td>A teammate makes the same edit</td><td>restored</td><td>restored</td><td>restored</td></tr>
+    <tr><td>Edit only app</td><td>restored</td><td>restored</td><td>built</td></tr>
+    <tr><td>Edit only util</td><td>restored</td><td>built</td><td>built</td></tr>
+  </table></div>
+  <p>The first person to make a change pays for it; everyone after restores the result. <a href="https://github.com/fosterstack/www/actions/runs/38070836344">The run and its log are public</a>. Details: <a href="/maven-build-cache-extension-multi-module/">Maven Build Cache Extension in a multi-module project</a>.</p>
+
+  <h2>What this tells you, and what it does not</h2>
+  <ul class="trust">
+    <li>A cache that is empty or down makes builds slower, not wrong. See <a href="/build-cache-server-down-what-happens/">what happens when the server is down</a>.</li>
+    <li>Results are from small test projects on one kind of CI machine. We did not test large projects or other CI products.</li>
+    <li>Your saving depends on how much of your build is work that can be skipped. Turn it on in CI first, then read your own hit rate: <a href="/build-cache-hit-rate-how-to-measure/">how to measure it</a>.</li>
+  </ul>
+  <div class="cta-row"><a class="btn" href="/first-15-minutes-build-cache/">First 15 minutes</a> <a class="btn btn-secondary" href="/guides/">All guides</a></div>
+</main>
+<footer>
+  <div>
+    <p>FosterStack is not affiliated with, endorsed by, or sponsored by Gradle Inc.
+    "Gradle" and "Develocity" are trademarks of Gradle Inc., used here only to identify
+    compatibility. FosterStack contains no Gradle Inc. code; it is a clean-room implementation
+    of the documented remote build cache HTTP protocol. Apache Maven is a trademark of the
+    Apache Software Foundation; the Maven Build Cache Extension is Apache's project, not
+    ours.</p>
+    <p style="margin-top:.6rem">© 2026 FosterStack · <a href="/build-cache-node-end-of-life/">Build Cache Node end of life</a> · <a href="/migrate-build-cache-node/">Migrate</a> · <a href="/build-cache-node-end-of-life/#build-cache-node-faq">FAQ</a> · <a href="/jenkins-ci-build-cache/">CI setup</a> · <a href="/how-we-build/">How we build</a> · <a href="/regulated/">For regulated markets</a> · <a href="https://github.com/fosterstack/cache">github.com/fosterstack/cache</a> · <a href="mailto:hello@fosterstack.com">hello@fosterstack.com</a></p>
+  </div>
+</footer>
+</body>
+</html>
diff --git a/is-the-build-cache-server-healthy-what-to-alert-on/index.html b/is-the-build-cache-server-healthy-what-to-alert-on/index.html
index e0a3d94..168c7dd 100644
--- a/is-the-build-cache-server-healthy-what-to-alert-on/index.html
+++ b/is-the-build-cache-server-healthy-what-to-alert-on/index.html
@@ -1,6 +1,7 @@
 <!doctype html>
 <html lang="en">
 <head>
+<meta name="robots" content="noindex, nofollow">
 <meta charset="utf-8">
 <meta name="viewport" content="width=device-width, initial-scale=1">
 <title>Is My Build Cache Server Healthy? What to Alert On</title>
@@ -89,6 +90,7 @@
 <main>
   <h1>Is my build cache server healthy? What to alert on</h1>
   <p class="lede">Watch three things: the server answers, uploads succeed, and builds get hits. FosterStack Cache reports all three, but <code>/healthz</code> alone only says the process is running.</p>
+  <p class="muted-note"><strong>DRAFT for v0.3, private preview, not published and never merged before v0.3.0 is live.</strong></p>
 
   <h2>The short answer</h2>
   <ul style="padding-left:1.25rem">
@@ -129,7 +131,7 @@ <h3>A scrape setting</h3>
   - job_name: fscache
     static_configs:
       - targets: [&#x27;cache.example.com:8080&#x27;]</code></pre>
-  <p>This is a plain example. Use your own address, and HTTPS if you have put the server behind a proxy.</p>
+  <p>This is a plain example. Use your own address, and HTTPS if a proxy fronts the server. With the server's own TLS (<code>FSCACHE_TLS_CERT</code> and <code>FSCACHE_TLS_KEY</code>) the <code>/healthz</code> check moves to <code>https://</code> too.</p>
 
   <h3>The metrics</h3>
   <p>These are the names a running 0.2.1 server reports:</p>
diff --git a/jenkins-ci-build-cache/index.html b/jenkins-ci-build-cache/index.html
index 9046406..c7bd0c8 100644
--- a/jenkins-ci-build-cache/index.html
+++ b/jenkins-ci-build-cache/index.html
@@ -129,6 +129,7 @@ <h2>Check that CI is really using the cache</h2>
     <a class="btn" href="/migrate-build-cache-node/">Gradle and Maven setup</a>
     <a class="btn btn-secondary" href="/">FosterStack home</a>
   </div>
+  <p class="muted-note">Moving off the free Build Cache Node? See <a href="/build-cache-node-end-of-life/">what the end of life means</a> and the <a href="/migrate-build-cache-node/">migration guide</a>.</p>
 </main>
 <footer>
   <div>
diff --git a/laptop-builds-reuse-ci-build-cache/index.html b/laptop-builds-reuse-ci-build-cache/index.html
index a70b19f..8b30f52 100644
--- a/laptop-builds-reuse-ci-build-cache/index.html
+++ b/laptop-builds-reuse-ci-build-cache/index.html
@@ -1,6 +1,7 @@
 <!doctype html>
 <html lang="en">
 <head>
+<meta name="robots" content="noindex, nofollow">
 <meta charset="utf-8">
 <meta name="viewport" content="width=device-width, initial-scale=1">
 <title>Your Laptop Builds Reuse What CI Already Built</title>
@@ -89,6 +90,8 @@
 <main>
   <h1>Your laptop builds reuse what CI already built</h1>
   <p class="lede">CI builds your code, and then your laptop builds the same code again from scratch. FosterStack Cache is a build cache server you run yourself: CI stores its results there, and your laptop takes them instead of redoing the work.</p>
+  <p class="muted-note"><strong>DRAFT for v0.3, private preview, not published and never merged before v0.3.0 is live.</strong></p>
+
 
   <h2>How it works</h2>
   <ol>
@@ -109,6 +112,10 @@ <h2>What has to match</h2>
   </ul>
   <p>Keep those the same on laptops and CI. For what to expect after an upgrade, see <a href="/gradle-remote-cache-not-working/#build-cache-cold-after-gradle-or-maven-upgrade">we upgraded Gradle or Maven and builds got slow</a>. If your laptop still rebuilds, see <a href="/gradle-remote-cache-not-working/#gradle-build-cache-hit-rate-low">why the Gradle hit rate is low</a> or <a href="/maven-build-cache-extension-not-restoring/">why the Maven cache is not restoring</a>. To set it up, see <a href="/maven-remote-build-cache-setup/">Maven remote build cache setup</a> and the Gradle setup in the <a href="/gradle-build-cache-ci-writes-developers-read/">CI-writes page</a>.</p>
 
+  <h2>Can we trust the cache server?</h2>
+  <p>From v0.3.0, releases are signed at every stage and verified together at release, and you can <a href="/verify-a-release/">verify it yourself</a>. Our target for fixing vulnerable dependencies is 48 hours from disclosure; <a href="https://github.com/fosterstack/cache/blob/main/SECURITY.md">the scope is in SECURITY.md</a>.</p>
+  <p>The checks on this page ran on 0.2.x, and in some of them the cache server ran on a Mac. v0.3.0 ships for Linux only; a Mac laptop is a client either way.</p>
+
   <h2>How we checked</h2>
   <div class="table-scroll" role="region" aria-label="Which platform stored and which restored" tabindex="0"><table>
     <thead><tr><th>Stored on</th><th>Restored on</th><th>Gradle</th><th>Maven</th></tr></thead>
diff --git a/llms.txt b/llms.txt
index ef2fe97..a369e32 100644
--- a/llms.txt
+++ b/llms.txt
@@ -51,12 +51,20 @@ verifiable against the CI run that produced them.
 - [Changelog](https://fosterstack.com/changelog/): release notes for v0.1.0, v0.2.1 and v0.2.2.
 - [For regulated markets](https://fosterstack.com/regulated/): the FIPS build and the public release evidence.
 - [Build cache size limit, eviction and a full disk](https://fosterstack.com/build-cache-eviction-size-limit/): What a self-hosted build cache does when it reaches its size cap: least-recently-used eviction, real numbers from a 0.2.1 server, and what an oversized entry gets.
+- [What to verify in a replacement build cache](https://fosterstack.com/what-to-verify-in-a-replacement-build-cache/): A checklist you can run against any replacement build cache: signed releases, provenance, read-only logins, eviction, metrics, air-gapped use and licence.
+- [Is a remote build cache worth it? What we measured](https://fosterstack.com/is-a-remote-build-cache-worth-it/): Measured numbers for a self-hosted remote build cache: Gradle build times with no cache, an empty cache and a filled one, and what Maven restores, each with a public run.
+- [FosterStack Cache FAQ: Gradle, Maven, licence, security](https://fosterstack.com/faq/): Short answers about what it is, what it works with, its licence, verifying a release and what happens if it is down.
 - [Your first 15 minutes with a self-hosted build cache](https://fosterstack.com/first-15-minutes-build-cache/): A checklist from nothing to your first FROM-CACHE with a self-hosted Gradle build cache, with the commands timed on a GitHub-hosted machine, release 0.2.2.
 - [Let CI write, developers only read: Gradle and Maven cache](https://fosterstack.com/gradle-build-cache-ci-writes-developers-read/): Set up a Gradle build cache where CI uploads and laptops only download, with a read-only login the server enforces. Real run on server 0.2.1 and Gradle 9.8.0.
 - [Gradle remote build cache authentication and 401 errors](https://fosterstack.com/gradle-remote-build-cache-authentication/): Put a password on a self-hosted Gradle build cache and give Gradle the right one: env var, gradle.properties or -P, and what a wrong password looks like.
 - [Maven build cache extension not restoring: the causes](https://fosterstack.com/maven-build-cache-extension-not-restoring/): Maven build cache extension builds again instead of restoring from the remote? Causes with real log lines: config placement, saveToRemote, 401 and the local cache.
 - [How big a build cache server? CPU, RAM, disk and load](https://fosterstack.com/build-cache-server-sizing/): CPU, RAM, disk and the size cap.
 - [Air-gapped install](https://fosterstack.com/air-gapped-build-cache-install/): download, verify, transfer, run.
+- [What changes in v0.3.0 (draft)](https://fosterstack.com/whats-new-fosterstack-cache-v0-3-0/): what to check before you upgrade.
+- [Everything FosterStack does for security](https://fosterstack.com/everything-we-do-for-security/): every security practice that runs, one line each, with where to check it.
+- [Scanning FosterStack in your compliance pipeline](https://fosterstack.com/scan-fosterstack-cache-image/): what to expect when you scan the image and how to apply our VEX statements.
+- [Guides](https://fosterstack.com/guides/): every guide, grouped by topic.
+- [Roadmap honesty](https://fosterstack.com/roadmap/): what runs today and what is next.
 - [How FosterStack Cache is built and signed](https://fosterstack.com/how-we-build/): the release steps and what you can verify.
 - [Production build cache: Docker Compose, nginx and TLS](https://fosterstack.com/build-cache-docker-compose-production/): A Compose file for a self-hosted build cache behind nginx with TLS and a password, run for real on 0.2.1 and Gradle 9.8.0, with what was and was not tested.
 - [Build cache behind a corporate proxy: Gradle and Maven](https://fosterstack.com/gradle-build-cache-corporate-proxy/): How Gradle's remote build cache behaves behind a proxy: the settings, the loopback trap, a proxy that refuses, and how to tell it from a cache error. Real run.
@@ -110,8 +118,8 @@ Not yet shipped:
 - The paid tiers. Team ($49/mo: multi-user access control, SSO, per-project
   analytics, email support), Business ($199/mo: adds HA/replication, priority
   support with the CVE-response target), and Compliance ($499/mo billed
-  annually: adds the FIPS applicability statement, signed per-release
-  attestation letters, questionnaire hours, named-version LTS) are described,
+  annually: adds the FIPS applicability statement, a monthly
+  attestation letter covering every release, questionnaire hours) are described,
   not yet purchasable; the license key that unlocks them is not built.
   Everything in the repository is the free MIT core, including the -fips image
   and all release evidence.
diff --git a/maven-remote-build-cache-setup/index.html b/maven-remote-build-cache-setup/index.html
index d530ee5..29b0ad6 100644
--- a/maven-remote-build-cache-setup/index.html
+++ b/maven-remote-build-cache-setup/index.html
@@ -1,6 +1,7 @@
 <!doctype html>
 <html lang="en">
 <head>
+<meta name="robots" content="noindex, nofollow">
 <meta charset="utf-8">
 <meta name="viewport" content="width=device-width, initial-scale=1">
 <title>Maven remote build cache setup, on/off, and with Gradle</title>
@@ -90,6 +91,7 @@
 <main>
   <h1>Maven remote build cache: setup, on/off switches, and Gradle on the same server</h1>
   <p class="lede">Share Maven build results across machines using Apache's Build Cache Extension and a self-hosted cache server. FosterStack Cache is that server, and one server can also serve Gradle. About ten minutes, mostly editing the files and choosing your values. The two builds in step 4 took 9 to 12 seconds together on a GitHub-hosted machine.</p>
+  <p class="muted-note"><strong>DRAFT for v0.3, private preview, not published and never merged before v0.3.0 is live.</strong></p>
 
   <h2>Who owns what</h2>
   <p>The client is Apache's Maven Build Cache Extension. We maintain the server. If your hit rate looks low, that is usually the extension's own project settings (which files count as inputs, what to skip), not the server. Start with the extension's configuration guide.</p>
@@ -124,7 +126,7 @@ <h2>2. Point it at the server, and switch uploads on</h2>
     &lt;/remote&gt;
   &lt;/configuration&gt;
 &lt;/cache&gt;</code></pre>
-  <p>Keep the comment: a cache setting that points at an unfamiliar host looks like data theft to a reviewer without it. Keep the trailing slash on the URL. Use HTTPS for a real server.</p>
+  <p>Keep the comment: a cache setting that points at an unfamiliar host looks like data theft to a reviewer without it. Keep the trailing slash on the URL. Use HTTPS for a real server: behind a proxy, or with the server's own <code>FSCACHE_TLS_CERT</code> and <code>FSCACHE_TLS_KEY</code>.</p>
 
   <h2>3. Add the password, if the server has one</h2>
   <p>In <code>~/.m2/settings.xml</code>, or your CI system's equivalent. The <code>id</code> must match the <code>id</code> in step 2:</p>
@@ -272,6 +274,7 @@ <h2>How we checked</h2>
     <a class="btn" href="/migrate-build-cache-node/">Gradle and Maven setup</a>
     <a class="btn btn-secondary" href="/">FosterStack home</a>
   </div>
+  <p class="muted-note">Moving off the free Build Cache Node? See <a href="/build-cache-node-end-of-life/">what the end of life means</a> and the <a href="/migrate-build-cache-node/">migration guide</a>.</p>
 </main>
 <footer>
   <div>
diff --git a/regulated/index.html b/regulated/index.html
index 5518bfd..556d844 100644
--- a/regulated/index.html
+++ b/regulated/index.html
@@ -1,6 +1,7 @@
 <!doctype html>
 <html lang="en">
 <head>
+<meta name="robots" content="noindex, nofollow">
 <meta charset="utf-8">
 <meta name="viewport" content="width=device-width, initial-scale=1">
 <title>FosterStack for teams entering regulated markets</title>
@@ -87,8 +88,10 @@
   <h1>For teams entering regulated markets</h1>
 
   <p class="lede">
-    FosterStack Cache gives the build-cache part of your pipeline public, checkable evidence: a FIPS 140-3 build, an SBOM, SLSA provenance, signatures and VEX statements. It does not make you compliant.
+    A contract lands with FIPS, SBOM and provenance requirements attached, and your build cache needs paperwork it has never had. FosterStack Cache gives that part of your pipeline public, checkable evidence: a FIPS 140-3 build, an SBOM, build provenance, signatures and VEX statements. It does not make you compliant.
   </p>
+  <p class="muted-note"><strong>DRAFT for v0.3, private preview, not published and never merged before v0.3.0 is live.</strong></p>
+
   <p>
     It usually starts with one customer. A contract lands on the table with
     federal or compliance requirements attached — FIPS-validated cryptography,
@@ -107,7 +110,7 @@ <h2>What our piece does — and does not do</h2>
     build cache. It also serves Maven, through the Apache Maven Build Cache Extension. For that component, we do the evidence work a compliance
     program needs: the <code>-fips</code> build links Go's FIPS 140-3
     validated cryptographic module (CMVP certificate #5247), and every
-    release ships with an SBOM, SLSA provenance, keyless signatures, and
+    release ships with an SBOM, build provenance, keyless signatures, and
     published VEX statements. Our requirements and their evidence are public
     in the repository, criterion by criterion.
   </p>
@@ -117,13 +120,13 @@ <h2>What our piece does — and does not do</h2>
     program</em>: one row of that questionnaire, answered with something written, signed and checkable instead of a shrug.
   </p>
 
-  <h2>More than kept patched.</h2>
+  <h2>What stands behind it</h2>
   <ul class="trust">
-    <li>Signed releases you can verify in minutes.</li>
+    <li>Signed releases you can verify in minutes. How we sign and check our own releases: <a href="/how-we-build/">how we build</a>.</li>
     <li>Build record, parts list (SBOM) and vulnerability statements published with every release.</li>
     <li>Scanned before every release. The current release is rescanned every day.</li>
-    <li>Images assembled twice on separate machines; the results must match.</li>
-    <li>Minimal image, no telemetry. FIPS variant available.</li>
+    <li>The image of every release is assembled a second time, independently; the digests must match.</li>
+    <li>Minimal image with no base image, no telemetry. FIPS variant available, built from the same source as the standard image.</li>
     <li>Vulnerable dependencies fixed fast — our target is 48 hours from disclosure (<a href="https://github.com/fosterstack/cache/blob/main/SECURITY.md">the scope is in SECURITY.md</a>).</li>
   </ul>
   <p><a href="/how-we-build/">How we build</a> · <a href="/security/">Security policy</a> · <a href="/verify-a-release/">Verify a release</a></p>
@@ -147,11 +150,23 @@ <h2>Verify everything yourself first</h2>
     That's the test we invite.
   </p>
   <p>
-    Step-by-step, with the output of each command from a real release:
+    Step by step:
     <a href="/verify-a-release/">Verify a release yourself</a>. To run the
     <code>-fips</code> image and confirm FIPS mode from its own startup log:
     <a href="/fips-140-3-build-cache/">FIPS 140-3 build cache</a>.
   </p>
+
+  <p style="color:var(--muted); font-size:.95rem">
+    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 a monthly attestation letter
+    covering every release, 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 <em>for</em> your compliance program.
+  </p>
 </main>
 <footer>
   <div>
diff --git a/reset-gradle-build-cache/index.html b/reset-gradle-build-cache/index.html
index c42c4ca..369c4a5 100644
--- a/reset-gradle-build-cache/index.html
+++ b/reset-gradle-build-cache/index.html
@@ -130,6 +130,7 @@ <h2>Check it worked</h2>
     <a class="btn" href="/migrate-build-cache-node/">Gradle and Maven setup</a>
     <a class="btn btn-secondary" href="/">FosterStack home</a>
   </div>
+  <p class="muted-note">Moving off the free Build Cache Node? See <a href="/build-cache-node-end-of-life/">what the end of life means</a> and the <a href="/migrate-build-cache-node/">migration guide</a>.</p>
 </main>
 <footer>
   <div>
diff --git a/roadmap/index.html b/roadmap/index.html
new file mode 100644
index 0000000..c74746b
--- /dev/null
+++ b/roadmap/index.html
@@ -0,0 +1,115 @@
+<!doctype html>
+<html lang="en">
+<head>
+<meta name="robots" content="noindex, nofollow">
+<meta charset="utf-8">
+<meta name="viewport" content="width=device-width, initial-scale=1">
+<title>Roadmap honesty</title>
+<meta name="description" content="DRAFT v0.3.0, not published: what runs today, what is next and how to move the roadmap.">
+<meta property="og:title" content="Roadmap honesty">
+<meta property="og:description" content="DRAFT v0.3.0, not published: what runs today, what is next and how to move the roadmap.">
+<meta property="og:url" content="https://fosterstack.com/roadmap/">
+<meta property="og:type" content="website">
+<meta property="og:site_name" content="FosterStack">
+<link rel="canonical" href="https://fosterstack.com/roadmap/">
+<link rel="icon" href="/favicon.svg" type="image/svg+xml">
+<link rel="icon" href="/favicon.ico" sizes="any">
+<link rel="apple-touch-icon" href="/apple-touch-icon.png">
+<style>
+  :root {
+    --bg: #ffffff; --fg: #16181d; --muted: #5b6472; --line: #e4e7ec;
+    --accent: #0d7a5f; --accent-fg: #ffffff; --card: #f6f8f9; --warn-bg: #fff7ed; --warn-line: #fdba74;
+    --mark: #0f4d66;
+  }
+  @media (prefers-color-scheme: dark) {
+    :root {
+      --bg: #101318; --fg: #e8eaf0; --muted: #98a2b3; --line: #262c36;
+      --accent: #2fbf95; --accent-fg: #08110e; --card: #171c23; --warn-bg: #241a10; --warn-line: #7c4a12;
+      --mark: #e8eaf0;
+    }
+  }
+  * { margin: 0; padding: 0; box-sizing: border-box; }
+  body {
+    background: var(--bg); color: var(--fg);
+    font: 16px/1.6 system-ui, -apple-system, "Segoe UI", Roboto, sans-serif;
+    -webkit-font-smoothing: antialiased;
+  }
+  main { max-width: 44rem; margin: 0 auto; padding: 0 1.25rem 4rem; }
+  header.site { max-width: 44rem; margin: 0 auto; padding: 1.25rem; display: flex; align-items: baseline; gap: .6rem; }
+  .logo { font-weight: 700; font-size: 1.05rem; letter-spacing: -.01em; }
+  .logo span { color: var(--accent); }
+  .logo .mark { width: 1.2em; height: 1.2em; vertical-align: -.24em; margin-right: .4em; }
+  .tag { color: var(--muted); font-size: .85rem; }
+  .notice {
+    background: var(--warn-bg); border: 1px solid var(--warn-line); border-radius: 8px;
+    padding: .7rem 1rem; font-size: .92rem; margin: 1.5rem 0 2.5rem;
+  }
+  h1 { font-size: 2rem; line-height: 1.2; letter-spacing: -.02em; margin-bottom: 1rem; }
+  .lede { font-size: 1.12rem; color: var(--muted); margin-bottom: 2rem; }
+  h2 { font-size: 1.25rem; margin: 3rem 0 .9rem; letter-spacing: -.01em; }
+  p + p { margin-top: .8rem; }
+  .cards { display: grid; grid-template-columns: repeat(auto-fit, minmax(15rem, 1fr)); gap: .8rem; margin-top: 1rem; }
+  .card { background: var(--card); border: 1px solid var(--line); border-radius: 10px; padding: 1rem 1.1rem; }
+  .card h3 { font-size: .98rem; margin-bottom: .35rem; }
+  .card p { font-size: .9rem; color: var(--muted); }
+  ul.trust { list-style: none; margin-top: .5rem; }
+  ul.trust li { padding: .45rem 0 .45rem 1.6rem; position: relative; }
+  ul.trust li::before { content: "✓"; position: absolute; left: .2rem; color: var(--accent); font-weight: 700; }
+  code, pre { font-family: ui-monospace, "SF Mono", Menlo, monospace; font-size: .88em; }
+  code { background: var(--card); border: 1px solid var(--line); border-radius: 5px; padding: .1em .35em; }
+  pre code { background: none; border: 0; padding: 0; color: inherit; font-size: 1em; }
+  button {
+    padding: .7rem 1.3rem; font-size: 1rem; font-weight: 600; cursor: pointer;
+    background: var(--accent); color: var(--accent-fg); border: 0; border-radius: 8px;
+  }
+  button:disabled { opacity: .6; cursor: default; }
+  table { width: 100%; border-collapse: collapse; font-size: .92rem; margin-top: 1rem; }
+  th, td { text-align: left; padding: .55rem .6rem; border-bottom: 1px solid var(--line); vertical-align: top; }
+  th { font-size: .8rem; text-transform: uppercase; letter-spacing: .04em; color: var(--muted); }
+  pre { background: #0f172a; color: #e2e8f0; padding: .9rem 1rem; border-radius: 8px;
+        overflow-x: auto; font-size: .9rem; line-height: 1.5; }
+  .cta-row { display: flex; gap: .6rem; flex-wrap: wrap; margin-top: 1.1rem; }
+  .btn { display: inline-block; padding: .55rem 1rem; border-radius: 8px; font-weight: 600;
+         text-decoration: none; background: var(--accent); color: var(--accent-fg); }
+  .btn-secondary { background: transparent; color: inherit; border: 1px solid var(--muted); }
+  .muted-note { color: var(--muted); font-size: .93rem; margin-top: 1.1rem; }
+  footer { border-top: 1px solid var(--line); margin-top: 4rem; padding: 1.5rem 1.25rem 3rem; }
+  footer div { max-width: 44rem; margin: 0 auto; color: var(--muted); font-size: .82rem; }
+  a { color: var(--accent); }
+
+  ol.steps { margin: .6rem 0 0 1.3rem; }
+  ol.steps li { padding: .3rem 0; }
+  code { overflow-wrap: anywhere; }
+  pre code { overflow-wrap: normal; }
+  :focus-visible { outline: 3px solid var(--accent); outline-offset: 2px; }
+</style>
+</head>
+<body>
+<header class="site">
+  <div class="logo"><svg class="mark" viewBox="0 0 96 96" aria-hidden="true" focusable="false"><rect x="12" y="14" width="72" height="18" rx="5" fill="var(--mark)"/><rect x="12" y="39" width="48" height="18" rx="5" fill="var(--mark)"/><rect x="12" y="64" width="26" height="18" rx="5" fill="var(--accent)"/></svg>foster<span>stack</span></div>
+  <div class="tag">Infrastructure worth keeping — and kept patched.</div>
+</header>
+<main>
+  <h1>Roadmap honesty</h1>
+  <p>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 <code>node_modules</code>, <code>~/.m2</code>, and
+  <code>~/.gradle/caches</code> 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,
+  <a href="https://github.com/fosterstack/cache/issues">open an issue</a> — that is what
+  moves the roadmap.</p>
+</main>
+<footer>
+  <div>
+    <p>FosterStack is not affiliated with, endorsed by, or sponsored by Gradle Inc.
+    "Gradle" and "Develocity" are trademarks of Gradle Inc., used here only to identify
+    compatibility. FosterStack contains no Gradle Inc. code; it is a clean-room implementation
+    of the documented remote build cache HTTP protocol. Apache Maven is a trademark of the
+    Apache Software Foundation; the Maven Build Cache Extension is Apache's project, not
+    ours.</p>
+    <p style="margin-top:.6rem">© 2026 FosterStack · <a href="/regulated/">For regulated markets</a> · <a href="https://github.com/fosterstack/cache">github.com/fosterstack/cache</a> · <a href="mailto:hello@fosterstack.com">hello@fosterstack.com</a></p>
+  </div>
+</footer>
+</body>
+</html>
diff --git a/scan-fosterstack-cache-image/index.html b/scan-fosterstack-cache-image/index.html
new file mode 100644
index 0000000..d058187
--- /dev/null
+++ b/scan-fosterstack-cache-image/index.html
@@ -0,0 +1,178 @@
+<!doctype html>
+<html lang="en">
+<head>
+<meta name="robots" content="noindex, nofollow">
+<meta charset="utf-8">
+<meta name="viewport" content="width=device-width, initial-scale=1">
+<title>Scanning FosterStack in your compliance pipeline</title>
+<meta name="description" content="DRAFT v0.3.0, not published: what to expect when you scan the FosterStack Cache image, and how to apply our published VEX statements in your scanner.">
+<meta property="og:title" content="Scanning FosterStack in your compliance pipeline">
+<meta property="og:description" content="DRAFT v0.3.0, not published: what to expect when you scan the FosterStack Cache image, and how to apply our published VEX statements in your scanner.">
+<meta property="og:url" content="https://fosterstack.com/scan-fosterstack-cache-image/">
+<meta property="og:type" content="website">
+<meta property="og:site_name" content="FosterStack">
+<link rel="canonical" href="https://fosterstack.com/scan-fosterstack-cache-image/">
+<link rel="icon" href="/favicon.svg" type="image/svg+xml">
+<link rel="icon" href="/favicon.ico" sizes="any">
+<link rel="apple-touch-icon" href="/apple-touch-icon.png">
+<style>
+  :root {
+    --bg: #ffffff; --fg: #16181d; --muted: #5b6472; --line: #e4e7ec;
+    --accent: #0d7a5f; --accent-fg: #ffffff; --card: #f6f8f9; --warn-bg: #fff7ed; --warn-line: #fdba74;
+    --mark: #0f4d66;
+  }
+  @media (prefers-color-scheme: dark) {
+    :root {
+      --bg: #101318; --fg: #e8eaf0; --muted: #98a2b3; --line: #262c36;
+      --accent: #2fbf95; --accent-fg: #08110e; --card: #171c23; --warn-bg: #241a10; --warn-line: #7c4a12;
+      --mark: #e8eaf0;
+    }
+  }
+  * { margin: 0; padding: 0; box-sizing: border-box; }
+  body {
+    background: var(--bg); color: var(--fg);
+    font: 16px/1.6 system-ui, -apple-system, "Segoe UI", Roboto, sans-serif;
+    -webkit-font-smoothing: antialiased;
+  }
+  main { max-width: 44rem; margin: 0 auto; padding: 0 1.25rem 4rem; }
+  header.site { max-width: 44rem; margin: 0 auto; padding: 1.25rem; display: flex; align-items: baseline; gap: .6rem; }
+  .logo { font-weight: 700; font-size: 1.05rem; letter-spacing: -.01em; }
+  .logo span { color: var(--accent); }
+  .logo .mark { width: 1.2em; height: 1.2em; vertical-align: -.24em; margin-right: .4em; }
+  .tag { color: var(--muted); font-size: .85rem; }
+  .notice {
+    background: var(--warn-bg); border: 1px solid var(--warn-line); border-radius: 8px;
+    padding: .7rem 1rem; font-size: .92rem; margin: 1.5rem 0 2.5rem;
+  }
+  h1 { font-size: 2rem; line-height: 1.2; letter-spacing: -.02em; margin-bottom: 1rem; }
+  .lede { font-size: 1.12rem; color: var(--muted); margin-bottom: 2rem; }
+  h2 { font-size: 1.25rem; margin: 3rem 0 .9rem; letter-spacing: -.01em; }
+  p + p { margin-top: .8rem; }
+  .cards { display: grid; grid-template-columns: repeat(auto-fit, minmax(15rem, 1fr)); gap: .8rem; margin-top: 1rem; }
+  .card { background: var(--card); border: 1px solid var(--line); border-radius: 10px; padding: 1rem 1.1rem; }
+  .card h3 { font-size: .98rem; margin-bottom: .35rem; }
+  .card p { font-size: .9rem; color: var(--muted); }
+  ul.trust { list-style: none; margin-top: .5rem; }
+  ul.trust li { padding: .45rem 0 .45rem 1.6rem; position: relative; }
+  ul.trust li::before { content: "✓"; position: absolute; left: .2rem; color: var(--accent); font-weight: 700; }
+  code, pre { font-family: ui-monospace, "SF Mono", Menlo, monospace; font-size: .88em; }
+  code { background: var(--card); border: 1px solid var(--line); border-radius: 5px; padding: .1em .35em; }
+  pre code { background: none; border: 0; padding: 0; color: inherit; font-size: 1em; }
+  button {
+    padding: .7rem 1.3rem; font-size: 1rem; font-weight: 600; cursor: pointer;
+    background: var(--accent); color: var(--accent-fg); border: 0; border-radius: 8px;
+  }
+  button:disabled { opacity: .6; cursor: default; }
+  table { width: 100%; border-collapse: collapse; font-size: .92rem; margin-top: 1rem; }
+  th, td { text-align: left; padding: .55rem .6rem; border-bottom: 1px solid var(--line); vertical-align: top; }
+  th { font-size: .8rem; text-transform: uppercase; letter-spacing: .04em; color: var(--muted); }
+  pre { background: #0f172a; color: #e2e8f0; padding: .9rem 1rem; border-radius: 8px;
+        overflow-x: auto; font-size: .9rem; line-height: 1.5; }
+  .cta-row { display: flex; gap: .6rem; flex-wrap: wrap; margin-top: 1.1rem; }
+  .btn { display: inline-block; padding: .55rem 1rem; border-radius: 8px; font-weight: 600;
+         text-decoration: none; background: var(--accent); color: var(--accent-fg); }
+  .btn-secondary { background: transparent; color: inherit; border: 1px solid var(--muted); }
+  .muted-note { color: var(--muted); font-size: .93rem; margin-top: 1.1rem; }
+  footer { border-top: 1px solid var(--line); margin-top: 4rem; padding: 1.5rem 1.25rem 3rem; }
+  footer div { max-width: 44rem; margin: 0 auto; color: var(--muted); font-size: .82rem; }
+  a { color: var(--accent); }
+
+  ol.steps { margin: .6rem 0 0 1.3rem; }
+  ol.steps li { padding: .3rem 0; }
+  code { overflow-wrap: anywhere; }
+  pre code { overflow-wrap: normal; }
+  :focus-visible { outline: 3px solid var(--accent); outline-offset: 2px; }
+</style>
+</head>
+<body>
+<header class="site">
+  <div class="logo"><svg class="mark" viewBox="0 0 96 96" aria-hidden="true" focusable="false"><rect x="12" y="14" width="72" height="18" rx="5" fill="var(--mark)"/><rect x="12" y="39" width="48" height="18" rx="5" fill="var(--mark)"/><rect x="12" y="64" width="26" height="18" rx="5" fill="var(--accent)"/></svg>foster<span>stack</span></div>
+  <div class="tag">Infrastructure worth keeping — and kept patched.</div>
+</header>
+<main>
+  <h1>Scanning FosterStack in your compliance pipeline</h1>
+  <p class="muted-note"><strong>DRAFT for v0.3, private preview, not published and never merged before v0.3.0 is live.</strong></p>
+  <p class="lede">Every scanner in <a href="https://github.com/fosterstack/cache/blob/main/.github/policy/scanners.json">the repo's scanner list</a> runs against a snapshot build of every release, and the current release's images are rescanned daily; <a href="https://github.com/fosterstack/cache/blob/main/RELEASING.md"><code>RELEASING.md</code></a> states exactly what the release scan does and does not attach to. This page is about what to expect when <em>you</em> scan our image, since a minimal image scans differently from a typical distro image in ways that surprise people the first time.</p>
+  <h2>What to expect</h2>
+  <p><strong>The production and <code>-fips</code> images report as <code>debian</code> in scanner OS detection</strong>, even though there's no shell, no package manager, and no way to <code>apt-get</code> anything. Confirmed directly against a real build:</p>
+  <pre tabindex="0"><code>$ trivy image ghcr.io/fosterstack/cache:${VER}
+...
+Detected OS   family="debian" version="13.6"
+...
+┌──────────────────────────────────┬──────────┬─────────────────┐
+│              Target               │   Type   │ Vulnerabilities │
+├──────────────────────────────────┼──────────┼─────────────────┤
+│ ghcr.io/fosterstack/cache (debian)│  debian  │        0        │
+├──────────────────────────────────┼──────────┼─────────────────┤
+│ usr/local/bin/fscache             │ gobinary │        0        │
+└──────────────────────────────────┴──────────┴─────────────────┘</code></pre>
+  <p>Google's distroless base ships an intact <code>/etc/os-release</code> deliberately (that's exactly what scanners key OS detection on), and we never strip it. The <code>gobinary</code> row is our own compiled binary, scanned by both tools' Go-module vulnerability catalogers directly.</p>
+  <h2>Package-DB asymmetry — expect this, it isn't a bug</h2>
+  <p>A scratch/distroless image has no package database. That has an asymmetric effect on checks:</p>
+  <ul>
+    <li><strong>"Is forbidden package X present?"</strong> checks — pass vacuously. There's no package manager, so nothing is "installed" in the sense those checks look for.</li>
+    <li><strong>"Is required package X present?"</strong> checks — fail or error, for the same reason.</li>
+  </ul>
+  <p>If you run a benchmark or policy pack written for a full-OS image (Debian, Ubuntu, etc.) against ours, expect confusing partial results — not a finding, just a mismatch between the benchmark's assumptions and a minimal image. Scanner content often has no OS or platform gating by default, so a scanner may score a scratch image against a full distro benchmark and produce results that don't mean what they look like they mean. Don't over-read a scratch image's score against a Debian-shaped policy without checking what each rule verifies.</p>
+  <h2>Exit codes: don't gate on the raw process exit code</h2>
+  <p>Trivy and Grype's exit codes conflate "ran and found something above your threshold" with "could not run at all" in ways that are easy to miss. <strong>Read per-rule verdicts from the results document (JSON/SARIF), never gate a pipeline purely on the raw exit code</strong> — a broken scan and a clean scan can both look like "exit 0" or both look like "exit 1" depending on flags, and conflating them ships a green gate that checks nothing.</p>
+  <h2>The -debug variant</h2>
+  <p>The <code>:debug</code> tag adds a busybox shell for interactive troubleshooting; it is not the image you deploy. Scanning it shows more than the production image, because busybox itself carries a small package surface, and any known finding there that has no fix is published as a VEX statement rather than hidden. The production and <code>-fips</code> images never include busybox.</p>
+  <h2>Using our VEX files in your scanner</h2>
+  <p>Each release carries our exceptions as published statements, generated from one source (<a href="https://github.com/fosterstack/cache/tree/main/.vex/"><code>.vex/</code></a>). Download them from the release page (<code>gh release download v${VER} --repo fosterstack/cache -p 'fosterstack-cache*'</code>) and check them against the signed release manifest as described in <a href="https://github.com/fosterstack/cache/blob/main/docs/verify-images.md">Verify our images</a>. Then apply the form your scanner reads:</p>
+  <div class="table-scroll" role="region" aria-label="Scrollable table" tabindex="0"><table>
+    <thead><tr><th>Your scanner</th><th>File</th><th>How</th></tr></thead>
+    <tbody>
+      <tr><td>Grype</td><td><code>fosterstack-cache.openvex.json</code></td><td><code>grype IMAGE --vex fosterstack-cache.openvex.json</code></td></tr>
+      <tr><td>Trivy</td><td><code>fosterstack-cache.openvex.json</code></td><td><code>trivy image --vex fosterstack-cache.openvex.json IMAGE</code></td></tr>
+      <tr><td>Docker Scout</td><td><code>fosterstack-cache.openvex.json</code></td><td><code>docker scout cves --vex-location fosterstack-cache.openvex.json --vex-author '^FosterStack LLC$' IMAGE</code> (see <a href="https://github.com/fosterstack/cache/blob/main/docs/#docker-scout">Docker Scout</a>)</td></tr>
+      <tr><td>Amazon Inspector</td><td><code>fosterstack-cache-&lt;version&gt;.inspector-filters.json</code></td><td>one suppression rule per statement: <code>aws inspector2 create-filter</code>, one rule per call</td></tr>
+      <tr><td>Google Artifact Analysis</td><td><code>fosterstack-cache-&lt;version&gt;.csaf.json</code></td><td><code>gcloud artifacts vulnerabilities load-vex</code>, see <a href="https://github.com/fosterstack/cache/blob/main/.vex/README.md"><code>.vex/README.md</code></a> for naming your image path</td></tr>
+    </tbody>
+  </table></div>
+  <p>The three files are generated from the same statements. The OpenVEX and CSAF files carry every statement; the Inspector file carries one rule per <code>not_affected</code> or <code>fixed</code> statement and none for <code>affected</code> or <code>under_investigation</code>. Google applies whole-image statements only. <a href="https://github.com/fosterstack/cache/blob/main/.vex/README.md"><code>.vex/README.md</code></a> has the detail.</p>
+  <h2>Suppression rules</h2>
+  <p>A suppression rule in your scanner is only as trustworthy as the claim behind it, so ours work in one direction: <strong>every suppression traces to a published statement</strong>.</p>
+  <ul>
+    <li><strong>Our rules.</strong> We keep no scanner-side ignore that stands alone. A suppression in our repository must cite the statement that governs it (<a href="https://github.com/fosterstack/cache/blob/main/.vex/README.md"><code>.vex/README.md</code></a>), and the Inspector rules above are generated from the statements, never written by hand.</li>
+    <li><strong>Which statements become rules.</strong> <code>not_affected</code> and <code>fixed</code> statements become suppression rules. <code>affected</code> and <code>under_investigation</code> never do: those findings stay visible in your scanner.</li>
+    <li><strong>Scoped to what we shipped.</strong> Each rule is scoped by the CVE and by the digests of the release it was written for (and by package and version when the statement names one), so it does not hide the same CVE in a different image.</li>
+    <li><strong>Your own rules.</strong> Put the statement ID in the rule's reason or comment, so a reviewer on your side can trace it back to our file the same way.</li>
+  </ul>
+  <h2>Docker Scout</h2>
+  <p>Docker Scout reads OpenVEX directly. It applies only the statements whose author matches <code>--vex-author</code> (by default Docker's own), so name ours, the author recorded in the published file:</p>
+  <pre tabindex="0"><code>docker scout cves --vex-location fosterstack-cache.openvex.json \
+  --vex-author '^FosterStack LLC$' \
+  ghcr.io/fosterstack/cache:${VER}</code></pre>
+  <p>Run it once with and once without <code>--vex-location</code> and <code>--vex-author</code>: the difference is the set of findings that applicable <code>not_affected</code> and <code>fixed</code> statements suppress, the same audit as in <a href="https://github.com/fosterstack/cache/blob/main/docs/#reproducing-our-own-gate">Reproducing our own gate</a>.</p>
+  <h2>Reproducing our own gate</h2>
+  <p>The release pipeline's scan stage is public: <a href="https://github.com/fosterstack/cache/blob/main/.github/workflows/stage-verify.yml"><code>.github/workflows/stage-verify.yml</code></a> runs one job per scanner in <a href="https://github.com/fosterstack/cache/blob/main/.github/policy/scanners.json">the scanner list</a> (today Grype and OSV-Scanner) against the exact candidate digests: every variant and architecture, and for Grype every release archive too. The Grype and OSV-Scanner commands below are partial examples that use the gate's scanners and its severity policy on one public tag; they show what a scan of that tag reports and do not cover everything the gate covers.</p>
+  <p>Grype runs in the gate at every severity with the published VEX applied. The VEX document ships with each release as <code>fosterstack-cache.openvex.json</code> and lives in-repo at <a href="https://github.com/fosterstack/cache/tree/main/.vex/"><code>.vex/</code></a>:</p>
+  <pre tabindex="0"><code>grype ghcr.io/fosterstack/cache:X.Y.Z \
+  --fail-on negligible --vex fosterstack-cache.openvex.json</code></pre>
+  <p>OSV-Scanner runs in the gate on the images and on the Go module manifests:</p>
+  <pre tabindex="0"><code>osv-scanner scan image ghcr.io/fosterstack/cache:X.Y.Z</code></pre>
+  <p>Trivy is not a gate command. If you run it, the example below uses the same severity set and the same file, which makes its result comparable but not gate-equivalent:</p>
+  <pre tabindex="0"><code>trivy image --scanners vuln \
+  --severity CRITICAL,HIGH,MEDIUM,LOW,UNKNOWN \
+  --vex fosterstack-cache.openvex.json \
+  ghcr.io/fosterstack/cache:X.Y.Z</code></pre>
+  <p>To see the findings without our statements applied, run Grype or Trivy without <code>--vex</code>, or Docker Scout without <code>--vex-location</code> and <code>--vex-author</code>. The difference between the two runs is the set of findings that applicable <code>not_affected</code> and <code>fixed</code> statements suppress, which is how you audit them.</p>
+  <h2>Confirming the scan is the release run</h2>
+  <p>Every scanner in the repo's list runs on every release, and the verdicts are in the public CI run: the scan is the CI run, in this repository's Actions tab. See <a href="https://github.com/fosterstack/cache/blob/main/docs/verify-images.md">Verify our images</a> for how to confirm the exact image you pulled came from that same run.</p>
+  <p class="muted-note">Related: <a href="/everything-we-do-for-security/">everything we do for security</a>, <a href="/verify-a-release/">verify a release yourself</a>.</p>
+  <p class="muted-note">Moving off the free Build Cache Node? See <a href="/build-cache-node-end-of-life/">what the end of life means</a> and the <a href="/migrate-build-cache-node/">migration guide</a>.</p>
+</main>
+<footer>
+  <div>
+    <p>FosterStack is not affiliated with, endorsed by, or sponsored by Gradle Inc.
+    "Gradle" and "Develocity" are trademarks of Gradle Inc., used here only to identify
+    compatibility. FosterStack contains no Gradle Inc. code; it is a clean-room implementation
+    of the documented remote build cache HTTP protocol. Apache Maven is a trademark of the
+    Apache Software Foundation; the Maven Build Cache Extension is Apache's project, not
+    ours.</p>
+    <p style="margin-top:.6rem">© 2026 FosterStack · <a href="/regulated/">For regulated markets</a> · <a href="https://github.com/fosterstack/cache">github.com/fosterstack/cache</a> · <a href="mailto:hello@fosterstack.com">hello@fosterstack.com</a></p>
+  </div>
+</footer>
+</body>
+</html>
diff --git a/security/index.html b/security/index.html
index 85d42b0..54828e5 100644
--- a/security/index.html
+++ b/security/index.html
@@ -1,6 +1,7 @@
 <!doctype html>
 <html lang="en">
 <head>
+<meta name="robots" content="noindex, nofollow">
 <meta charset="utf-8">
 <meta name="viewport" content="width=device-width, initial-scale=1">
 <title>Security policy: how to report a vulnerability</title>
@@ -88,6 +89,8 @@
 <main>
   <h1>Security policy: how to report a vulnerability</h1>
   <p class="lede">Found a security problem in FosterStack Cache or on this website? Tell us privately. Here is how, what happens next, which version gets fixes, and what we sign and publish so you can check our work.</p>
+  <p class="muted-note"><strong>DRAFT for v0.3, private preview, not published and never merged before v0.3.0 is live.</strong></p>
+
 
   <h2>Report a vulnerability</h2>
   <ul class="trust">
@@ -97,20 +100,20 @@ <h2>Report a vulnerability</h2>
   </ul>
   <p>Send the report, not a patch. Please do not post details publicly before a fix ships.</p>
 
-  <h2>What we aim for</h2>
-  <p>Vulnerable dependencies fixed fast — our target is 48 hours from disclosure (<a href="https://github.com/fosterstack/cache/blob/main/SECURITY.md">the scope is in SECURITY.md</a>). Security patches are never withheld from the free tier: the same fix ships to everyone on the same day.</p>
+  <h2>Kept patched</h2>
+  <p>We keep FosterStack Cache patched. Vulnerable dependencies fixed fast — our target is 48 hours from disclosure (<a href="https://github.com/fosterstack/cache/blob/main/SECURITY.md">the scope is in SECURITY.md</a>). Security patches are never withheld from the free tier: the same fix ships to everyone on the same day.</p>
 
-  <h2 id="long-term-support-build-cache">Long-term support: what is supported</h2>
-  <p>"LTS" means a version that keeps getting fixes for a stated period, so you can stay on it. The supported version is the latest minor release. That is the whole policy. There is no separate long-term-support line, no list of older versions that get fixes, and no support period to quote.</p>
+  <h2 id="long-term-support-build-cache">Which version gets fixes</h2>
+  <p>"LTS" means a version that keeps getting fixes, so you can stay on it. Today the supported version is the latest minor release: there is no list of older versions that get fixes.</p>
   <ul class="trust">
-    <li>To get a fix, move to the latest release. Older releases are not on the supported list.</li>
+    <li>To get a fix, move to a supported release.</li>
     <li>Pin the image to an exact version or digest, not <code>latest</code>, so a deploy never changes without you choosing it.</li>
     <li>Upgrade on a routine. A build cache is disposable, so an upgrade that goes wrong costs you slower builds while it refills, not lost work.</li>
     <li>Watch the repository's releases on GitHub. It is the one notice channel, and you can stop at any time. We do not collect email.</li>
   </ul>
 
   <h2>What we sign and publish</h2>
-  <p>Releases are built only in CI. Each one comes with files you can check without an account:</p>
+  <p>Releases are built only in CI. Each release goes through the steps on <a href="/how-we-build/">how we build</a> and comes with files you can check without an account.</p>
   <ul class="trust">
     <li>Container images, signed without a stored key (Sigstore), with build provenance.</li>
     <li><code>checksums.txt</code> with its own signature file.</li>
@@ -129,7 +132,7 @@ <h2>What we do not claim</h2>
   <ul class="trust">
     <li>The server has a read-write login and an optional read-only login. There is no per-person identity.</li>
     <li>The paid tiers are not built.</li>
-    <li>We are not announcing an LTS line, a support period, or a date.</li>
+    <li>We do not promise a date for any release or any support period.</li>
   </ul>
 
   <p class="muted-note">Machine-readable contact: <a href="/.well-known/security.txt">security.txt</a>.</p>
diff --git a/sitemap.xml b/sitemap.xml
index 3d5cc56..32ab0d7 100644
--- a/sitemap.xml
+++ b/sitemap.xml
@@ -11,6 +11,10 @@
     <loc>https://fosterstack.com/air-gapped-build-cache-install/</loc>
     <lastmod>2026-10-08</lastmod>
   </url>
+  <url>
+    <loc>https://fosterstack.com/whats-new-fosterstack-cache-v0-3-0/</loc>
+    <lastmod>2026-10-10</lastmod>
+  </url>
   <url>
     <loc>https://fosterstack.com/build-cache-docker-compose-production/</loc>
     <lastmod>2026-10-08</lastmod>
@@ -35,6 +39,18 @@
     <loc>https://fosterstack.com/fips-140-3-build-cache/</loc>
     <lastmod>2026-10-08</lastmod>
   </url>
+  <url>
+    <loc>https://fosterstack.com/what-to-verify-in-a-replacement-build-cache/</loc>
+    <lastmod>2026-10-14</lastmod>
+  </url>
+  <url>
+    <loc>https://fosterstack.com/is-a-remote-build-cache-worth-it/</loc>
+    <lastmod>2026-10-14</lastmod>
+  </url>
+  <url>
+    <loc>https://fosterstack.com/faq/</loc>
+    <lastmod>2026-10-14</lastmod>
+  </url>
   <url>
     <loc>https://fosterstack.com/first-15-minutes-build-cache/</loc>
     <lastmod>2026-10-08</lastmod>
@@ -63,6 +79,22 @@
     <loc>https://fosterstack.com/how-our-pipeline-maps-to-nist-and-slsa/</loc>
     <lastmod>2026-10-08</lastmod>
   </url>
+  <url>
+    <loc>https://fosterstack.com/everything-we-do-for-security/</loc>
+    <lastmod>2026-10-13</lastmod>
+  </url>
+  <url>
+    <loc>https://fosterstack.com/scan-fosterstack-cache-image/</loc>
+    <lastmod>2026-10-13</lastmod>
+  </url>
+  <url>
+    <loc>https://fosterstack.com/guides/</loc>
+    <lastmod>2026-10-14</lastmod>
+  </url>
+  <url>
+    <loc>https://fosterstack.com/roadmap/</loc>
+    <lastmod>2026-10-14</lastmod>
+  </url>
   <url>
     <loc>https://fosterstack.com/how-we-build/</loc>
     <lastmod>2026-10-08</lastmod>
diff --git a/upgrade-build-cache-server/index.html b/upgrade-build-cache-server/index.html
index 99c66f7..82a670a 100644
--- a/upgrade-build-cache-server/index.html
+++ b/upgrade-build-cache-server/index.html
@@ -132,6 +132,17 @@ <h3>What we saw</h3>
     <tr><td>Stop 0.2.2, start 0.2.1 on the same volume again</td><td>starts normally; the status page shows 5 entries, 49 bytes; all five values read back</td></tr>
   </table></div>
 
+  <h2 id="upgrade-to-v0-3-0">Upgrading from 0.2.x to v0.3.0</h2>
+  <p>The upgrade steps above are the same: pull the new tag, stop the old container, start the new one on the same volume. Check these first, because they are the things that differ.</p>
+  <ul class="trust">
+    <li><strong>Linux only for binaries.</strong> v0.3.0 ships Linux archives (amd64 and arm64) and no macOS archive. On a Mac, run the Linux container image under Docker Desktop.</li>
+    <li><strong>Two images, no <code>-debug</code>.</strong> The production and <code>-fips</code> images hold only the <code>fscache</code> binary, with no shell. If you used the <code>:debug</code> tag, look inside a running container from outside it with <code>kubectl debug</code> or <code>docker debug</code>.</li>
+    <li><strong>The data folder is the same.</strong> The path has not moved. Temporary files of writes in flight now live in a <code>+tmp</code> folder inside it, so a backup of the volume still covers everything.</li>
+    <li><strong>Your settings keep their meaning.</strong> Every <code>FSCACHE_*</code> setting works as before. The server now logs a warning for an <code>FSCACHE_*</code> variable it does not know, so read the log once after the upgrade for a misspelt name.</li>
+    <li><strong>Verification commands differ.</strong> If your pipeline verifies images, the signing workflow names changed with the new release chain. Use <a href="/verify-a-release/">verify a release yourself</a> for v0.3.0 and later.</li>
+  </ul>
+  <p>Back up the volume first if refilling the cache is expensive for you, as in the back-up section below.</p>
+
   <h2>Two differences between the releases</h2>
   <ul class="trust">
     <li><strong>0.1.0 has no status page.</strong> <code>/statusz</code> returned 404 there. 0.2.1 has it. The metrics page is on both.</li>
diff --git a/verify-a-release/index.html b/verify-a-release/index.html
index 100ac5d..5988898 100644
--- a/verify-a-release/index.html
+++ b/verify-a-release/index.html
@@ -1,12 +1,13 @@
 <!doctype html>
 <html lang="en">
 <head>
+<meta name="robots" content="noindex, nofollow">
 <meta charset="utf-8">
 <meta name="viewport" content="width=device-width, initial-scale=1">
 <title>Verify a FosterStack Cache release yourself</title>
-<meta name="description" content="Check a FosterStack Cache release yourself: checksum, container image signature with cosign, build provenance, SBOM and VEX, with real output from 0.2.2.">
+<meta name="description" content="Verify a FosterStack Cache v0.3.0 release yourself with cosign, gh and jq: image signatures, signed file lists, digests, provenance and the parts list.">
 <meta property="og:title" content="Verify a FosterStack Cache release yourself">
-<meta property="og:description" content="Check a FosterStack Cache release yourself: checksum, container image signature with cosign, build provenance, SBOM and VEX, with real output from 0.2.2.">
+<meta property="og:description" content="Verify a FosterStack Cache v0.3.0 release yourself with cosign, gh and jq: image signatures, signed file lists, digests, provenance and the parts list.">
 <meta property="og:url" content="https://fosterstack.com/verify-a-release/">
 <meta property="og:type" content="website">
 <meta property="og:site_name" content="FosterStack">
@@ -87,152 +88,67 @@
 </header>
 <main>
   <h1>Verify a FosterStack Cache release yourself</h1>
-  <p class="lede">Check our signature, build provenance, SBOM and vulnerability statements with commands you run yourself, using <code>cosign</code> and the <code>gh</code> tool. You can confirm that our release workflow signed a container image and that GitHub's CI built it. No account is needed, except for the <code>gh attestation</code> steps (5 to 7), which need a GitHub login or token.</p>
-
-  <h2>What you need</h2>
-  <p><code>cosign</code>, the <code>gh</code> tool (for the build-provenance steps), and <code>jq</code>. Get them from their own pages: <a href="https://docs.sigstore.dev/cosign/system_config/installation/">cosign</a>, <a href="https://cli.github.com/">gh</a> and <a href="https://jqlang.org/download/">jq</a>. In our timed run we used cosign 3.1.3, gh 2.102.0 and jq 1.6; we make no claim about other versions. Set the version and your platform once:</p>
-  <pre tabindex="0"><code>$ VER=0.2.2
-PLATFORM=linux_arm64   # or linux_amd64, darwin_arm64, darwin_amd64</code></pre>
-  <p>To check another release, set <code>VER</code> to its number, for example <code>VER=0.2.1</code>. To check the latest release, set <code>VER</code> from GitHub with this command in place of the first line above:</p>
+  <p>You should not have to take our word for what you run. Signed at every stage, verified together at release. These steps check the image signatures, the signed file lists, the digest, how the release was built and its parts list, using only <code>cosign</code>, <code>gh</code>, <code>jq</code> and <code>sha256sum</code>. They are for v0.3.0 and later. For v0.2.x, see the <a href="https://github.com/fosterstack/cache/blob/main/docs/verify-images.md">image verification guide</a>.</p>
+  <p>You need no account to pull the images or to run <code>cosign</code>. Downloading release files with <code>gh</code> needs <code>gh auth login</code>; you can also download them from the release page in a browser.</p>
+  <h2>Set the version</h2>
   <pre tabindex="0"><code>VER=$(curl -fsSL https://api.github.com/repos/fosterstack/cache/releases/latest \
-        | sed -n 's/.*"tag_name": *"v\([^"]*\)".*/\1/p')</code></pre>
-
-  <h2>1. Download the release files</h2>
-  <pre tabindex="0"><code>$ gh release download v${VER} --repo fosterstack/cache \
+        | sed -n 's/.*"tag_name": *"v\([^"]*\)".*/\1/p')
+echo "$VER"
+IDENT="https://github.com/fosterstack/cache/.github/workflows"
+ISSUER=https://token.actions.githubusercontent.com</code></pre>
+  <p>There are two images, production and <code>-fips</code>. Run step 1 for each.</p>
+  <h2 id="verify-container-image-signature-cosign">1. The signature and who signed it</h2>
+  <pre tabindex="0"><code>cosign verify ghcr.io/fosterstack/cache:${VER} \
+  --certificate-identity "${IDENT}/stage-promote.yml@refs/tags/v${VER}" \
+  --certificate-oidc-issuer "$ISSUER"
+cosign verify ghcr.io/fosterstack/cache:${VER}-fips \
+  --certificate-identity "${IDENT}/stage-promote.yml@refs/tags/v${VER}" \
+  --certificate-oidc-issuer "$ISSUER"</code></pre>
+  <p>This shows that the release stage of our public pipeline, at this release tag, signed these exact images. The signing certificate lasts minutes and is recorded in Rekor, the public transparency log. There is no signing key to steal.</p>
+  <h2>2. The file lists are ours, and your files match them</h2>
+  <pre tabindex="0"><code>gh release download v${VER} --repo fosterstack/cache \
   -p checksums.txt -p checksums.txt.bundle \
-  -p &quot;fscache_${VER}_${PLATFORM}.tar.gz&quot; \
-  -p &quot;fscache_${VER}_${PLATFORM}.tar.gz.sbom.json&quot; \
-  -p fosterstack-cache.openvex.json -p release-manifest.json</code></pre>
-  <p>Downloading from the <a href="https://github.com/fosterstack/cache/releases">releases page</a> in a browser works the same.</p>
-
-  <h2>2. Is the checksums file ours?</h2>
-  <p>This checks the signature on <code>checksums.txt</code>. It needs no GitHub account.</p>
-  <pre tabindex="0"><code>$ cosign verify-blob \
-  --bundle checksums.txt.bundle \
-  --certificate-identity-regexp=&#x27;^https://github.com/fosterstack/cache/&#x27; \
-  --certificate-oidc-issuer=&#x27;https://token.actions.githubusercontent.com&#x27; \
-  checksums.txt
-Verified OK</code></pre>
-
-  <h2>3. Does your download match it?</h2>
-  <pre tabindex="0"><code>$ sha256sum -c &lt;(grep &quot;fscache_${VER}_${PLATFORM}.tar.gz&quot; checksums.txt | grep -v sbom)
-fscache_0.2.2_linux_arm64.tar.gz: OK</code></pre>
-  <p>Steps 2 and 3 together are the important pair. The checksum alone only shows the archive matches a file you downloaded beside it. The signature is what ties that file to us.</p>
-
-  <h2 id="verify-container-image-signature-cosign">4. Verify a container image signature with cosign</h2>
-  <p>This answers one question: did our release workflow sign these exact bytes? Pin the workflow and the release tag, not "any workflow in the repository". No account is needed.</p>
-  <pre tabindex="0"><code>$ cosign verify ghcr.io/fosterstack/cache:${VER} \
-  --certificate-identity-regexp=&quot;^https://github.com/fosterstack/cache/.github/workflows/stage-promote.yml@refs/tags/v${VER}$&quot; \
-  --certificate-oidc-issuer=&#x27;https://token.actions.githubusercontent.com&#x27;
-Verification for ghcr.io/fosterstack/cache:0.2.2 --
-The following checks were performed on each of these signatures:
-  - The cosign claims were validated
-  - Existence of the claims in the transparency log was verified offline
-  - The code-signing certificate was verified using trusted certificate authority certificates
-
-[{&quot;critical&quot;:{&quot;identity&quot;:{&quot;docker-reference&quot;:&quot;ghcr.io/fosterstack/cache:0.2.2&quot;},&quot;image&quot;:{&quot;docker-manifest-digest&quot;:&quot;sha256:f2b330cf27b3814405230cc001a771909ae5bbf3b1e223a90ee7a9ee5d0e53dd&quot;},&quot;type&quot;:&quot;https://sigstore.dev/cosign/sign/v1&quot;},&quot;optional&quot;:{}},{&quot;critical&quot;:{&quot;identity&quot;:{&quot;docker-reference&quot;:&quot;ghcr.io/fosterstack/cache:0.2.2&quot;},&quot;image&quot;:{&quot;docker-manifest-digest&quot;:&quot;sha256:f2b330cf27b3814405230cc001a771909ae5bbf3b1e223a90ee7a9ee5d0e53dd&quot;},&quot;type&quot;:&quot;https://fosterstack.com/attestations/release-manifest/v1&quot;},&quot;optional&quot;:{}}]</code></pre>
-  <p>There is no signing key to steal. The certificate is short-lived and was issued when the workflow ran, and the signature is in a public transparency log. The same command against <code>docker.io/fosterstack/cache:${VER}</code> returns the same digest, <code>sha256:f2b330cf27b3814405230cc001a771909ae5bbf3b1e223a90ee7a9ee5d0e53dd</code>.</p>
-
-  <h2>5. Where was the image built?</h2>
-  <p>A signature says who signed. Build provenance says what produced the bytes. This step reads GitHub's attestation store, so it needs a token (<code>GH_TOKEN</code> or <code>gh auth login</code>), even though the repository is public.</p>
-  <pre tabindex="0"><code>$ gh attestation verify oci://ghcr.io/fosterstack/cache:${VER} \
-  --repo fosterstack/cache \
-  --signer-workflow fosterstack/cache/.github/workflows/stage-image.yml \
-  --source-ref &quot;refs/tags/v${VER}&quot; \
-  --format json | jq &#x27;.[0].verificationResult | {statement: .statement.predicateType, image: .statement.subject[0].digest, signer: .signature.certificate.subjectAlternativeName, run: .signature.certificate.runInvocationURI}&#x27;
-{
-  &quot;statement&quot;: &quot;https://slsa.dev/provenance/v1&quot;,
-  &quot;image&quot;: {
-    &quot;sha256&quot;: &quot;f2b330cf27b3814405230cc001a771909ae5bbf3b1e223a90ee7a9ee5d0e53dd&quot;
-  },
-  &quot;signer&quot;: &quot;https://github.com/fosterstack/cache/.github/workflows/stage-image.yml@refs/tags/v0.2.2&quot;,
-  &quot;run&quot;: &quot;https://github.com/fosterstack/cache/actions/runs/37957120550/attempts/2&quot;
-}</code></pre>
-  <p>The command exits with status 0 on success. The image digest is the one from step 4, and the run link is the public build that produced it. The link opens attempt 2 of the release run. That attempt built and authorized the image. Attempt 3 re-ran only the promotion job, after a registry login was rejected in attempt 2. It published and signed the images, so the public signatures come from attempt 3. The image digests did not change.</p>
-
-  <h2>6. Where was your download built?</h2>
-  <pre tabindex="0"><code>$ gh attestation verify &quot;fscache_${VER}_${PLATFORM}.tar.gz&quot; --repo fosterstack/cache \
-  --format json | jq -r &#x27;.[0].verificationResult.statement.subject[].name, .[0].verificationResult.signature.certificate.subjectAlternativeName&#x27;
-fscache-fips_0.2.2_linux_amd64.tar.gz
-fscache-fips_0.2.2_linux_amd64.tar.gz.sbom.json
-fscache-fips_0.2.2_linux_arm64.tar.gz
-fscache-fips_0.2.2_linux_arm64.tar.gz.sbom.json
-fscache_0.2.2_darwin_amd64.tar.gz
-fscache_0.2.2_darwin_amd64.tar.gz.sbom.json
-fscache_0.2.2_darwin_arm64.tar.gz
-fscache_0.2.2_darwin_arm64.tar.gz.sbom.json
-fscache_0.2.2_linux_amd64.tar.gz
-fscache_0.2.2_linux_amd64.tar.gz.sbom.json
-fscache_0.2.2_linux_arm64.tar.gz
-fscache_0.2.2_linux_arm64.tar.gz.sbom.json
-checksums.txt
-https://github.com/fosterstack/cache/.github/workflows/stage-build.yml@refs/tags/v0.2.2</code></pre>
-  <p>One statement covers every archive, its SBOM and <code>checksums.txt</code>. Your archive is in the list.</p>
-
-  <h2>7. Did the whole release chain pass?</h2>
-  <p>Each stage of the release signs its own statement about the exact image. One of them exists only if the final authorization stage checked all the others for this image: the source check, the build, the image assembly, the reproducibility check, each scanner's verdict, and the acceptance tests.</p>
-  <pre tabindex="0"><code>$ gh attestation verify oci://ghcr.io/fosterstack/cache:${VER} \
-  --repo fosterstack/cache \
-  --signer-workflow fosterstack/cache/.github/workflows/stage-authorize.yml \
-  --predicate-type https://fosterstack.com/attestations/release-authorization/v1 \
-  --format json | jq &#x27;.[0].verificationResult | {predicateType: .statement.predicateType, signer: .signature.certificate.subjectAlternativeName}&#x27;
-{
-  &quot;predicateType&quot;: &quot;https://fosterstack.com/attestations/release-authorization/v1&quot;,
-  &quot;signer&quot;: &quot;https://github.com/fosterstack/cache/.github/workflows/stage-authorize.yml@refs/tags/v0.2.2&quot;
-}</code></pre>
-
-  <h2>8. What is inside? The SBOM</h2>
-  <p>Each binary archive has a software bill of materials in SPDX format.</p>
-  <pre tabindex="0"><code>$ jq &#x27;{spdxVersion, name, packages: (.packages | length)}&#x27; &quot;fscache_${VER}_${PLATFORM}.tar.gz.sbom.json&quot;
-{
-  &quot;spdxVersion&quot;: &quot;SPDX-2.3&quot;,
-  &quot;name&quot;: &quot;fscache_0.2.2_linux_arm64.tar.gz&quot;,
-  &quot;packages&quot;: 13
-}</code></pre>
-  <pre tabindex="0"><code>$ jq -r &#x27;.packages[0:4][] | &quot;\(.name) \(.versionInfo)&quot;&#x27; &quot;fscache_${VER}_${PLATFORM}.tar.gz.sbom.json&quot;
-github.com/beorn7/perks v1.0.1
-github.com/cespare/xxhash/v2 v2.3.0
-github.com/fosterstack/cache v0.2.2
-github.com/munnerz/goautoneg v0.0.0-20191010083416-a7dc8b61c822</code></pre>
-
-  <h2>9. Which known vulnerabilities do not apply? The VEX file</h2>
-  <p>The VEX (OpenVEX) file lists vulnerabilities that scanners may report and says why each does not affect this release.</p>
-  <pre tabindex="0"><code>$ jq -r &#x27;.statements[] | &quot;\(.vulnerability.name) \(.status) \(.justification)&quot;&#x27; fosterstack-cache.openvex.json
-CVE-2024-51744 not_affected component_not_present
-CVE-2025-60876 not_affected vulnerable_code_not_in_execute_path
-CVE-2025-46394 not_affected vulnerable_code_not_in_execute_path
-CVE-2024-58251 not_affected vulnerable_code_not_in_execute_path</code></pre>
-  <p>You do not have to take our word for those. Run your own scanner against the image and give it this file.</p>
-
-  <h2>10. The release manifest</h2>
-  <p><code>release-manifest.json</code> lists the evidence for the whole release. It names three image variants (the standard one, <code>debug</code> and <code>fips</code>), each with its digest. The standard one is the digest you verified in steps 4 and 5, at both registries:</p>
-  <pre tabindex="0"><code>$ jq -r &#x27;.images[] | &quot;\(.variant) \(.digest)&quot;&#x27; release-manifest.json
-production sha256:f2b330cf27b3814405230cc001a771909ae5bbf3b1e223a90ee7a9ee5d0e53dd
-debug sha256:87887f55ffa41cc63d4aa6f6d9459fd0dbf919491b83f1d3c8b7fc5444b5a081
-fips sha256:92fae7f20616e553c5fe24e9b92f186c3d3f28ad89cee5c24864911032e6c05e</code></pre>
-  <pre tabindex="0"><code>$ jq -c &#x27;.images[0].refs&#x27; release-manifest.json
-[&quot;ghcr.io/fosterstack/cache@sha256:f2b330cf27b3814405230cc001a771909ae5bbf3b1e223a90ee7a9ee5d0e53dd&quot;,&quot;docker.io/fosterstack/cache@sha256:f2b330cf27b3814405230cc001a771909ae5bbf3b1e223a90ee7a9ee5d0e53dd&quot;]</code></pre>
-  <pre tabindex="0"><code>$ jq &#x27;.verified_statements | length&#x27; release-manifest.json
-43</code></pre>
-  <p>That last number is the statements the authorization stage checked, each with its entry in the public transparency log.</p>
-
-  <h2>What these checks do and do not prove</h2>
-  <ul class="trust">
-    <li>A valid signature proves who signed these exact bytes.</li>
-    <li>Build provenance proves which repository, workflow and run produced them, which is a public CI run and not a developer machine.</li>
-    <li>Neither says the image was scanned or tested. Those are separate signed statements attached to the same image digest, and you can verify them the same way.</li>
-    <li>The SBOM and VEX files are statements we publish. They are as trustworthy as the signature on the release that carries them.</li>
-    <li>None of this proves the software has no bugs or that no vulnerability exists. It proves the release is the one we built, in the way we describe.</li>
+  -p release-files.sha256 -p release-files.sha256.bundle \
+  -p release-manifest.json -p "fscache_${VER}_linux_amd64.tar.gz"
+for f in checksums.txt release-files.sha256; do
+  cosign verify-blob "$f" --bundle "$f.bundle" \
+    --certificate-identity "${IDENT}/stage-promote.yml@refs/tags/v${VER}" \
+    --certificate-oidc-issuer "$ISSUER"
+done
+sha256sum -c &lt;(grep "fscache_${VER}_linux_amd64.tar.gz" checksums.txt)
+sha256sum -c &lt;(grep release-manifest.json release-files.sha256)</code></pre>
+  <p>Do the signature check first. Without it, a list only proves that your files match a file anyone could have written. The archives are covered by the signed <code>checksums.txt</code>, and the manifest by the signed <code>release-files.sha256</code>.</p>
+  <h2>3. The digest is the one in the release</h2>
+  <pre tabindex="0"><code>jq -r '.images[] | "\(.variant) \(.digest)"' release-manifest.json</code></pre>
+  <p>Every statement names an image by digest, never by tag. The digest you pulled should be in this list.</p>
+  <h2>4. How it was built</h2>
+  <pre tabindex="0"><code>gh release download v${VER} --repo fosterstack/cache \
+  -p provenance.json -p provenance.bundle.json
+cosign verify-blob-attestation --bundle provenance.bundle.json \
+  --type https://slsa.dev/provenance/v1 --check-claims=false \
+  --certificate-identity "${IDENT}/stage-sign.yml@refs/tags/v${VER}" \
+  --certificate-oidc-issuer "$ISSUER"
+jq -r '.dsseEnvelope.payload | @base64d | fromjson | .subject[] | .name + " sha256:" + .digest.sha256' provenance.bundle.json</code></pre>
+  <p>The SLSA provenance is signed by a separate job with its own identity, <code>stage-sign.yml</code>. It receives only the list of digests the build made and runs no code from the build. The second command lists each item it names, with its digest.</p>
+  <h2>5. The parts list and what it was assembled from</h2>
+  <pre tabindex="0"><code>gh release download v${VER} --repo fosterstack/cache \
+  -p production.sbom.json -p production.sbom.json.bundle \
+  -p production.full.lock.json -p production.full.lock.json.bundle
+for f in production.sbom.json production.full.lock.json; do
+  cosign verify-blob "$f" --bundle "$f.bundle" \
+    --certificate-identity "${IDENT}/stage-promote.yml@refs/tags/v${VER}" \
+    --certificate-oidc-issuer "$ISSUER"
+done</code></pre>
+  <p>The SBOM lists what is in the image. The lock file lists every package the image was assembled from, by checksum. Repeat with <code>fips.sbom.json</code> and <code>fips.full.lock.json</code> for the <code>-fips</code> image.</p>
+  <h2>What this proves</h2>
+  <ul>
+    <li>A valid signature proves who signed these exact files, and that the signing was recorded publicly.</li>
+    <li>Provenance proves which workflow, at which tag, produced the digests it names.</li>
+    <li>It does not prove the software has no bugs. Scan results and our statements about findings are separate: see <a href="/security/">the security policy</a>.</li>
   </ul>
-  <h2>How we checked</h2>
-  <p>Every command above was run against release 0.2.2, and the output shown is what it printed. We ran the same commands against release 0.2.1 too: they worked the same, and only the values differ. The workflow names in the commands belong to these two releases. They are version-scoped, so for older releases use the <a href="https://github.com/fosterstack/cache/blob/main/docs/verify-images.md">verification guide</a>.</p>
-  <p><strong>How long it takes.</strong> We followed this page word for word in a new container on a GitHub-hosted runner, with only the tools it names installed (cosign, <code>gh</code> and <code>jq</code>, plus <code>curl</code>, <code>ca-certificates</code> and <code>tar</code> from the system). Steps 1 to 7 took 12.6 to 13.1 seconds, and all ten steps 13.9 to 14.5 seconds, in two runs for release 0.2.1 and two for release 0.2.2. Installing the tools took about 5 seconds more. Reading and typing are not in those numbers. Steps 1 to 4 ran with no GitHub login; only steps 5 to 7 were given a token. Every step passed. In the 0.2.1 runs we also compared the values this page used to print for 0.2.1, and the digests, the build-run link, the package count, a VEX line and the statement count all matched. <a href="https://github.com/fosterstack/www/actions/runs/38029170706">The run and its log are public</a>, and the script is <a href="/bin/bench-verify-release.sh">bin/bench-verify-release.sh</a>.</p>
-
-  <p class="muted-note">Related: <a href="/how-we-build/">how releases are built and signed</a> and <a href="/air-gapped-build-cache-install/">installing on an air-gapped network</a>.</p>
-  <div class="cta-row">
-    <a class="btn" href="https://github.com/fosterstack/cache/releases">Releases on GitHub</a>
-    <a class="btn btn-secondary" href="/">FosterStack home</a>
-  </div>
+  <p>Each stage of the release also writes a record that anyone with the Witness tool can check. Those records are extra evidence outside the steps above, and are attached to the release.</p>
+  <p class="muted-note">Related: <a href="/how-we-build/">how releases are built and signed</a>, <a href="/how-our-pipeline-maps-to-nist-and-slsa/">how the pipeline maps to NIST and SLSA</a> and <a href="/scan-fosterstack-cache-image/">scan the image yourself</a>.</p>
+  <p class="muted-note">Moving off the free Build Cache Node? See <a href="/build-cache-node-end-of-life/">what the end of life means</a> and the <a href="/migrate-build-cache-node/">migration guide</a>.</p>
 </main>
 <footer>
   <div>
diff --git a/what-to-verify-in-a-replacement-build-cache/index.html b/what-to-verify-in-a-replacement-build-cache/index.html
new file mode 100644
index 0000000..ab8e0bc
--- /dev/null
+++ b/what-to-verify-in-a-replacement-build-cache/index.html
@@ -0,0 +1,124 @@
+<!doctype html>
+<html lang="en">
+<head>
+<meta name="robots" content="noindex, nofollow">
+<meta charset="utf-8">
+<meta name="viewport" content="width=device-width, initial-scale=1">
+<title>What to verify in a replacement build cache</title>
+<meta name="description" content="A checklist you can run against any replacement build cache: signed releases, provenance, read-only logins, eviction, metrics, air-gapped use and licence.">
+<meta property="og:title" content="What to verify in a replacement build cache">
+<meta property="og:description" content="A checklist you can run against any replacement build cache: signed releases, provenance, read-only logins, eviction, metrics, air-gapped use and licence.">
+<meta property="og:url" content="https://fosterstack.com/what-to-verify-in-a-replacement-build-cache/">
+<meta property="og:type" content="website">
+<meta property="og:site_name" content="FosterStack">
+<link rel="canonical" href="https://fosterstack.com/what-to-verify-in-a-replacement-build-cache/">
+<link rel="icon" href="/favicon.svg" type="image/svg+xml">
+<link rel="icon" href="/favicon.ico" sizes="any">
+<link rel="apple-touch-icon" href="/apple-touch-icon.png">
+<style>
+  :root {
+    --bg: #ffffff; --fg: #16181d; --muted: #5b6472; --line: #e4e7ec;
+    --accent: #0d7a5f; --accent-fg: #ffffff; --card: #f6f8f9; --warn-bg: #fff7ed; --warn-line: #fdba74;
+    --mark: #0f4d66;
+  }
+  @media (prefers-color-scheme: dark) {
+    :root {
+      --bg: #101318; --fg: #e8eaf0; --muted: #98a2b3; --line: #262c36;
+      --accent: #2fbf95; --accent-fg: #08110e; --card: #171c23; --warn-bg: #241a10; --warn-line: #7c4a12;
+      --mark: #e8eaf0;
+    }
+  }
+  * { margin: 0; padding: 0; box-sizing: border-box; }
+  body {
+    background: var(--bg); color: var(--fg);
+    font: 16px/1.6 system-ui, -apple-system, "Segoe UI", Roboto, sans-serif;
+    -webkit-font-smoothing: antialiased;
+  }
+  main { max-width: 44rem; margin: 0 auto; padding: 0 1.25rem 4rem; }
+  header.site { max-width: 44rem; margin: 0 auto; padding: 1.25rem; display: flex; align-items: baseline; gap: .6rem; }
+  .logo { font-weight: 700; font-size: 1.05rem; letter-spacing: -.01em; }
+  .logo span { color: var(--accent); }
+  .logo .mark { width: 1.2em; height: 1.2em; vertical-align: -.24em; margin-right: .4em; }
+  .tag { color: var(--muted); font-size: .85rem; }
+  .notice {
+    background: var(--warn-bg); border: 1px solid var(--warn-line); border-radius: 8px;
+    padding: .7rem 1rem; font-size: .92rem; margin: 1.5rem 0 2.5rem;
+  }
+  h1 { font-size: 2rem; line-height: 1.2; letter-spacing: -.02em; margin-bottom: 1rem; }
+  .lede { font-size: 1.12rem; color: var(--muted); margin-bottom: 2rem; }
+  h2 { font-size: 1.25rem; margin: 3rem 0 .9rem; letter-spacing: -.01em; }
+  p + p { margin-top: .8rem; }
+  .cards { display: grid; grid-template-columns: repeat(auto-fit, minmax(15rem, 1fr)); gap: .8rem; margin-top: 1rem; }
+  .card { background: var(--card); border: 1px solid var(--line); border-radius: 10px; padding: 1rem 1.1rem; }
+  .card h3 { font-size: .98rem; margin-bottom: .35rem; }
+  .card p { font-size: .9rem; color: var(--muted); }
+  ul.trust { list-style: none; margin-top: .5rem; }
+  ul.trust li { padding: .45rem 0 .45rem 1.6rem; position: relative; }
+  ul.trust li::before { content: "✓"; position: absolute; left: .2rem; color: var(--accent); font-weight: 700; }
+  code, pre { font-family: ui-monospace, "SF Mono", Menlo, monospace; font-size: .88em; }
+  code { background: var(--card); border: 1px solid var(--line); border-radius: 5px; padding: .1em .35em; }
+  pre code { background: none; border: 0; padding: 0; color: inherit; font-size: 1em; }
+  button {
+    padding: .7rem 1.3rem; font-size: 1rem; font-weight: 600; cursor: pointer;
+    background: var(--accent); color: var(--accent-fg); border: 0; border-radius: 8px;
+  }
+  button:disabled { opacity: .6; cursor: default; }
+  table { width: 100%; border-collapse: collapse; font-size: .92rem; margin-top: 1rem; }
+  th, td { text-align: left; padding: .55rem .6rem; border-bottom: 1px solid var(--line); vertical-align: top; }
+  th { font-size: .8rem; text-transform: uppercase; letter-spacing: .04em; color: var(--muted); }
+  pre { background: #0f172a; color: #e2e8f0; padding: .9rem 1rem; border-radius: 8px;
+        overflow-x: auto; font-size: .9rem; line-height: 1.5; }
+  .cta-row { display: flex; gap: .6rem; flex-wrap: wrap; margin-top: 1.1rem; }
+  .btn { display: inline-block; padding: .55rem 1rem; border-radius: 8px; font-weight: 600;
+         text-decoration: none; background: var(--accent); color: var(--accent-fg); }
+  .btn-secondary { background: transparent; color: inherit; border: 1px solid var(--muted); }
+  .muted-note { color: var(--muted); font-size: .93rem; margin-top: 1.1rem; }
+  footer { border-top: 1px solid var(--line); margin-top: 4rem; padding: 1.5rem 1.25rem 3rem; }
+  footer div { max-width: 44rem; margin: 0 auto; color: var(--muted); font-size: .82rem; }
+  a { color: var(--accent); }
+  code { overflow-wrap: anywhere; }
+  pre code { overflow-wrap: normal; }
+  main h3 { font-size: 1.05rem; margin: 2rem 0 .6rem; }
+  .table-scroll { max-width: 100%; overflow-x: auto; }
+  :focus-visible { outline: 3px solid var(--accent); outline-offset: 2px; }
+</style>
+</head>
+<body>
+<header class="site">
+  <div class="logo"><svg class="mark" viewBox="0 0 96 96" aria-hidden="true" focusable="false"><rect x="12" y="14" width="72" height="18" rx="5" fill="var(--mark)"/><rect x="12" y="39" width="48" height="18" rx="5" fill="var(--mark)"/><rect x="12" y="64" width="26" height="18" rx="5" fill="var(--accent)"/></svg>foster<span>stack</span></div>
+  <div class="tag">Infrastructure worth keeping — and kept patched.</div>
+</header>
+<main>
+  <h1>What to verify in a replacement build cache</h1>
+  <p class="lede">Eleven checks you can run against any build cache you are thinking of putting in front of your builds. Each has what to ask or test, and what we say for FosterStack Cache so you can compare.</p>
+  <div class="table-scroll" role="region" aria-label="Scrollable table" tabindex="0"><table>
+    <tr><th>Check</th><th>What to do</th><th>FosterStack Cache</th></tr>
+    <tr><td><strong>Are releases signed, and can you check without an account?</strong></td><td>Download one release and run the signature check yourself. You should not need to sign up or ask anyone.</td><td>Images are keylessly signed and every binary archive is covered by a signed checksums file. See <a href="/verify-a-release/">Verify a release</a>.</td></tr>
+    <tr><td><strong>Is there a record of how it was built?</strong></td><td>Ask for build provenance that names the workflow and run, not only a signature.</td><td>Images and archives carry SLSA provenance naming the CI run that built them. See <a href="/how-we-build/">how we build</a> and <a href="/how-our-pipeline-maps-to-nist-and-slsa/">how it maps to NIST and SLSA</a>.</td></tr>
+    <tr><td><strong>Is there a parts list and a statement on known vulnerabilities?</strong></td><td>Ask for an SBOM and for VEX statements per release, and whether anyone can read them without buying anything.</td><td>SBOMs, VEX statements and signatures are published with every release, free.</td></tr>
+    <tr><td><strong>Can you give people read-only access?</strong></td><td>Check that a read-only login can read and that any write is refused, not just discouraged.</td><td>An optional read-only login can read; every write is refused. See <a href="/gradle-build-cache-ci-writes-developers-read/">CI writes, developers read</a>.</td></tr>
+    <tr><td><strong>What stops a bad entry reaching your builds?</strong></td><td>Ask who can write, and what a poisoned entry could do. A cache that only the right logins can write to is the control.</td><td>See <a href="/can-someone-poison-our-build-cache/">Can someone poison our build cache?</a></td></tr>
+    <tr><td><strong>Does eviction keep the disk from filling?</strong></td><td>Set a size cap and fill past it in a test. The server should drop old entries, not stop.</td><td>Size-capped least-recently-used eviction. See <a href="/build-cache-eviction-size-limit/">size limit, eviction and a full disk</a>.</td></tr>
+    <tr><td><strong>Can you see what it is doing?</strong></td><td>Look for a health check and metrics you can alert on without a vendor agent.</td><td><code>/healthz</code> for liveness and Prometheus metrics at <code>/metrics</code>. See <a href="/is-the-build-cache-server-healthy-what-to-alert-on/">what to alert on</a>.</td></tr>
+    <tr><td><strong>Does it run with no outbound connection?</strong></td><td>Run it on a network with no route to the internet and check that builds still work. Ask whether it sends telemetry.</td><td>No telemetry and no connection to FosterStack needed. See <a href="/air-gapped-build-cache-install/">air-gapped install</a>.</td></tr>
+    <tr><td><strong>What happens when it is down?</strong></td><td>Stop it during a build. Builds should be slower, not wrong.</td><td>See <a href="/build-cache-server-down-what-happens/">what happens when the server is down</a>.</td></tr>
+    <tr><td><strong>What is the licence, and is the code public?</strong></td><td>Read the licence file and check that the security evidence is not behind the paid tier.</td><td>MIT, with the source on GitHub. The security evidence is public and free.</td></tr>
+    <tr><td><strong>What does the security-fix promise actually say?</strong></td><td>Ask for the patch commitment in writing, with a time and what counts as a fix.</td><td>Our aim is to ship dependency fixes within 48 hours of public disclosure. That is a stated intention, not a contractual promise today. The current release is rescanned daily. See <a href="https://github.com/fosterstack/cache/blob/main/SECURITY.md">SECURITY.md</a>.</td></tr>
+  </table></div>
+  <h2>Where to start</h2>
+  <p>If you are moving off the free Build Cache Node, read <a href="/build-cache-node-end-of-life/">what the end of life means</a> and the <a href="/migrate-build-cache-node/">migration guide</a>. Questions? See the <a href="/faq/">FAQ</a>.</p>
+  <div class="cta-row"><a class="btn" href="/first-15-minutes-build-cache/">First 15 minutes</a> <a class="btn btn-secondary" href="/guides/">All guides</a></div>
+</main>
+<footer>
+  <div>
+    <p>FosterStack is not affiliated with, endorsed by, or sponsored by Gradle Inc.
+    "Gradle" and "Develocity" are trademarks of Gradle Inc., used here only to identify
+    compatibility. FosterStack contains no Gradle Inc. code; it is a clean-room implementation
+    of the documented remote build cache HTTP protocol. Apache Maven is a trademark of the
+    Apache Software Foundation; the Maven Build Cache Extension is Apache's project, not
+    ours.</p>
+    <p style="margin-top:.6rem">© 2026 FosterStack · <a href="/build-cache-node-end-of-life/">Build Cache Node end of life</a> · <a href="/migrate-build-cache-node/">Migrate</a> · <a href="/build-cache-node-end-of-life/#build-cache-node-faq">FAQ</a> · <a href="/jenkins-ci-build-cache/">CI setup</a> · <a href="/how-we-build/">How we build</a> · <a href="/regulated/">For regulated markets</a> · <a href="https://github.com/fosterstack/cache">github.com/fosterstack/cache</a> · <a href="mailto:hello@fosterstack.com">hello@fosterstack.com</a></p>
+  </div>
+</footer>
+</body>
+</html>
diff --git a/whats-new-fosterstack-cache-v0-3-0/index.html b/whats-new-fosterstack-cache-v0-3-0/index.html
new file mode 100644
index 0000000..3442d39
--- /dev/null
+++ b/whats-new-fosterstack-cache-v0-3-0/index.html
@@ -0,0 +1,122 @@
+<!doctype html>
+<html lang="en">
+<head>
+<meta name="robots" content="noindex, nofollow">
+<meta charset="utf-8">
+<meta name="viewport" content="width=device-width, initial-scale=1">
+<title>What's new in FosterStack Cache v0.3.0 (draft)</title>
+<meta name="description" content="What changes for you in FosterStack Cache v0.3.0: what to check before you upgrade. Draft, not published.">
+<meta property="og:title" content="What's new in FosterStack Cache v0.3.0 (draft)">
+<meta property="og:description" content="What changes for you in FosterStack Cache v0.3.0: what to check before you upgrade. Draft, not published.">
+<meta property="og:url" content="https://fosterstack.com/whats-new-fosterstack-cache-v0-3-0/">
+<meta property="og:type" content="website">
+<meta property="og:site_name" content="FosterStack">
+<link rel="canonical" href="https://fosterstack.com/whats-new-fosterstack-cache-v0-3-0/">
+<link rel="icon" href="/favicon.svg" type="image/svg+xml">
+<link rel="icon" href="/favicon.ico" sizes="any">
+<link rel="apple-touch-icon" href="/apple-touch-icon.png">
+<style>
+  :root {
+    --bg: #ffffff; --fg: #16181d; --muted: #5b6472; --line: #e4e7ec;
+    --accent: #0d7a5f; --accent-fg: #ffffff; --card: #f6f8f9; --warn-bg: #fff7ed; --warn-line: #fdba74;
+    --mark: #0f4d66;
+  }
+  @media (prefers-color-scheme: dark) {
+    :root {
+      --bg: #101318; --fg: #e8eaf0; --muted: #98a2b3; --line: #262c36;
+      --accent: #2fbf95; --accent-fg: #08110e; --card: #171c23; --warn-bg: #241a10; --warn-line: #7c4a12;
+      --mark: #e8eaf0;
+    }
+  }
+  * { margin: 0; padding: 0; box-sizing: border-box; }
+  body {
+    background: var(--bg); color: var(--fg);
+    font: 16px/1.6 system-ui, -apple-system, "Segoe UI", Roboto, sans-serif;
+    -webkit-font-smoothing: antialiased;
+  }
+  main { max-width: 44rem; margin: 0 auto; padding: 0 1.25rem 4rem; }
+  header.site { max-width: 44rem; margin: 0 auto; padding: 1.25rem; display: flex; align-items: baseline; gap: .6rem; }
+  .logo { font-weight: 700; font-size: 1.05rem; letter-spacing: -.01em; }
+  .logo span { color: var(--accent); }
+  .logo .mark { width: 1.2em; height: 1.2em; vertical-align: -.24em; margin-right: .4em; }
+  .tag { color: var(--muted); font-size: .85rem; }
+  .notice {
+    background: var(--warn-bg); border: 1px solid var(--warn-line); border-radius: 8px;
+    padding: .7rem 1rem; font-size: .92rem; margin: 1.5rem 0 2.5rem;
+  }
+  h1 { font-size: 2rem; line-height: 1.2; letter-spacing: -.02em; margin-bottom: 1rem; }
+  .lede { font-size: 1.12rem; color: var(--muted); margin-bottom: 2rem; }
+  h2 { font-size: 1.25rem; margin: 3rem 0 .9rem; letter-spacing: -.01em; }
+  p + p { margin-top: .8rem; }
+  .cards { display: grid; grid-template-columns: repeat(auto-fit, minmax(15rem, 1fr)); gap: .8rem; margin-top: 1rem; }
+  .card { background: var(--card); border: 1px solid var(--line); border-radius: 10px; padding: 1rem 1.1rem; }
+  .card h3 { font-size: .98rem; margin-bottom: .35rem; }
+  .card p { font-size: .9rem; color: var(--muted); }
+  ul.trust { list-style: none; margin-top: .5rem; }
+  ul.trust li { padding: .45rem 0 .45rem 1.6rem; position: relative; }
+  ul.trust li::before { content: "✓"; position: absolute; left: .2rem; color: var(--accent); font-weight: 700; }
+  code, pre { font-family: ui-monospace, "SF Mono", Menlo, monospace; font-size: .88em; }
+  code { background: var(--card); border: 1px solid var(--line); border-radius: 5px; padding: .1em .35em; }
+  pre code { background: none; border: 0; padding: 0; color: inherit; font-size: 1em; }
+  button {
+    padding: .7rem 1.3rem; font-size: 1rem; font-weight: 600; cursor: pointer;
+    background: var(--accent); color: var(--accent-fg); border: 0; border-radius: 8px;
+  }
+  button:disabled { opacity: .6; cursor: default; }
+  table { width: 100%; border-collapse: collapse; font-size: .92rem; margin-top: 1rem; }
+  th, td { text-align: left; padding: .55rem .6rem; border-bottom: 1px solid var(--line); vertical-align: top; }
+  th { font-size: .8rem; text-transform: uppercase; letter-spacing: .04em; color: var(--muted); }
+  pre { background: #0f172a; color: #e2e8f0; padding: .9rem 1rem; border-radius: 8px;
+        overflow-x: auto; font-size: .9rem; line-height: 1.5; }
+  .cta-row { display: flex; gap: .6rem; flex-wrap: wrap; margin-top: 1.1rem; }
+  .btn { display: inline-block; padding: .55rem 1rem; border-radius: 8px; font-weight: 600;
+         text-decoration: none; background: var(--accent); color: var(--accent-fg); }
+  .btn-secondary { background: transparent; color: inherit; border: 1px solid var(--muted); }
+  .muted-note { color: var(--muted); font-size: .93rem; margin-top: 1.1rem; }
+  footer { border-top: 1px solid var(--line); margin-top: 4rem; padding: 1.5rem 1.25rem 3rem; }
+  footer div { max-width: 44rem; margin: 0 auto; color: var(--muted); font-size: .82rem; }
+  a { color: var(--accent); }
+  code { overflow-wrap: anywhere; }
+  pre code { overflow-wrap: normal; }
+  :focus-visible { outline: 3px solid var(--accent); outline-offset: 2px; }
+</style>
+</head>
+<body>
+<header class="site">
+  <div class="logo"><svg class="mark" viewBox="0 0 96 96" aria-hidden="true" focusable="false"><rect x="12" y="14" width="72" height="18" rx="5" fill="var(--mark)"/><rect x="12" y="39" width="48" height="18" rx="5" fill="var(--mark)"/><rect x="12" y="64" width="26" height="18" rx="5" fill="var(--accent)"/></svg>foster<span>stack</span></div>
+  <div class="tag">Infrastructure worth keeping — and kept patched.</div>
+</header>
+<main>
+  <h1>What changes for you in FosterStack Cache v0.3.0</h1>
+  <p>You run FosterStack Cache for Gradle or Maven builds and you want to know what an upgrade to v0.3.0 changes. Three things may matter on your side: check them before you upgrade.</p>
+  <p class="muted-note"><strong>DRAFT for v0.3, private preview, not published and never merged before v0.3.0 is live.</strong></p>
+  <h2>Check these before you upgrade</h2>
+  <ul class="trust">
+    <li><strong>Linux only.</strong> v0.3.0 ships Linux archives (amd64 and arm64) and no macOS archive. On a Mac, run the Linux container image under Docker Desktop.</li>
+    <li><strong>No <code>-debug</code> image.</strong> v0.3.0 ships the <code>production</code> and <code>fips</code> images only. They hold only the <code>fscache</code> binary, with no shell, so look inside a running container from outside it with <code>kubectl debug</code> or <code>docker debug</code>; the README has a section on it.</li>
+    <li><strong>Inside the data folder.</strong> The data folder path is the same, but temporary files of writes in flight now live in a <code>+tmp</code> folder inside it.</li>
+  </ul>
+  <h2>What stays the same</h2>
+  <p>The Gradle and Maven protocols stay as they are, and every <code>FSCACHE_*</code> setting you use today keeps its meaning. Two new optional settings, <code>FSCACHE_TLS_CERT</code> and <code>FSCACHE_TLS_KEY</code>, make the server itself serve HTTPS (TLS 1.2 or later); set both or neither. The server now binds its address first and logs a warning for an <code>FSCACHE_*</code> variable it does not know. A request with more than 500 header values has been rejected with <code>431</code> (Request Header Fields Too Large) since 0.2.2, because of Go 1.27; Gradle and Maven send far fewer.</p>
+  <h2>Kept patched</h2>
+  <p>We keep FosterStack Cache patched. The server does not update itself, so watch the repository's releases on GitHub. Our target for vulnerable dependencies is 48 hours from disclosure; <a href="https://github.com/fosterstack/cache/blob/main/SECURITY.md">the scope is in SECURITY.md</a>.</p>
+  <h2>How the release is built</h2>
+  <p>Signed at every stage, verified together at release. The image is built from signed packages, with no base image. We secure our own release pipeline first. You can check all of it yourself: see <a href="/verify-a-release/">verify a release yourself</a> and <a href="/how-we-build/">how we build</a>.</p>
+  <h2>Upgrading</h2>
+  <p>The upgrade steps are the same as for any release: pull the new tag and start it on the same volume. See <a href="/upgrade-build-cache-server/#upgrade-to-v0-3-0">upgrading from 0.2.x to v0.3.0</a> for what to check first.</p>
+  <p class="muted-note">Related: <a href="/changelog/">changelog</a> and <a href="/security/">security policy</a>.</p>
+  <p class="muted-note">Moving off the free Build Cache Node? See <a href="/build-cache-node-end-of-life/">what the end of life means</a> and the <a href="/migrate-build-cache-node/">migration guide</a>.</p>
+</main>
+<footer>
+  <div>
+    <p>FosterStack is not affiliated with, endorsed by, or sponsored by Gradle Inc.
+    "Gradle" and "Develocity" are trademarks of Gradle Inc., used here only to identify
+    compatibility. FosterStack contains no Gradle Inc. code; it is a clean-room implementation
+    of the documented remote build cache HTTP protocol. Apache Maven is a trademark of the
+    Apache Software Foundation; the Maven Build Cache Extension is Apache's project, not
+    ours.</p>
+    <p style="margin-top:.6rem">© 2026 FosterStack · <a href="/regulated/">For regulated markets</a> · <a href="https://github.com/fosterstack/cache">github.com/fosterstack/cache</a> · <a href="mailto:hello@fosterstack.com">hello@fosterstack.com</a></p>
+  </div>
+</footer>
+</body>
+</html>