Vercel: miljøvariabler uten .env i Git

Denne veiledningen gjelder et prosjekt som allerede er driftet på Vercel. Du trenger tilgang til innstillingene og må vite hvilke variabler programmet leser. Eksempelet nedenfor gjelder Next.js; variabelnavn fra et annet rammeverk kan ikke overføres automatisk. Veiledningen er basert på offisiell dokumentasjon og er ikke testet med en ekte konto.

Praktisk informasjon om bruk av Ailoot finner du i dokumentasjonen.

Hvorfor du ikke trenger å legge .env til i Git#

En miljøvariabel er en innstilling med et navn og en verdi som et program mottar separat fra kildekoden. Navnet SERVICE_API_KEY gir for eksempel programmet tilgang til verdien av en nøkkel til en ekstern tjeneste. Ikke legg selve nøkkelen i veiledningen, i samtalen med en agent eller i depotet.

Next.js kan laste inn variabler fra lokale .env*-filer. En lokal fil og prosjektinnstillingene i Vercel er likevel to separate steder. Hvis filen ikke pushes til depotet, angir du verdiene separat på vertsplattformen. Standardmalen for create-next-app legger .env-filer til i .gitignore; Next.js-dokumentasjonen advarer om at du nesten aldri bør pushe dem til depotet.

Hvis du fortsatt er usikker på hva som kan lagres i kildefiler, kan du begynne med sikkerhetssjekken for et prosjekt laget med AI. Her ser vi på et mer avgrenset spørsmål: hvor du angir konfigurasjonen for en bestemt Vercel-deployment.

Finn først ut hvor programmet leser variabelen#

Lag en liste over navnene før du legger inn verdier, uten å ta med hemmelighetene. For hvert navn må du finne ut tre ting: hvilket miljø som bruker det, hvor koden som leser variabelen kjører, og når verdien trengs.

Miljøet Development er ment for lokal utvikling. Preview brukes for forhåndsvisningsdeployments, og Production for hovedversjonen som er publisert. Preview kan ha innstillinger for en bestemt Git-branch: disse overstyrer de generelle Preview-innstillingene med samme navn.

I et Next.js-prosjekt er variabler uten NEXT_PUBLIC_ som standard tilgjengelige på serveren. Prefikset NEXT_PUBLIC_ gjør det mulig å bygge verdien inn i JavaScript-koden som sendes til nettleseren. Dette passer for en innstilling som uttrykkelig er offentlig, for eksempel en versjonsmerking som ikke er hemmelig, men ikke for en privat API-nøkkel. Selv uten dette prefikset må programkoden ikke sende en hemmelighet manuelt tilbake til klienten.

Hvis du ennå ikke har funnet ut hvilket rammeverk prosjektet bruker, kan du be agenten identifisere det ut fra prosjektfilene. Sammenligningen av Astro og Next.js kan hjelpe deg med å forstå forskjellene; regelen for NEXT_PUBLIC_ gjelder ikke alle React-programmer.

Konfigurering av hosting er en av oppgavene som inngår i arbeidet med et program sammen med en AI-agent.

Slik legger du til en variabel i et Vercel-prosjekt#

Utfør trinnene selv i det offisielle kontrollpanelet. Ikke gi agenten en ekte nøkkel for å fylle ut skjemaet, og ikke legg ved et skjermbilde som viser verdien.

1. Åpne Vercel-kontrollpanelet og velg riktig prosjekt. Ikke stol utelukkende på at depotnavnet stemmer: kontroller at du konfigurerer programmet du har tenkt å åpne.
2. Gå til Environment Variables i sidemenyen for prosjektinnstillingene.
3. Skriv inn navnet programmet leser, for eksempel SERVICE_API_KEY, i feltet Name. Dette er et eksempel på et navn; hvis koden forventer et annet, bruker du akkurat den skrivemåten.
4. Skriv inn verdien fra stedet der du oppbevarer påloggingsinformasjonen, i feltet Value. Ikke legg den i kildekoden, en chat eller en kontrollogg.
5. Velg miljøet som trenger denne innstillingen. Bruk Preview for å kontrollere en forhåndsvisningsversjon og Production for hovedversjonen. Ikke tilordne én hemmelighet automatisk til alle miljøer.
6. Hvis Preview-innstillingen gjelder en bestemt branch, kontrollerer du den valgte branchen og eventuelle overstyringer med samme navn.
7. Klikk på Save.

