Sto cercando di fare il deploy di un'applicazione Next.js su Vercel e ho bisogno di impostare le variabili di ambiente (API keys, URL, ecc). Ho creato un file .env.local qui sulla mia macchina e funziona, ma quando faccio push su GitHub e Vercel fa il build, l'applicazione non riesce ad accedere a queste variabili. Come faccio a passarle in modo sicuro a Vercel?
Il file .env.local non va mai in produzione perché Git lo ignora di default (è nel .gitignore), quindi Vercel non ha accesso a quelle variabili quando fa il deploy. Devi configurare le variabili direttamente nel pannello di Vercel. Accedi al progetto nella dashboard di Vercel, vai su Settings > Environment Variables e aggiungi ogni variabile che ti serve - nome e valore. Se hai variabili che servono solo in sviluppo (tipo test locali), spunta la casella "Development" soltanto. Per quelle che il tuo Next.js deve usare sia sul server che sul client, aggiungile senza restrizioni di ambiente.
Per le variabili che devono stare solo sul server (come API key sensibili), le metti normalmente e le usi nel codice dentro funzioni lato server - getServerSideProps, API routes, Server Components. Next.js automaticamente non le espone al browser. Se hai bisogno di accedere a una variabile dal client, prefissala con NEXT_PUBLIC_ nel nome (tipo NEXT_PUBLIC_API_URL) e diventa disponibile nel browser, ma usalo solo per dati che non sono sensibili.
Dopo che hai configurato tutto su Vercel, fai un nuovo push su GitHub anche senza cambiare nulla, così Vercel fa il rebuild con le variabili che hai settato. Se stai usando preview deployments (deploy automatico di pull request), configura le variabili per girare anche in quegli ambienti di test andando nella sezione "Preview" nelle settings. Consiglio: se hai tante variabili, copia un blocco intero da un ambiente all'altro invece di aggiungerle una per una.
Vai nel dashboard di Vercel, apri il progetto, vai in Settings > Environment Variables e incolla lì le chiavi che usi nel .env.local. Crea una variabile per ognuna (API_URL, API_KEY, quello che serve) e seleziona in quale ambiente ognuna funziona - Development, Preview, Production, o tutti e tre. Dopo di che quando Vercel fa il build, inietta quelle variabili nel processo e l'applicazione riesce ad accedervi tramite `process.env.NOME_DELLA_VARIABILE`.
Adesso, il punto che molti dimenticano frequentemente: se stai usando variabili che possono essere accessibili solo dal server (tipo password di database o API key segrete), devi usare il prefisso `NEXT_PUBLIC_` solo su quelle che vanno lato client. Tutto quello che non ha questo prefisso rimane al sicuro sul server durante il build. Se metti una chiave sensibile con `NEXT_PUBLIC_`, finisce nel JavaScript che il browser scarica - a quel punto non è più sicuro. Allora stai attento a questa convenzione, perché è facile sbagliare.
Un consiglio utile è anche copiare la struttura del tuo .env.local in un file chiamato .env.example (o .env.local.example), togli i valori reali, e fai il commit nel Git. Così chi lavorerà sul progetto sa esattamente quali variabili deve configurare sia localmente che su Vercel.
Non mettere mai le chiavi sensibili nel repository, nemmeno "solo per ora" - poi te ne dimentichi e finiscono per venire fuori. I ragazzi lì hanno già spiegato bene come fare dal dashboard, ma c'è un dettaglio importante: quando hai variabili che devono essere disponibili nel browser (tipo una chiave API pubblica), devi aggiungere il prefisso `NEXT_PUBLIC_` su Vercel, altrimenti non arrivano al client-side. Quelle che invece devono rimanere solo sul server (come le credenziali del database), le lasci senza prefisso e girano lato server - le puoi accedere solo in getServerSideProps, API routes, ecc. Questo evita di esporre dati che non dovrebbero essere visibili nel codice sorgente.
Gente già ha spiegato bene, ma aggiungo un dettaglio: oltre a mettere le variabili nella dashboard, assicurati di usare la sintassi giusta nel tuo codice - in Next.js, le variabili che cominciano con `NEXT_PUBLIC_` diventano visibili nel browser (serve per URL pubblici, per esempio), mentre le altre rimangono solo sul server, il che è importante per le chiavi sensibili.
L'ho imparato nel modo più difficile quando ho provato a esporre una API key senza volerlo, e ho scoperto che il browser riusciva ad accedervi perché avevo messo `NEXT_PUBLIC_` davanti. Adesso controllo sempre due volte qual è lo scopo di quella variabile prima di configurarla.
Accediper rispondere.
