Come spostare un'app Vercel su un VPS

Vercel è una soluzione eccellente, finché l'impatto delle fatture, le limitazioni della piattaforma o la necessità di maggiore controllo non generano la sensazione che la porta d’ingresso della tua app appartenga a qualcun altro.

In sintesi: per migrare un'applicazione da Vercel a un server proprietario, occorre ricostruire l'infrastruttura sottostante che la piattaforma gestiva in automatico: ambiente di esecuzione (runtime), variabili d’ambiente, instradamento dei domini, certificati HTTPS, flussi di deployment e procedure di backup. Il percorso più sicuro prevede la configurazione completa del nuovo server e la relativa fase di test su un indirizzo temporaneo, aggiornando i record DNS solo a piena operatività confermata.

Cosa cambia quando passi da Vercel al tuo server?

Vercel può essere paragonato a un appartamento ad uso residence: fornisci gli arredi — il codice sorgente — mentre la piattaforma gestisce in autonomia accessi, utenze, manutenzione e servizi accessori.

Gestire un server proprietario equivale invece a rilevare l'intero immobile: garantisce una libertà d'azione superiore, ma richiede la piena conoscenza dell'impianto tecnico. Non significa dover assumere il ruolo di un sistemista a tempo pieno, ma implica rendere trasparenti e gestibili tutti quei processi precedentemente automatizzati.

La vera evoluzione è di prospettiva: Vercel astrae e nasconde l'operatività; un server dedicato trasforma l'infrastruttura in parte integrante del ciclo di vita del progetto.

Per progetti di dimensioni contenute questo passaggio è del tutto lineare. Se desideri un'introduzione graduale ai concetti di gestione server, suggeriamo la lettura di pubblicare una piccola web app senza DevOps.

Di cosa hai bisogno prima di spostare un'app Vercel?

Il primo passo consiste nell'eseguire un censimento rigoroso di ogni risorsa che Vercel impiega per far funzionare l'applicazione.

Parti dalle variabili d’ambiente: rappresentano la configurazione fondamentale che l'app consulta a runtime, come endpoint dei database, chiavi API, segreti di autenticazione, token di pagamento e parametri pubblici (ad esempio NEXT_PUBLIC_API_URL). L'omissione di un singolo parametro può consentire l'avvio dell'applicazione ma causare errori imprevedibili in fase d'uso.

Definisci con precisione i processi di compilazione e avvio. Un'architettura basata su Next.js, ad esempio, necessita di una fase di build e di un successivo processo server permanente. Un'applicazione puramente statica richiede invece la semplice erogazione di asset tramite web server. Eventuali background worker o sistemi di gestione delle code rappresentano componenti autonome e richiedono una configurazione dedicata.

Verifica la collocazione della base dati. Se utilizzavi un provider database esterno collegato a Vercel, puoi mantenerlo inalterato. Se la migrazione include anche il database, pianifica l'operazione come un processo indipendente con specifiche procedure di salvataggio e ripristino.

Mappa infine l'intera infrastruttura dei nomi di dominio: dominio principale, host www, eventuali ambienti di preview e sottodomini dedicati ai servizi API. Un'errata configurazione DNS è tra le cause più frequenti di inaccessibilità di un'applicazione trasferita, anche a fronte di un codice perfettamente funzionante.

Come sposti l’app senza romperla?

Evita di aggiornare subito i puntamenti del dominio: sarebbe l'equivalente di inaugurare un'attività prima di aver completato l'allestimento interno.

Predisponi l'ambiente sul nuovo server mentre l'infrastruttura Vercel rimane attiva e continua a servire il traffico degli utenti. Esegui la build del codice, configura le variabili d’ambiente, connetti la base dati ed effettua tutti i collaudi necessari attraverso un sottodominio di test o un indirizzo IP temporaneo.

Concentrati sui flussi operativi critici e non fermarti alla sola pagina iniziale: collauda le procedure di login, l'invio dei moduli di contatto, la generazione di notification email, il caricamento di file e le chiamate verso le API. Se l'applicazione impiega il rendering lato server (SSR), verifica con attenzione le rotte che eseguono query al database a ogni richiesta.

In caso di errore 502 Bad Gateway, ricorda che indica la corretta risposta del proxy inverso (o web server) a fronte di un'applicazione a monte che non risponde. Le cause spaziano dal crash del processo Node.js a una porta di rete errata, fino a variabili d'ambiente mancanti o tempi di avvio eccessivi.

Una volta verificata la stabilità dell'applicazione, procedi con l'aggiornamento dei record DNS verso il nuovo server. Poiché la propagazione dei DNS richiede un tempo fisiologico, mantieni attivo il progetto su Vercel durante la transizione per servire gli utenti la cui connessione punta ancora ai vecchi indirizzi.

