</> HTML5Advent
ENFRESDEITPT

// hosting · Web Platform Advent #14

Come ospitare un'app Node.js: VPS, PaaS e serverless

I modi pratici per fare il deploy di un'applicazione Node.js — VPS, PaaS gestito o serverless — più PM2, un reverse proxy, le variabili d'ambiente e un flusso di deploy sensato.

Una mano inserisce una blade server in un rack di server illuminato di blu

Ospitare un'app Node.js è diverso dall'ospitare un sito statico o una pagina PHP. Node esegue un processo a lunga durata che possiede il proprio server HTTP, quindi l'host deve mantenere vivo quel processo, riavviarlo in caso di crash e instradare verso di esso il traffico pubblico. Questa guida ti accompagna attraverso le tre opzioni realistiche e i componenti di cui hai bisogno indipendentemente da quella che scegli.

Tre modi per ospitare Node.js

Quasi ogni deployment ricade in uno di questi modelli. La scelta giusta dipende da quanta parte del server vuoi gestire e da come si comporta il tuo traffico.

  • VPS (autogestito) — ottieni una macchina Linux e accesso root completo. Massimo controllo e costi prevedibili, ma installi e mantieni tu stesso Node, il process manager, il reverse proxy e il TLS.
  • PaaS (platform-as-a-service) — fai il push del codice (spesso via Git) e la piattaforma costruisce, esegue e scala il processo al posto tuo. Meno controllo, più veloce nel rilascio, di solito a consumo.
  • Serverless / functions — fai il deploy di singoli handler anziché di un server in esecuzione. La piattaforma li avvia su richiesta. Ottimo per carichi di lavoro irregolari o a basso traffico, ma stateless e soggetto a cold start.

Mantenere vivo il processo con PM2

Su un VPS, eseguire node server.js nella tua shell si interrompe nel momento in cui ti disconnetti, e nulla lo riavvia dopo un crash. Un process manager risolve entrambe le cose. PM2 è la scelta più comune:

npm install -g pm2

# start the app and name it
pm2 start server.js --name web

# restart automatically after a server reboot
pm2 startup
pm2 save

# useful day-to-day commands
pm2 list
pm2 logs web
pm2 restart web

PM2 esegue la tua app anche in modalità cluster per usare ogni core della CPU, il modo più semplice per scalare una singola macchina:

pm2 start server.js --name web -i max
Una fila di server montati a rack in un data center
Su un VPS il tuo processo Node gira su una macchina fisica o virtuale come queste; un process manager lo tiene in esecuzione e un reverse proxy lo espone al web.

Un reverse proxy davanti a Node

Non esporre Node direttamente sulla porta 80/443. Metti davanti un reverse proxy come Nginx: termina il TLS, serve i file statici in modo efficiente e può instradare più app su una sola macchina. Un blocco server Nginx minimale che inoltra il traffico a un'app Node in ascolto sulla porta 3000:

server {
  listen 80;
  server_name example.com;

  location / {
    proxy_pass http://127.0.0.1:3000;
    proxy_http_version 1.1;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection 'upgrade';
    proxy_set_header Host $host;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Proto $scheme;
  }
}

Gli header Upgrade e Connection contano se la tua app usa i WebSocket. Per l'HTTPS, la via usuale è un certificato gratuito di Let's Encrypt tramite certbot, che modifica questa configurazione al posto tuo.

Variabili d'ambiente e configurazione

Non scrivere mai segreti (URL di database, chiavi API) direttamente nel tuo sorgente. Leggili dall'ambiente con process.env e lascia che sia la piattaforma a iniettarli:

const port = process.env.PORT || 3000;
const dbUrl = process.env.DATABASE_URL;

app.listen(port, () => {
  console.log(`listening on ${port}`);
});

Su un VPS puoi tenerli in un file .env (caricato da una libreria ed escluso da Git) oppure passarli tramite il file ecosystem di PM2. Su una PaaS li imposti nella dashboard. Leggi sempre process.env.PORT — le piattaforme gestite assegnano la porta al posto tuo.

Un flusso di deploy sensato

Comunque tu ospiti, punta a un deploy ripetibile anziché a modificare i file sul server a mano:

  • Recupera il nuovo codice (git pull o un artefatto di CI).
  • Installa solo le dipendenze di produzione: npm ci --omit=dev.
  • Esegui lo step di build se ne hai uno (npm run build).
  • Ricarica il processo senza downtime: pm2 reload web.

Su una PaaS l'intera sequenza è innescata da un git push; su un VPS puoi scriverla in uno script o collegarla a un CI runner.

Quale opzione fa al caso tuo?

OpzioneGestisciIdeale quando
VPSOS, Node, PM2, Nginx, TLSVuoi controllo e costi prevedibili
PaaSSolo il tuo codice + variabili d'ambienteVuoi rilasciare in fretta e scalare facilmente
ServerlessSingoli handlerTraffico irregolare o basso, lavoro stateless

Se stai iniziando, un singolo VPS ben configurato con PM2 e Nginx eseguirà comodamente la maggior parte delle app Node e ti insegnerà cosa automatizzano le piattaforme gestite. Passa a una PaaS o al serverless quando lo scaling o l'overhead operativo diventano il collo di bottiglia — non prima.