Your deploy pipeline is not a backup

Every project we run deploys through a pipeline. Push a commit, a build fires, the site goes live in under a minute. That pipeline had been green for months across every project we own.

Then we actually checked where the code lived. Three of four repositories had no git remote whatsoever. Years of commit history — for sites processing real payments — existed on exactly one laptop.

Why nobody noticed

Because everything worked. The deploy tooling was linked directly to the local project folder, so shipping never required a remote to exist. Every signal a developer normally reads as "things are fine" was in fact fine. The missing piece produced no symptom at all, because backups have no symptoms until the day you need one.

This is the difference between a control that is working and a control that is absent but untested. From the outside they look identical.

The audit that finds it in two minutes

For each project, ask three questions and answer them with commands rather than memory:

git remote -v          # is there anywhere else this exists?
git status -sb         # is local ahead of that remote?
git log origin/main..main --oneline   # what exactly isn't pushed?

A fourth project in our audit did have a remote — and was two commits ahead of it, unpushed for weeks. Having a backup and having a current backup are also different things.

Check for secrets before you push, not after

The fix is to create a private repository and push. The mistake is doing that before checking what's in the history. A private repo still puts every committed file on someone else's infrastructure, and rewriting published history is far worse than spending two minutes checking first.

git check-ignore -v .env .env.local .vercel
git log --all --pretty=format: --name-only --diff-filter=A | sort -u \
  | grep -Ei '(^|/)\.env($|\.)|secret|credential|\.pem$'
git grep -InE 'sk_live_|whsec_|-----BEGIN' HEAD

The first command confirms your ignore rules actually cover what you think. The second asks whether an environment file was ever committed — including in a commit you later reverted, which still lives in history. The third scans tracked content for credential patterns.

The general lesson

A working system can mask a missing one. Deploys succeeding tells you the deploy path works; it says nothing about backup, monitoring, or recovery, because those are separate mechanisms that happen to be green at the same time.

If a control matters, it needs its own check. Ours now runs across every project, and it takes about two minutes.