Ad aggiornamento completato, attiva la cifratura HTTPS. Un certificato SSL valido elimina gli avvisi di protezione del browser e garantisce la riservatezza delle comunicazioni. Per una guida pratica sul tema, consulta come ottenere HTTPS gratis sul tuo server.

Cosa va storto di solito dopo aver lasciato Vercel?

Il fattore di rischio principale è rappresentato dalle variabili d’ambiente omesse o errate. L'applicazione può completare la fase di build senza anomalie per poi interrompersi non appena un utente tenta un'autenticazione o un pagamento. Non occorre solo ricopiare i nomi dei parametri, ma assicurarsi della correttezza dei valori previsti per l'ambiente di produzione.

La seconda criticità riguarda la mancanza di un processo di deployment automatizzato. Vercel garantisce la pubblicazione diretta da repository Git a produzione; sul server proprietario è indispensabile strutturare un flusso di deployment replicabile e documentato, evitando procedure manuali soggette a errore.

Un terzo elemento spesso trascurato è la gestione del filesystem persistente. Se l'applicazione consente l'upload di contenuti da parte degli utenti e li salva su disco locale, tali risorse risiederanno direttamente sul server, richiedendo opportune strategie di storage e piani di backup dedicati.

La quarta insidia riguarda il dimensionamento delle risorse fisiche. Un server con poca memoria RAM può mostrare prestazioni adeguate a riposo, ma crollare improvvisamente durante una compilazione o sotto un picco di traffico. Se hai dubbi sulla configurazione hardware ideale, consulta che dimensione di server ti serve per valutare il fabbisogno di CPU, RAM e spazio disco.

I backup rappresentano una componente imprescindibile. Prima di effettuare lo switch definitivo, devi avere la certezza matematica di poter ripristinare il sistema a fronte di un deploy fallito, una corruzione del database o l'eliminazione accidentale di directory di sistema. Un backup non collaudato non offre alcuna garanzia di tenuta.

FAQ

Posso spostare un’app Next.js da Vercel? Sì. È sufficiente disporre di un server in grado di eseguire l'applicazione Next.js compilata, replicando la medesima configurazione di variabili d'ambiente e i puntamenti DNS previsti in origine su Vercel.

Le variabili d’ambiente di Vercel si spostano automaticamente? No. Devono essere ricreate manualmente nella nuova configurazione di hosting, prestando massima attenzione alla tutela delle chiavi riservate.

È necessario l'uso di Docker? Non è obbligatorio. Docker semplifica il confezionamento e l'isolamento dell'applicazione, ma un'app semplice può essere eseguita direttamente sull'ambiente del server se il runtime è ben definito.

Posso mantenere il database sul provider attuale? Certamente. La migrazione dell'applicazione e lo spostamento della base dati sono due operazioni distinte e indipendenti.

**Perché si verifica l'errore 502 Bad Gateway dopo la migrazione?** Significa che il proxy inverso è raggiungibile, ma il processo sottostante dell'applicazione è arrestato, configurato in modo errato o non in ascolto sulla porta di rete prevista.

La soluzione semplificata

Server Manager ti aiuta a gestire la migrazione dell'applicazione mantenendo l'architettura chiara e ordinata, evitando che le configurazioni si disperdano in appunti estemporanei. Il risultato è un sistema trasparente in cui domini, certificati HTTPS, processi applicativi e parametri d'ambiente rimangono tracciabili e consultabili anche nel tempo.

Questo approccio previene i problemi tipici del post-migrazione da Vercel: credenziali mancanti, puntamenti DNS errati, certificati SSL scaduti o non validi, conflitti tra progetti o flussi di deployment non documentati.

Il vero vantaggio risiede nella chiarezza architetturale: quando si verifica un'anomalia di autenticazione o un errore 502 Bad Gateway, l'analisi del problema non parte mai da un'incognita, ma da una mappa precisa delle componenti in gioco.

Qual è il risultato quando lo spostamento è finito?

Una migrazione da Vercel eseguita con criterio si distingue per la sua invisibilità operativa: gli utenti continuano ad accedere allo stesso dominio, la cifratura HTTPS rimane attiva, le sessioni funzionano regolarmente, i deployment sono automatizzati e i backup sono pienamente operativi.

Consegui il pieno controllo dell'infrastruttura mantenendone la totale intelligibilità. È questa la vera vittoria: la tua applicazione risiede in un ambiente proprietario e gestibile, con una configurazione ordinata e pronta per qualsiasi evoluzione futura.