Sviluppo web

Vercel CLI dal terminale: deploy, log e variabili d'ambiente

Installazione, login e deploy da terminale: cosa scrive `vercel link`, come si leggono i log e come un token elimina ogni prompt in CI.

In sintesi

  • `vercel login` salva il token una volta; `vercel` pubblica un'anteprima e `vercel --prod` la produzione, con licenza Apache 2.0 del CLI.
  • `vercel link` scrive `.vercel/project.json` con `orgId` e `projectId`: è un riferimento locale da mettere in `.gitignore`.
  • In CI `pull`, `build` e `deploy --prebuilt` con `--token` eliminano ogni prompt e ricostruiscono lo stesso artefatto.

Risposta breve: dalla radice del progetto esegui vercel login una volta, poi vercel per un deployment di anteprima e vercel --prod per la produzione. Il CLI fa le stesse cose della dashboard, senza aprire il browser.

Installazione e primo deploy

npm i -g vercel@latest
vercel login
vercel
vercel --prod

Il login chiede conferma dell'email e salva il token in ~/.vercel. Il primo vercel risponde a tre domande: scope, nome del progetto e cartella. Dalla seconda volta in poi il comando non chiede più nulla.

Il CLI crea la cartella .vercel con project.json, che contiene orgId e projectId. Servono a legare la cartella al progetto giusto. Metti .vercel in .gitignore: è un riferimento locale, non configurazione condivisa.

Log e ispezioni dal terminale

vercel list
vercel inspect https://my-app-abc123.vercel.app
vercel logs https://my-app-abc123.vercel.app

list stampa gli ultimi deployment con stato e data, inspect mostra build, durata e regioni, logs segue i log di runtime di quel deployment. Sono le tre ragioni per cui si apre la dashboard.

Variabili d'ambiente, un ambiente alla volta

vercel env add DATABASE_URL production
vercel env ls
vercel env pull .env.local

env add chiede il valore e lo salva cifrato. env pull scrive un file locale con i valori dell'ambiente di sviluppo: non committarlo, contiene segreti veri e non segnaposto.

Deploy non interattivo in CI

vercel pull --yes --environment=production --token=$VERCEL_TOKEN
vercel build --prod --token=$VERCEL_TOKEN
vercel deploy --prebuilt --prod --token=$VERCEL_TOKEN

Con un token il CLI non apre nessun prompt: pull scarica le variabili, build costruisce in locale, deploy --prebuilt carica l'artefatto. Lo schema è nella documentazione del CLI; il codice del CLI è Apache 2.0 nel repository vercel/vercel.

Limite dichiarato

vercel dev non riproduce la rete edge, la cache ISR né i limiti di esecuzione della produzione. Un comportamento che passa in locale può cambiare dopo il deploy: misura la latenza sul dominio reale, non su localhost.

Dove continuare

Nel catalogo trovi la libreria AI Elements di Vercel, il record system monitor e la tabella dei log. Per il resto leggi 404 dopo il deploy in App Router, gli errori di build comuni e il confronto analytics Vercel o self-hosted.

Domande frequenti

Serve un account Vercel per usare il CLI?

Sì. Il CLI autentica un account o un team: senza login i comandi di deploy rispondono con un errore di autenticazione. Il piano gratuito basta per un progetto personale con deploy di anteprima.

Dove finisce il token di accesso?

In un file di configurazione nella cartella home dell'utente, sotto .vercel. Non è nel repository: se lavori su una macchina condivisa, esci con vercel logout alla fine della sessione.

Posso usare il CLI senza installarlo globalmente?

Sì. npx vercel esegue la stessa versione senza installazione globale, e in CI conviene fissare la versione nel package.json per non dipendere dall'ultima release.

Come leggo i log di un deployment già online?

Con vercel logs seguito dall'URL del deployment. Il comando resta in ascolto: per un controllo singolo conviene vercel inspect, che stampa build, durata e regioni e poi esce.

Il deploy da CLI è diverso da quello via Git?

Il risultato è lo stesso artefatto, ma l'origine cambia: un deploy da CLI non è collegato a un commit e non aggiorna lo stato della pull request. Per la produzione conviene un solo canale, non due.