Pre-launch checklist
The security and infrastructure gates between here and a public repo, in the order they have to be cleared
Credentials in git history
Secrets were committed before the repo was locked down. The repo is private, so the blast radius is anyone with access — but that is exactly what changes the moment a collaborator or the public arrives. Rotation comes before access, and history rewriting comes before publication. Never invert that order.
Where it stands
| Gate | Status |
|---|---|
| CI (typecheck + lint on every PR) | ✅ .github/workflows/ci.yml, green since d546968b1 |
| Hardcoded credentials in shell scripts | ✅ Gone — packages/db-tools/scripts/db/ holds no push scripts any more |
| Database password rotation | ⬜ Open |
Branch protection on main | ⬜ Open |
.gitignore audit | ✅ Only .env.example files are tracked |
| Secret scanning | ⬜ Open |
| Git history rewrite | ⬜ Open — blocks going public |
Gate 1 — before inviting collaborators
A collaborator sees the full history from their first git clone. Everything here must land before the invite goes out.
Rotate the database passwords
Both Supabase projects. Dashboard → Project settings → Database → Reset password.
Project refs are not written down here on purpose — read them from Infisical (prod, /db) or the Vercel dashboard. Publishing an infrastructure identifier in the docs site is the same mistake in a nicer font.
Push the new values to Vercel
Rotation without propagation is an outage. Update every project's env vars (POSTGRES_URL, POSTGRES_RLS_URL, SUPABASE_SECRET_KEY) and redeploy before you consider the rotation done.
Regenerate the publishable key
Only if it was ever pasted somewhere it shouldn't have been. The publishable key is safe by design — it is the secret key that matters.
Lock down main
- Require pull requests; no direct pushes
- Require your approval to merge
- Require the CI check to pass
Invite with Write, never Admin
Admin can change branch protection, rotate deploy keys, and delete the repo. Write is what a collaborator needs.
Access rules that don't expire
- Never share
.envfiles. Grant access through the Vercel env-var UI, so revoking it is one click and leaves a trail. - Supabase project admin stays with you.
- Vercel project admin stays with you.
Gate 2 — before going public
This one is irreversible
A public repo is a public history. Once a commit containing a live secret is fetched by a crawler, rotating afterwards is damage control, not prevention.
Rewrite the history
git filter-repo over the leaked paths, or start from a fresh repo with a single initial commit. Rotate anything the history exposed again afterwards, on the assumption the old history was already cloned.
Re-audit .gitignore
Currently clean: git ls-files | grep -E '\.env' returns only .env.example files. Re-run it as the last thing before flipping the repo public — a new app added later is the way this regresses.
Enable secret scanning + push protection
Settings → Code security. Push protection is the half that matters: it blocks the next leak instead of reporting it.
Related
- Security — the runtime posture (RLS, JWT claims, service-role boundaries)
- The database's own deployment rules live in the
cute-dbskill andpackages/db/migrations/README.md