Mettere un sito Next.js su una VPS invece che su Vercel

Quello che Vercel fa e che dovrai fare tu

Questa è la sezione più importante, e quasi nessuno la scrive. Vercel non è «un posto dove sta il sito»: è una decina di servizi messi insieme. Spostandosi su una VPS, ognuno diventa un lavoro tuo.

Quando conviene spostarsi, e quando no

La risposta onesta dipende da tre cose: quanto traffico fai, quanto controllo ti serve, e quanto tempo hai.

1. 1

   Conviene spostarsi se…

   Hai superato la soglia gratuita e la fattura cresce. Ti serve qualcosa che Vercel non fa: un database sulla stessa macchina, un programma che gira in sottofondo, cartelle di file che crescono. Vuoi che i dati restino in Europa per scelta. Ti diverte amministrare un server e lo faresti comunque.

   • Costo fisso e prevedibile
   • Puoi metterci altre cose sulla stessa macchina
   • Nessun limite di funzioni o di banda imposto da altri
2. 2

   Non conviene se…

   Il sito sta dentro il piano gratuito e ci resterà. Il traffico arriva da tutto il mondo e la velocità conta. Non hai voglia di ricevere un avviso alle tre di notte. È l'unico sito che gestisci e non hai un secondo posto dove provare le modifiche.

   • Gli aggiornamenti di sicurezza diventano tuoi
   • Un server solo è un punto di rottura solo
   • I backup li devi fare e — soprattutto — provare

La riga che cambia tutto

Next.js ha una modalità pensata proprio per questo. Si aggiunge una riga in next.config.mjs:

output: 'standalone'

Da quel momento la costruzione produce, dentro .next/standalone, un pacchetto che contiene tutto quello che serve: il server, le dipendenze davvero usate, il codice del sito. Sulla VPS non serve installare niente — niente npm install, niente attesa, niente sorprese perché la versione di una libreria è cambiata fra il tuo computer e il server.

Sul sito che stai leggendo il pacchetto pesa 170 MB in tutto, comprese le immagini, e il server è pronto in meno di un secondo.

La procedura completa

Dall'inizio alla fine. Serve una VPS con Debian o Ubuntu e l'accesso SSH.

1. Prepara la VPS. Aggiorna il sistema, crea un utente non amministratore per far girare il sito, e installa Node nella versione che usi sul tuo computer — la stessa, non una qualsiasi.
2. Chiudi le porte. Lascia aperte solo la 22 (SSH), la 80 e la 443. Tutto il resto va chiuso: il sito parlerà con il proxy, non con il mondo.
3. Costruisci sul tuo computer, non sul server: npm run build con output: 'standalone' attivo. Costruire sul server significa tenerci le dipendenze di sviluppo e il codice sorgente, che non servono.
4. Copia le tre cartelle sulla VPS con rsync: .next/standalone, .next/static dentro una cartella .next, e public.
5. Avvia il sito: node server.js, con la porta scelta in una variabile d'ambiente. Provalo subito con un curl sulla porta interna: se risponde, il difficile è finito.
6. Fallo ripartire da solo. Un servizio di sistema (systemd) che lo riavvia se si ferma e lo riaccende al riavvio della macchina. È la parte che distingue una prova da un sito in produzione.
7. Metti il proxy davanti (sezione dopo) e collega il dominio.
8. Prova tutto prima di spostare il dominio: le pagine, le immagini, i reindirizzamenti vecchi, la mappa del sito. Il momento per scoprire un difetto è adesso, non quando il traffico è già lì.

Il reverse proxy e il certificato HTTPS

Il sito gira su una porta interna, per esempio la 3000. Davanti ci va un programma che riceve le richieste dal mondo, le passa al sito, e si occupa del certificato HTTPS.

Le due scelte sono Caddy e nginx. Per chi comincia, Caddy: prende il certificato da solo, lo rinnova da solo, e la configurazione è di tre righe invece di trenta. nginx è più diffuso e più configurabile, ma il certificato va impostato a parte.

Il proxy fa anche una cosa che migliora molto la velocità: serve i file statici direttamente — immagini, stili, codice — senza disturbare il programma del sito. Sono la maggior parte delle richieste.

1. Installa Caddy dal repository ufficiale della tua distribuzione.
2. Scrivi il file di configurazione: il tuo dominio, e reverse_proxy verso localhost e la porta del sito.
3. Aggiungi una regola per i file statici con una scadenza lunga: i file di Next hanno il codice nel nome, quindi si possono tenere in memoria per un anno senza rischi.
4. Riavvia Caddy. Il certificato arriva da solo in pochi secondi, se il dominio punta già alla VPS.
5. Controlla che http rimandi a https: Caddy lo fa da solo, ma va verificato.

Come si pubblica un aggiornamento

Su Vercel basta un push. Sulla VPS serve uno script tuo, ed è meglio scriverlo il primo giorno che la decima volta a mano.

Lo schema che funziona: costruisci in locale, copia in una cartella nuova sulla VPS, e solo quando la copia è finita sposti il collegamento e riavvii. Così il sito è fermo un secondo invece che per tutta la durata della copia — e se qualcosa va storto, la cartella vecchia è ancora lì.

1. npm run build sul tuo computer.
2. rsync delle tre cartelle in /var/www/sito-.
3. Sposta il collegamento /var/www/attuale sulla cartella nuova.
4. systemctl restart del servizio del sito.
5. curl sulla home per controllare che risponda: se no, rimetti il collegamento sulla cartella precedente e riavvia. È il ritorno indietro, e deve essere un comando solo.
6. Tieni le ultime tre cartelle e cancella le più vecchie.

I cinque modi di sbagliare

Sono quelli che si vedono più spesso.

1. Dimenticare .next/static. Il sito si apre senza grafica e sembra rotto. È l'errore numero uno.
2. Avviarlo a mano senza un servizio di sistema. Funziona finché non chiudi il terminale.
3. Costruire sul server. Ci lasci il codice sorgente e le dipendenze di sviluppo, e se la memoria della VPS è poca la costruzione fallisce a metà.
4. Non fare i backup, o non provarli. Un backup mai ripristinato non è un backup: è un file di cui non sai niente.
5. Non impostare nessun avviso. Se il sito cade e te ne accorgi da un messaggio di un lettore, hai perso una giornata di visite. Un controllo che chiama la home ogni cinque minuti e avvisa è mezz'ora di lavoro.