Preview-secrets og produktion — samme nøgle er et læk

Et preview-deploy er et løfte om at nogen kan se branchen uden at køre den lokalt. Løftet rådner, når I fylder URL'en med det, produktion bruger til at tage imod penge, gemme kunder og lytte til webhooks. I har ikke gjort review lettere. I har flyttet produktionsadgangen ud på et link, I poster i en kommentar. Den, I inviterede til at 'lige tjekke knappen', kan nu det, I troede kun pipelinen kunne.

Teams gør det, fordi den første preview der fejler på manglende env, bliver mødt med 'sæt de samme som prod, så kommer vi videre'. Det virker. Det bliver vanen. Tre måneder senere har hver PR Stripe live, en connection string til den rigtige base, og et webhook-secret I rullede sidste år. I har ikke et preview-miljø. I har produktion med en anden hostname og uden den gate, I satte på main.

Skaden er konkret. En test-checkout på preview debiterer et rigtigt kort. En seed-script tømmer eller skriver i den rigtige base. Et webhook fra Stripe rammer både prod og den preview, I glemte, fordi I pegede endpointet det forkerte sted. En AI-nøgle på en offentlig preview bliver scrapet. I opdager det, når nogen spørger hvorfor der står to betalinger, eller hvorfor en branch 'lige skulle bruge prod-data'. I retter den ene PR. I rører ikke mappen.

Vi skriver det, fordi 'env er sat' er blevet et tjek, I sætter når buildet er grønt. Et ærligt setup er kedeligt: preview har test-nøgler og en base, I må ødelægge. Produktion har de rigtige, og kun pipelinen til main (eller den host, I faktisk ejer) kan læse dem. Uden det skel har I en .env, I kopierede. I har ikke miljøer.

Et secret er en værdi, der giver adgang til noget, I ikke vil have ude. En API-nøgle, en database-URL, et webhook-secret, en signing key, en service-account. Preview-secret er den variant, I er villige til at lade følge en branch-URL. Produktions-secret er den variant, I kun vil lade den host læse, der tager imod rigtige brugere. Forskellen er ikke navnet på variablen. Forskellen er hvilken dør nøglen åbner.

Det er ikke det samme som 'vi har Preview, Preview, Production i Vercel'. Mapperne er hylder. Hvis I putter den samme værdi på alle tre, har I én hylde med tre labels. Cloudflare, Netlify, GitHub Environments, Doppler, Infisical — samme job. Et skel findes, når preview-værdien ikke kan det, prod-værdien kan. En `STRIPE_SECRET_KEY` der er `sk_live_…` på preview, er produktion. I har bare hængt den på en anden URL.

Det er heller ikke det samme som et staging-miljø. Staging-indlægget er en længelevende kopi, der skal ligne produktion i form: samme migrationer, samme jobs, ofte anonymiseret data. Preview er kortlivet og PR-bundet. De kan dele princippet — egne nøgler — men de er ikke samme job. At kalde preview for staging, fordi URL'en 'ligner', er hvordan I giver en feature-branch adgang til den base, I bruger til UAT med rigtige kunder.

Og det er ikke 'NEXT_PUBLIC_ er fint, det er jo bare public'. Det der er public i bundle, er public på preview og på prod. En publishable Stripe-nøgle er designet til det. En service-rolle, en intern API-token, en database-connection i en client-component er det ikke. Preview gør lækket lettere at finde, fordi URL'en er i en PR, I deler. Byg den vane, at det der lander i klienten, må stå i et screenshot. Resten lever kun på serveren, og kun i det miljø, I mente.

Den første fejl er at kopiere produktion 'så preview ligner'. Checkout virker. Webhooks virker. Cron virker. I har bevist at branchen kan det, produktion kan — med produktionens nøgler. Det er ikke et review. Det er et ekstra produktionsvindue. Retningen er den omvendte: preview skal ligne nok til at I kan se UI og de stier, I kan drive med test-nøgler. Det, I ikke kan drive uden live, slår I fra eller peger på en sandbox.

Den anden fejl er at lade preview kalde rigtige side-effekter. En 'send kvittering'-knap der rammer Resend/Postmark med prod-domænet. En 'kør migration' i en preview-build. En synk til ERP. En Slack-incoming, I bruger til alarms. Hver side-effekt, preview kan udløse, er en side-effekt I har givet til den, der har URL'en. Staging kan have en kontrolleret synk. Preview skal som udgangspunkt ikke have nogen.

Den tredje fejl er at tro at 'Protected' på Vercel eller environment reviewers på GitHub er skellet. Det er en port foran hvem der kan læse eller deploye. Det er godt. Det erstatter ikke forskellige værdier. En beskyttet mappe med prod-nøgler, som I også har sat på Preview så 'designeren kan teste betaling', er stadig et læk. Porten var til main. I åbnede den for en branch, fordi demoen skulle virke.

Den fjerde fejl er secrets i repoet, i preview-logs, eller i client-bundle, I kaldte server. En `.env` I committede 'kun til preview'. En debug-side der printer `process.env`. En server action I sendte til klienten. Preview-logs er oftere åbne for flere øjne end prod-logs. Skriv vanen: nøgler lever i hostens mappe, ikke i git; logs må ikke spejle dem; det der er `NEXT_PUBLIC_` er et screenshot. Sikkerheds-indlægget er headers på www. Her er at nægte at lade PR-URL'en være den der lækker resten.

Checkout er det job, der oftest får live-nøglen 'så kunden kan klikke'. Det er det job, der oftest debiterer to gange. Preview får test-mode, eller den får en skærm der siger at betaling ikke kører her. En designer, der skal se kvitteringssiden, får et fixture eller en staging, I ejer — ikke en PR med sk_live. Stripe, Quickpay, Reepay: sandbox findes, fordi det her job er rigtigt. Brug den.

Webhooks er det job, I glemmer, fordi endpointet 'bare skal pege et sted hen'. Vendor kalder den URL, I har sat i dashboardet. Hvis I sætter en preview-URL, dør endpointet med branchen — eller I lader en gammel preview stå, og den får events, produktion også får. Peg produktion på produktion. Peg sandbox på preview eller på et staging, I har tænkt. To endpoints. To secrets. Ét dashboard-felt, I ikke deler.

Cron og baggrundsjobs er det job, der oftest kører, fordi I genbrugte den samme definition. Et preview-deploy der 'bare starter appen' starter også den synk, I kun ville have om natten på prod. Sæt et flag. Læs miljøet. Nægt at køre. Staging kan have jobs, I har valgt. Preview skal som udgangspunkt sove. En branch, der sender en bunke mails fordi I testede 'reminders', er ikke et miljø. Det er et udbrud.

Den delte demo er det job, I kalder preview, når I mener staging. En URL I sender til bestyrelsen i tre uger, med rigtige (eller rigtigt udseende) data, er ikke en PR. Staging-indlægget er den kopi. Preview dør med branchen og skal tåle at blive slettet. Hvis demoen skal leve, så giv den sit eget miljø og sine egne nøgler — ikke prod, og ikke 'den her PR vi holder åben'. En evig preview med prod-secrets er produktion uden den gate, I satte på main.