Password protection with end-to-end encryption shipped for static sites
Site operators can now lock published Gitpulse sites behind a password, with all HTML and JSON content encrypted client-side in the browser — no server, no infrastructure changes required.
Static sites are public by default. Gitpulse's editorial feed of pull requests and commits had no way to restrict access — fine for open-source projects, but teams wanting to share early analysis internally had nowhere to hide.
This PR changes that. Set one environment variable at build time and the entire static export ships as ciphertext. HTML pages become unlock shells, data files become encrypted envelopes with random initialization vectors, OG images and sitemaps are deleted to prevent metadata leaks, and robots.txt blocks search crawlers entirely. The encryption uses PBKDF2-SHA256 with 600,000 iterations feeding AES-GCM 256-bit via the browser's native Web Crypto API — no third-party crypto libraries, just platform primitives that work everywhere.
Readers see one clean unlock screen the first time they visit. The derived key can be cached locally so returning visitors decrypt silently without re-entering credentials. Wrong passwords fail fast via AES-GCM's authentication tag verification, giving a clear unlock error instead of garbled content.
The implementation is entirely opt-in. Leave GITPULSE_PASSWORD unset and the build pipeline behaves exactly as before — no encryption, no unlock UI, no friction. It works on any static host: Vercel, GitHub Pages, Netlify, Cloudflare Pages. The CLI's incremental analyze step can also decrypt protected deployments, keeping differential builds working even against encrypted state.
The GitHub Pages deployment now uses password protection by default, demonstrating the feature live at znat.github.io/gitpulse/ with a public demo password published in the README.