Preview secrets and production — the same key is a leak

A preview deploy is a promise that someone can see the branch without running it locally. The promise rots when you fill the URL with what production uses to take money, store customers and listen to webhooks. You have not made review easier. You have moved production access onto a link you paste in a comment. The person you invited to 'just check the button' can now do what you thought only the pipeline could.

Teams do it because the first preview that fails on a missing env is met with 'put the same as prod so we can move on'. It works. It becomes the habit. Three months later every PR has Stripe live, a connection string to the real base, and a webhook secret you rolled last year. You do not have a preview environment. You have production with a different hostname and without the gate you put on main.

The damage is concrete. A test checkout on preview charges a real card. A seed script empties or writes the real base. A webhook from Stripe hits both prod and the preview you forgot, because you pointed the endpoint at the wrong place. An AI key on a public preview gets scraped. You notice when someone asks why there are two charges, or why a branch 'just needed prod data'. You fix that one PR. You do not touch the shelf.

We write this because 'env is set' has become a tick you add when the build is green. An honest setup is boring: preview has test keys and a base you are allowed to break. Production has the real ones, and only the pipeline to main (or the host you actually own) can read them. Without that split you have a .env you copied. You do not have environments.

A secret is a value that opens something you do not want out. An API key, a database URL, a webhook secret, a signing key, a service account. A preview secret is the variant you are willing to let follow a branch URL. A production secret is the variant you only want the host that takes real users to read. The difference is not the variable name. The difference is which door the key opens.

It is not the same as 'we have Preview, Preview, Production in Vercel'. The scopes are shelves. If you put the same value on all three, you have one shelf with three labels. Cloudflare, Netlify, GitHub Environments, Doppler, Infisical — same job. A split exists when the preview value cannot do what the prod value can. A `STRIPE_SECRET_KEY` that is `sk_live_…` on preview is production. You just hung it on another URL.

It is also not the same as a staging environment. The staging post is a long-lived copy that should look like production in shape: the same migrations, the same jobs, often anonymised data. Preview is short-lived and PR-bound. They can share the principle — their own keys — but they are not the same job. Calling preview staging because the URL 'looks like it' is how you give a feature branch access to the base you use for UAT with real customers.

And it is not 'NEXT_PUBLIC_ is fine, it is public anyway'. What is public in the bundle is public on preview and on prod. A publishable Stripe key is designed for that. A service role, an internal API token, a database connection in a client component is not. Preview makes the leak easier to find, because the URL lives in a PR you share. Build the habit that what lands in the client may stand in a screenshot. The rest lives only on the server, and only in the environment you meant.

The first failure is copying production 'so preview looks like it'. Checkout works. Webhooks work. Cron works. You have proved the branch can do what production can — with production's keys. That is not a review. It is an extra production window. The direction is the opposite: preview should look like enough that you can see the UI and the paths you can drive with test keys. What you cannot drive without live, you turn off or point at a sandbox.

The second failure is letting preview call real side effects. A 'send receipt' button that hits Resend/Postmark with the prod domain. A 'run migration' in a preview build. A sync to the ERP. A Slack incoming you use for alarms. Every side effect preview can fire is a side effect you have given to whoever has the URL. Staging may have a controlled sync. Preview should, as a default, have none.

The third failure is believing that 'Protected' on Vercel or environment reviewers on GitHub is the split. That is a gate in front of who can read or deploy. It is good. It does not replace different values. A protected shelf with prod keys that you also put on Preview so 'the designer can test payment' is still a leak. The gate was for main. You opened it for a branch because the demo had to work.

The fourth failure is secrets in the repo, in preview logs, or in a client bundle you called server. A `.env` you committed 'only for preview'. A debug page that prints `process.env`. A server action you sent to the client. Preview logs are more often open to more eyes than prod logs. Write the habit: keys live in the host's shelf, not in git; logs must not echo them; what is `NEXT_PUBLIC_` is a screenshot. The security post is headers on www. This is refusing to let the PR URL be the one that leaks the rest.

Checkout is the job that most often gets the live key 'so the client can click'. It is the job that most often charges twice. Preview gets test mode, or it gets a screen that says payment does not run here. A designer who needs to see the receipt page gets a fixture or a staging you own — not a PR with sk_live. Stripe, Quickpay, Reepay: the sandbox exists because this job is real. Use it.

Webhooks are the job you forget, because the endpoint 'just has to point somewhere'. The vendor calls the URL you set in the dashboard. If you set a preview URL, the endpoint dies with the branch — or you leave an old preview standing, and it gets events production also gets. Point production at production. Point sandbox at preview or at a staging you meant. Two endpoints. Two secrets. One dashboard field you do not share.

Cron and background jobs are the job that most often runs because you reused the same definition. A preview deploy that 'just starts the app' also starts the sync you only wanted at night on prod. Set a flag. Read the environment. Refuse to run. Staging may have jobs you chose. Preview should, as a default, sleep. A branch that sends a pile of mail because you tested 'reminders' is not an environment. It is a breach.

The shared demo is the job you call preview when you mean staging. A URL you send to the board for three weeks, with real (or real-looking) data, is not a PR. The staging post is that copy. Preview dies with the branch and must tolerate being deleted. If the demo must live, give it its own environment and its own keys — not prod, and not 'this PR we keep open'. An eternal preview with prod secrets is production without the gate you put on main.