Vercel gjør prosjektvariabler tilgjengelige både under builden og når Vercel Functions kjøres på serversiden. At en verdi er tilgjengelig i Vercel, betyr likevel ikke at den kan sendes til nettleseren: det avhenger av programkoden og reglene for rammeverket.

Hvorfor du trenger en ny deployment etter Save#

Når du lagrer en variabel, endres ikke eksisterende deployments. Vercel-dokumentasjonen krever at du deployer prosjektet på nytt for at den nye innstillingen skal nå versjonen du bruker.

Når du arbeider gjennom Git, kan du opprette en ny Production-deployment ved å pushe en commit til branchen som er angitt under Production Branch, og en Preview-deployment ved å pushe til en annen branch. Ikke anta at hovedbranchen alltid heter main: kontroller innstillingen for prosjektet ditt. Dette bør være en vanlig, avtalt prosjektutgivelse, uten at du legger en hemmelig fil til i commiten.

Vent til builden er ferdig etter at deploymenten har startet, og åpne URL-en til den nye deploymenten. Noter URL, miljø og branch. Hvis du kontrollerer den gamle URL-en til en enkeltdeployment, vises ikke de nye innstillingene der.

Next.js har et tilleggsvilkår: referanser som process.env.NEXT_PUBLIC_RELEASE_LABEL erstattes med verdiene sine under next build. Verdien er fast etter builden. Hvis du endrer innstillingen uten å lage en ny build, blir ikke JavaScript-kode på klientsiden som allerede er levert, skrevet om.

Slik kontrollerer du resultatet uten å eksponere nøkkelen#

Begynn med et trygt eksempel: en uttrykkelig ikke-hemmelig merking med navnet NEXT_PUBLIC_RELEASE_LABEL og verdien preview-check. Dette er et eksempel på navn og tekst, ikke en nøkkel eller en test som er utført her. Hvis et Next.js-program leser denne variabelen direkte gjennom process.env.NEXT_PUBLIC_RELEASE_LABEL, kan det vise merkingen på det tiltenkte stedet i grensesnittet etter en ny build. Denne kontrollen bekrefter bare at den offentlige innstillingen ble sendt videre.

En privat nøkkel kontrolleres på en annen måte. Ikke vis verdien, en del av den, lengden på den eller hele process.env. Ikke lag en offentlig URL som returnerer innholdet i variabelen. Kontroller først bare om innstillingen er «til stede / ikke til stede» på serveren, og kontroller deretter separat programfunksjonen som bruker tjenesten. At en innstilling er til stede, beviser ikke at nøkkelen er gyldig eller har de nødvendige tillatelsene.

Du kan registrere resultatene uten hemmeligheter:

• prosjektet, miljøet og branchen samsvarer med det du valgte under konfigureringen;
• du kontrollerer URL-en til en ny deployment som ble opprettet etter at du lagret variabelen;
• builden er ferdig, og den nødvendige programfunksjonen har kjørt med trygge testdata;
• hemmeligheten er ikke eksponert i nettleseren, API-svar, logger eller samtaler.

Hvis funksjonen utfører en betaling, sender en melding eller utfører en annen handling med konsekvenser, bruker du tjenestens angitte testmodus. Å kontrollere konfigurasjonen gir ikke i seg selv tillatelse til å utføre en handling i det virkelige miljøet.

Hva du skal kontrollere hvis verdien fortsatt er undefined#

undefined betyr at ingen verdi ble hentet på dette tilgangspunktet. Gå gjennom navn, miljø og versjon i rekkefølge uten å endre alle innstillingene på én gang.

Selv om du har kontrollert navnet, miljøet og den nye versjonen, beviser ikke en feil i funksjonen at variabelen forårsaket den. Undersøk den konkrete feilen i koden på serversiden uten å publisere diagnostiske data som inneholder hemmeligheter. Denne veiledningen lover ikke å løse alle HTTP 500-svar.

Overgang til din egen server krever en annen fremgangsmåte: se veiledningen for å deploye et prosjekt med Coolify. Vercels knappnavn og konfigureringstrinn gjelder ikke der.

Gå til Ailoot.