Come Eseguire Node.js su un VPS

Heroku ha eliminato il suo livello gratuito e ha aumentato il limite minimo. Vercel addebita per ogni utente e interrompe i lavori che durano troppo. Render e Railway aumentano il prezzo con il traffico.

Apri la più recente fattura del tuo fornitore di hosting. L’app Node, un database Postgres e una cache Redis. Tre voci, tre serie di avvisi di superamento, una discussione frenetica su Slack il giorno in cui il marketing lancia finalmente una campagna.

Quella fattura è il motivo per cui molte squadre stanno rivalutando l’VPS. Node.js di per sé non si preoccupa di dove viene eseguito. L’unica cosa da cui il serverless ti proteggeva era scoprire cosa succede dopo ‘npm start’.

Diamo un’occhiata a un modello di configurazione per la produzione per Node.js su una macchina Linux sotto il tuo controllo. Se puoi accedere tramite SSH a una macchina e leggere un file di configurazione, alla fine avrai uno stack di produzione che potrai gestire per anni con un paio di ore di manutenzione al mese.

Quando Ha Senso Usare Node.js su un VPS?

Un VPS è la casa giusta per Node.js quando hai un processo a lungo termine, uno stack che vuoi consolidare in una fattura unica, o una fattura di runtime gestito che ha superato la convenienza.

In generale, ci sono tre buone opzioni:

Processi di lunga durata: Server WebSocket, lavoratori di coda, programmatori di cron, server MCP. Qualsiasi cosa che deve rimanere in esecuzione e in ascolto. La maggior parte delle piattaforme serverless è ancora ottimizzata per esecuzioni e cicli di richiesta di breve durata. Un processo Node su un VPS rimane lì.
Consolidamento dei costi: App Node, Postgres, Redis, più un piccolo lavoratore di costruzione vivono tutti sulla stessa scatola da 4 GB. Una sola voce di fattura, non quattro.
App che hanno superato PaaS: Timeout delle funzioni sul tuo lungo lavoro di generazione PDF. Prezzo per postazione su un team che finalmente ha assunto un quarto ingegnere. Una fattura di Heroku che supera i $60 al mese per un carico di lavoro che funziona bene su un VPS da $15.

E ci sono tre sbagliati adattamenti:

Siti statici e contenuti SSG: Un’esportazione di Next.js, una build di Astro, un blog di Gatsby. Il livello gratuito di Vercel è lo strumento giusto. Un VPS è eccessivo.
Carichi di lavoro guidati da eventi e sporadici: AWS Lambda o Cloudflare Workers costano pochi centesimi per un webhook che viene eseguito dieci volte al giorno. Un VPS costa lo stesso sia che l’applicazione sia attiva o inattiva.
App in tempo reale scalate orizzontalmente: Se il tuo server WebSocket deve distribuire a 100.000 connessioni contemporanee, un VPS non è la risposta. Quella è un cluster Kubernetes, un’infrastruttura distribuita ai margini o una piattaforma gestita in tempo reale.

JavaScript è il linguaggio più usato nel Sondaggio degli Sviluppatori di Stack Overflow 2025, e Node.js rimane uno dei modi predefiniti con cui gli sviluppatori eseguono JavaScript sul backend. Questo significa che ci sono molte persone che eseguono Node in qualche luogo. Questo articolo è per la fetta di loro che sarebbe più felice di gestirlo su un server di cui hanno il controllo.

Ho visto team trasferire quattro servizi Node di produzione da Heroku su un unico VPS da 4 GB, con la stessa disponibilità, un terzo della bolletta, e WebSockets a lunga durata che finalmente funzionavano senza bisogno di soluzioni provvisorie.

La migrazione consiste principalmente in un pomeriggio di ‘apt install’, un ‘pm2 start’ e un cambio di DNS.

Quali Specifiche VPS Richiede Effettivamente Node.js?

Node.js è di per sé leggero. Un server Express minimo può rimanere inattivo ben al di sotto dei 100 MB di memoria residente. Il consiglio che “Node ha bisogno solo di 1 GB” che puoi ancora trovare nei blog più vecchi è tecnicamente vero e praticamente inutile. Entro il tempo in cui hai aggiunto Postgres, Redis, log e un processo di distribuzione che non è tenuto insieme dalla speranza, stai già superando quel limite in un giorno tranquillo.

Dimensionamento realistico per carichi di lavoro comuni:

Carico di lavoro	RAM	vCPU	Archiviazione	Note
API Express di piccole dimensioni, nessun DB sulla macchina	2 GB	1-2	40 GB NVMe	Piano realistico per una app in produzione
API Node + Postgres + Redis su una macchina	4 GB	2	80 GB NVMe	Il punto ideale; la maggior parte dei team si posiziona qui
App pesante SSR (Next.js, Nuxt, Remix)	8 GB	4	80 GB NVMe	Rendering SSR e pipeline di costruzione sono dove va la memoria
App in tempo reale/WebSocket, scala moderata	8 GB	4	80 GB NVMe	Ogni connessione persistente consuma memoria

Alcuni dettagli da definire prima di procedere:

L’Importanza dello Storage NVMe Rispetto alla Dimensione del Disco: Le app Node moderne accedono a migliaia di piccoli file durante installazioni, compilazioni e avvio. Dischi lenti peggiorano sensibilmente le installazioni di dipendenze, gli avvii a freddo e le ricostruzioni SSR.
Virtualizzazione KVM, Non OpenVZ: I piani basati su OpenVZ più vecchi condividono un kernel con l’host, il che può significare versioni del kernel datate e occasionali problemi di compatibilità con runtime più recenti. Ora la maggior parte dei fornitori di VPS affidabili utilizza solo KVM, ma vale comunque la pena verificarlo.
Spazio di Swap: Abilita 1-2 GB di swap sui box più piccoli. L’heap V8 di Node può variare notevolmente durante la raccolta dei rifiuti. Senza swap, un picco transitorio interrompe il processo. Ho visto una box da 4 GB andare in OOM durante un normale deploy perché qualcuno aveva disabilitato lo swap pensando fosse un anacronismo dell’era Docker.
Larghezza di Banda: La maggior parte dei piani VPS moderni include da 1 a 4 TB di larghezza di banda mensile, sufficiente per quasi tutto tranne che per l’hosting video. I piani VPS Auto-Gestiti includono larghezza di banda illimitata, una voce in meno nel foglio di calcolo della pianificazione della capacità.

Un VPS da 4 GB costa circa $15 al mese a prezzi di mercato. Ciò equivale a 50 centesimi al giorno, o circa un caffè all’aeroporto ogni due settimane. Rispetto al pagamento separato per i runtime delle app, Postgres gestito e Redis su un PaaS, l’economia cambia sorprendentemente velocemente.

Quale Versione di Node.js Dovresti Installare?

Installa Node.js 24 (nome in codice Krypton). È l’attuale versione LTS attiva, promossa nell’ottobre 2025 e supportata fino all’aprile 2028 secondo il calendario ufficiale delle versioni di Node.js.

Molti tutorial indirizzano ancora le persone a Node 22. Queste guide non sono state aggiornate. Se stai iniziando un nuovo deployment oggi, fissare l’immagine CI e il tuo VPS a Node 24.x.

Versione	Codice	Stato	Fine Supporto
Node.js 26.x	(nessuno)	Corrente	Passa a LTS alla fine del 2026
Node.js 24.x	Krypton	LTS Attivo	Aprile 2028
Node.js 22.x	Jod	LTS in Manutenzione	Aprile 2027
Node.js 20.x	Iron	Fine Vita \|	Ha raggiunto il Fine Vita il 30 Aprile 2026. Non usarlo.

Alcune regole generali:

Non utilizzare release correnti (non-LTS) in produzione: Node 26 esiste per testare la compatibilità futura e le nuove funzionalità di runtime, non per l’app su cui dipendono i tuoi ricavi.
Node 22 è l’opzione alternativa se una dipendenza critica non è ancora compatibile con Node 24: La maggior parte dell’ecosistema si è stabilizzata entro pochi mesi dalla promozione LTS.
Fissa la tua versione di Node ovunque: La tua immagine CI, Dockerfile, .nvmrc e VPS di produzione dovrebbero essere concordi. “Funziona sul mio computer” diventa costoso molto rapidamente quando i moduli nativi entrano in gioco.

🤔Stai Considerando Bun? È più veloce in alcuni carichi di lavoro ed è sinceramente impressionante, ma l’ecosistema è ancora più piccolo e l’esperienza in produzione è più breve rispetto a quella di Node. Per la maggior parte dei team, la routine vince.

NodeSource, che gestisce i repository apt e yum da cui molti team di produzione installano Node, evidenzia i miglioramenti nella linea 24.x, a partire da un motore V8 più recente. Node 24 ora include anche strumenti ormai maturi come il node integrato –watch e un esecutore di test nativo stabile (node: test), entrambi stabilizzatisi nelle linee 20–22 e portati avanti qui. Niente di ciò è appariscente. Rimuove solo un po’ di attrito operativo ogni mese.

Come Si Installa Node.js Su Un VPS?

Hai due percorsi di installazione realistici. Scegli in base a se il server esegue una app Node o diverse.

NodeSource Per Un Server App Singolo

Questo è il percorso di produzione più semplice. Un script di configurazione e un apt install ti permettono di ottenere l’attuale linea LTS di Node 24 come pacchetto di sistema, e gli aggiornamenti futuri di sicurezza avverranno tramite normali upgrade dei pacchetti.

Su Ubuntu o Debian:

curl -fsSL https://deb.nodesource.com/setup_24.x | bash -
apt install -y nodejs

Verifica l’installazione:

node -v
npm -v

Comandi del terminale che mostrano la versione 24.14.0 di Node.js e la versione 11.9.0 di npm installati su DreamHost.

Dovresti vedere una release di Node 24.x.

Le istruzioni per le distribuzioni della famiglia RHEL (yum/dnf) si trovano nel repository ufficiale delle distribuzioni NodeSource.

nvm per il Cambio di Versione per Progetto

nvm (Node Version Manager) installa Node nella tua directory home e permette a diversi progetti di eseguire diverse versioni di Node. Utile se ospiti più app sullo stesso server o non hai accesso sudo.

Esegui questo come utente dell’app, non come root:

curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.40.5/install.sh | bash

Ricarica la tua shell, poi installa Node 24:

nvm install 24
nvm use 24
nvm alias default 24

👉Una regola importante: Non usare sudo ‘npm install -g’ per le dipendenze delle applicazioni.

Le installazioni globali sono solitamente riservate agli strumenti CLI a livello di macchina come pm2, typescript o nodemon. Le dipendenze della tua app devono essere inserite nel package.json e dovrebbero essere installate dalla directory del progetto con npm ci.

NodeSource	nvm
Una versione di Node per server	Multiple versioni di Node per server
Installato su tutto il sistema, funziona con qualsiasi utente	Installato per utente
Aggiornamenti automatici con `‘apt’`	Gestito manualmente
Richiede `sudo`	Non richiede `sudo`

Se non sei sicuro, inizia con NodeSource. La maggior parte dei server di produzione monofunzione non necessita della commutazione della versione di Node per ogni progetto.

👉Utenti di VPS DreamHost Autogestiti: L’applicazione Node disponibile in fase di provisioning include Node 22 LTS — ancora supportato fino ad aprile 2027. Per utilizzare Node 24, segui i passaggi di NodeSource o nvm sopra indicati dopo il provisioning.

Devi Usare PM2 o systemd per Mantenere in Esecuzione la Tua App?

Entrambi funzionano. La risposta onesta è quella con cui il tuo team si trova più a suo agio. PM2 è il percorso amichevole per gli sviluppatori. systemd è il percorso nativo Unix. Entrambi risolvono gli stessi tre problemi: riavvio in caso di crash, avvio all’accensione e spegnimento grazioso su ‘SIGTERM’.

Se stai iniziando da zero, ecco come scegliere:

	PM2	systemd
Tempo di configurazione	3 minuti	10 minuti
Modalità cluster (multi-core)	Incorporata	Non incorporata (avviare N unità)
Rotazione dei log	Modulo: `‘pm2-logrotate’`	Incorporata tramite `‘journalctl’`
Ricarica senza interruzioni	`‘pm2 reload’`	Generalmente gestito manualmente con riavvii progressivi o più unità
Sovraccarico di memoria (demone)	Piccolo sovraccarico del demone	Nessuno (nessun demone extra)
Migliore per	Configurazioni singole, sviluppo JS veloce	Casse multiple per app, comfort del team operativo

Il rapido avvio di PM2 è proprio così, rapido:

npm install -g pm2
pm2 start app.js --name api
pm2 startup    # stampa il comando di avvio systemd da eseguire
pm2 save       # salva l'elenco dei processi correnti

PM2 diventa quindi l’unico interlocutore a cui ti rivolgi: ‘pm2 logs,’ ‘pm2 reload api,’ ‘pm2 monit.’

👉Da sapere anche: ‘pm2 startup’ scrive un’unità systemd, quindi la configurazione di PM2 effettivamente utilizza systemd sottostante.

Una unità systemd minima per la gestione diretta di Node in ‘/etc/systemd/system/api.service’:

[Unit] Descrizione=La Mia API Node Dopo=network.target

[Service] Type=simple User=app WorkingDirectory=/var/www/api ExecStart=/usr/bin/node server.js Restart=on-failure RestartSec=5 Environment=NODE_ENV=production StandardOutput=journal StandardError=journal

[Install] WantedBy=multi-user.target
Poi ‘systemctl enable --now api.’ I log si trovano in ‘journalctl -u api -f.’

Se stai già utilizzando PM2 e funziona, non migrare a systemd solo perché qualcuno su Hacker News lo ha detto. La memoria del daemon PM2 non è il motivo per cui dovresti migrare da esso.

Migra quando hai una vera ragione, come eseguire mezza dozzina di processi Node dove ogni megabyte conta, o spedire in un ambiente operativo dove ogni altro servizio è una unità systemd, e PM2 si distingue come l’elemento insolito.

Come Posizionare NGINX (o Caddy) Davanti alla Tua App Node?

NGINX funge da proxy inverso tra le richieste del client e il backend dell'app Node.js.

Vuoi un reverse proxy davanti a Node per cinque motivi: terminazione HTTPS, compressione gzip/brotli, erogazione di risorse statiche, esecuzione di più app sulla stessa macchina e limitazione del tasso più semplice. Node può fare tutto questo. NGINX e Caddy lo fanno meglio e non interrompono il tuo ciclo di eventi quando qualcosa si comporta male.

Scegli NGINX se qualcuno nel tuo team lo conosce già. Scegli Caddy se vuoi HTTPS in tre righe di configurazione e sei a posto con un ecosistema di configurazione avanzata più ridotto.

Configurazione Minima NGINX

Inserisci questo blocco proxy in /etc/nginx/sites-available/api, crea un link simbolico a sites-enabled, poi nginx -t && systemctl reload nginx.

server {
    listen 80;
    server_name api.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-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_cache_bypass $http_upgrade;
    }
}

Le intestazioni ‘Upgrade’ e ‘Connection’ sono le linee di supporto WebSocket. I documenti stessi di NGINX indicano che Upgrade è un’intestazione hop-by-hop, quindi necessita di una gestione esplicita quando si inoltra il traffico WebSocket.

Lasciali abilitati se la tua app utilizza WebSockets ora, o potrebbe farlo in futuro. Socket.IO, sottoscrizioni GraphQL tramite WebSockets e un sorprendente numero di funzionalità “regolari” in tempo reale dipendono da quel handshake di aggiornamento.

Il bug di produzione più comune che vedo nelle configurazioni Node è un server Socket.IO dietro NGINX senza quelle due righe. Le connessioni falliscono in modo intermittente, gli sviluppatori incolpano Socket.IO, e il problema effettivo è di solito nella configurazione del proxy.

Caddyfile Minimo

La versione quickstart del reverse proxy di Caddy dello stesso argomento:

api.example.com {
    reverse_proxy 127.0.0.1:3000
}

Questo è l’intero file. Fintanto che il dominio punta al server e le porte 80/443 sono raggiungibili, Caddy provvede e rinnova HTTPS automaticamente. I documenti di Caddy dicono che le provviste automatiche di HTTPS rilasciano certificati TLS per i siti e li mantengono rinnovati; la guida rapida al proxy inverso segnala anche che HTTPS è automatico quando Caddy conosce il nome host.

Associa Nodo a localhost, Non a 0.0.0.0

Qualunque proxy tu scelga, configura la tua app Node per ascoltare su 127.0.0.1:3000, non su 0.0.0.0:3000. L’unica cosa che dovrebbe affrontare internet pubblico su una scatola Node è il proxy. Abbina questo con UFW, il comune frontend del firewall di Ubuntu, per negare tutto eccetto le porte 22, 80 e 443.

ufw default deny incoming
ufw allow 22/tcp
ufw allow 80/tcp
ufw allow 443/tcp
ufw enable

Se SSH è in esecuzione su una porta personalizzata, permetti quella porta prima di abilitare UFW.

Collegati a localhost fin dal primo giorno. La riunione in cui qualcuno ammette “l’app era esposta perché Node era collegato a 0.0.0.0” non è una riunione a cui vuoi partecipare.

Come Configuri HTTPS Per La Tua App Node.js?

Usa Let’s Encrypt. È gratuito, automatizzato e fidato da ogni browser. Ci sono due percorsi, a seconda del proxy che hai scelto.

NGINX + Certbot

Imposta un record A sul tuo IP VPS e attendi la propagazione del DNS.

Installa Certbot:

apt install certbot python3-certbot-nginx

Avvia:

certbot --nginx -d api.example.com

Certbot aggiorna la tua configurazione NGINX e ricarica il server automaticamente.

Sulle versioni moderne di Ubuntu, un timer systemd installato dal pacchetto Certbot gestisce automaticamente il rinnovo.

Apri https://api.example.com e conferma l’icona del lucchetto.

Anche la documentazione ufficiale di Certbot copre il percorso di installazione basato su snap se il pacchetto della tua distribuzione è obsoleto.

Caddy

Aggiungi il dominio al Caddyfile (l’esempio sopra già lo include), poi riavvia Caddy. Finché il dominio viene risolto correttamente e le porte 80/443 sono accessibili, il certificato viene fornito automaticamente al primo avvio. Non c’è Certbot.

Non terminare TLS in Node stesso per la produzione.

Il modulo https di Node funziona perfettamente, ma i reverse proxy come NGINX e Caddy sono progettati appositamente per la terminazione TLS. Offrono stapling OCSP, cifrature moderne di default, rinnovo automatico dei certificati, supporto HTTP/2 e — nel caso di Caddy — supporto HTTP/3 già configurato.

Potresti gestire tutto direttamente in Node? Certo. Staresti semplicemente ricostruendo un’infrastruttura che il tuo proxy già risolve molto bene.

Come Appare Effettivamente Una Configurazione Node.js Pronta Per La Produzione?

Otto cose mordono le persone in produzione. La maggior parte di esse non sono presenti nei tutorial di installazione perché non rientrano nell’arco “installa Node, esegui app”. Sono la differenza tra un’app che sopravvive al secondo mese e una che non lo fa.

NODE_ENV=production: Lo step più spesso dimenticato. In molti Framework e librerie Node, disabilita comportamenti esclusivi dello sviluppo e abilita le ottimizzazioni di produzione. Express, ad esempio, memorizza nella cache i template di vista compilati e restituisce errori più concisi in produzione — la propria documentazione cita un miglioramento delle prestazioni fino a 3 volte. Imposta la ‘env var’ ovunque.
Graceful shutdown: Quando il tuo VPS si riavvia o PM2 invia ‘SIGTERM’, la tua app ha qualche secondo per gestire le richieste in corso, chiudere le connessioni al database e uscire pulitamente. Configura un gestore ‘process.on(‘SIGTERM’, …)’. Il tempo di spegnimento predefinito di PM2 dipende dalla configurazione e dall’ambiente, quindi non presupporre che avrai sempre molto tempo per pulire.
Log rotation: Il modulo ‘pm2-logrotate’ di PM2 gestisce questo per PM2. Il giornale di systemd lo gestisce per le unità systemd dirette. Senza rotazione, i tuoi log riempiono il disco in un quarto del tempo che ti aspetteresti.
.env discipline: Non commettere mai segreti, non registrarli mai. Usa ‘dotenv’ per lo sviluppo locale. In produzione, imposta le variabili d’ambiente tramite ‘Environment=’ della tua unità systemd o il tuo file ecosistema PM2. Il giorno in cui fai ‘console.log(process.env)’ per errore è il giorno in cui devi ruotare ogni credenziale.
Un reverse proxy davanti a Node: Collega Node a localhost; lascia che NGINX o Caddy si confrontino con internet pubblico.
Un firewall: UFW nega tutto tranne 22, 80, 443. Spostare SSH dalla porta 22 non fermerà un attaccante determinato, ma riduce drasticamente il rumore di tentativi di forza bruta automatizzati e i log di autenticazione inutili.
Monitoring: Un endpoint di controllo sanitario che il tuo strumento di monitoraggio verifica ogni minuto. PM2 ha funzionalità di base integrate. Per questioni serie, utilizza Prometheus e Grafana, oppure un servizio di monitoraggio dell’uptime ospitato come Better Stack o UptimeRobot. Vuoi sapere che la tua app non funziona prima che un cliente te lo dica.

Stima manutenzione per lo stack sopra: da una a tre ore al mese.

Aggiornamenti Apt, aggiornamenti occasionali delle dipendenze e un controllo trimestrale del volume dei log. Questo è lo scambio per i vantaggi di costo e controllo.

Quando Un VPS È La Scelta Sbagliata Per Node.js?

Un VPS è la scelta sbagliata quando il tuo carico di lavoro è pensato per qualcos’altro. Sii onesto su quale lato ti trovi prima di effettuare la configurazione.

Siti Statici e Contenuti SSG: Esportazione Next.js, Astro, Gatsby e un blog Eleventy. Piattaforme come Vercel, Netlify o Cloudflare Pages offrono hosting statico globalmente memorizzato nella cache, deploy basati su Git e ricostruzioni automatiche inclusi. Un VPS di solito è un’infrastruttura non necessaria per contenuti puramente statici.
Carichi di lavoro guidati da eventi sparsi: Cloudflare Workers e AWS Lambda sono economici per i webhook eseguiti dieci volte al giorno.
App in tempo reale che necessitano di oltre 100.000 connessioni contemporanee: Un VPS non scala orizzontalmente. Avrai bisogno di orchestrazione (Kubernetes, ECS, Nomad) o di una piattaforma gestita per il tempo reale come Ably o Pusher.
Carichi di lavoro regolati e con elevati requisiti di conformità: HIPAA, PCI-DSS Livello 1, FedRAMP. Una PaaS gestita con certificazioni di conformità integrate allevia il dolore delle revisioni. Auto-ospitare la conformità su un VPS è un progetto di più trimestri che probabilmente non vuoi.
Nessuna dimestichezza con Linux — e nessuna voglia di acquisirla: Piattaforme come Render, Railway e DigitalOcean App Platform si collocano tra l’hosting VPS grezzo e una PaaS completamente gestita. Strumenti come Dokploy aggiungono flussi di lavoro di deployment in stile Heroku sulla tua infrastruttura VPS. Ottieni comunque molti dei vantaggi in termini di costo e controllo senza la necessità di familiarizzare profondamente con iptables, gli interni di systemd o il debugging del reverse-proxy all’1 di notte.

Non c’è nulla di sbagliato in nessuna di quelle risposte. La migliore decisione tecnica è quella che si adatta al tuo carico di lavoro.

Scegliere Il Tuo Stack Node E Trasferirsi

Apri quella fattura di hosting un’altra volta.

Stai per sostituire una quantità sorprendente di esso con un unico conto VPS.

👉Lo stack: Ubuntu 24.04 LTS, Node 24, PM2 (o systemd), NGINX (o Caddy), Let’s Encrypt tramite Certbot (o integrato in Caddy).

Avvia il piano VPS più piccolo che soddisfi la RAM necessaria, installa Node, esegui la tua app su ‘127.0.0.1,’ indirizza NGINX verso di essa e cambia i tuoi DNS.

Se l’app supera un deploy, un riavvio e una sessione notturna senza problemi, hai quasi raggiunto il tuo obiettivo.

Il resto è manutenzione. Un’ora o due al mese, la sporadica finestra di ‘apt upgrade’, un aggiornamento delle dipendenze trimestrale. Questo è l’accordo che hai fatto quando hai scambiato una fattura per postazione con una forfettaria, e il Self-Managed VPS Stack 4 di DreamHost è il punto da cui puoi partire.

VPS

Possiedi l’intero stack. App, IA, database e altro ancora.

Mantieni ogni credenziale e conversazione su un server che controlli tu, con velocità NVMe e banda illimitata integrate.

Esplora i piani di hosting VPS

Domande Frequenti Sull’Uso di Node.js su un VPS

Posso eseguire Node.js su qualsiasi VPS?

La maggior parte dei piani VPS moderni eseguono Node.js senza problemi. I piani VPS basati su KVM con una distribuzione Linux a 64 bit sono la scelta predefinita più sicura per le versioni attuali di Node.js.

I piani più vecchi basati su OpenVZ a volte hanno restrizioni del kernel che interrompono le versioni più recenti di Node. Se stai scegliendo tra provider, chiedi se sono basati su KVM.

Quanta RAM è necessaria per Node.js su un VPS?

Un server Express minimo rimane inattivo ben al di sotto dei 100 MB, ma un’applicazione di produzione realistica con middleware, registrazione e un pool di connessioni funziona tipicamente nel range di 150-300 MB.

Il minimo realistico per un’app di produzione è di 2 GB; il punto ideale per uno stack Node + Postgres + Redis è di 4 GB. L’Hosting VPS Autogestito di DreamHost Stack 4 (4 GB) gestisce la maggior parte dei carichi di lavoro di produzione di Node. Passa allo Stack 8 (8 GB) per app con SSR intensivo o in tempo reale.

Qual è la versione LTS corrente di Node.js?

L’attuale LTS attivo è Node.js 24.x (“Krypton”), promosso il 28 ottobre 2025 e supportato fino ad aprile 2028. Node.js 22.x (“Jod”) è in LTS di manutenzione fino ad aprile 2027 se una dipendenza impone la retrocompatibilità. Node.js 26 è stato lanciato il 5 maggio 2026, come Corrente e sarà promosso a LTS nell’ottobre 2026.

La maggior parte dei team di produzione si attiene alle versioni LTS a meno che non abbiano specificamente bisogno di funzionalità di runtime più recenti.

Ho bisogno di PM2 se ho systemd?

No, non hai bisogno di entrambi. PM2 e systemd risolvono lo stesso problema: mantenere la tua app Node in esecuzione in caso di crash e riavvii. Molti team focalizzati su Node scelgono PM2 per il clustering integrato, la gestione dei log e gli strumenti di ricarica.

I team che già utilizzano unità systemd per tutto il resto scelgono systemd.

Perché posizionare NGINX davanti a Node.js?

NGINX (o Caddy) davanti a Node.js centralizza la terminazione TLS, la compressione, la distribuzione di asset statici e il rate limiting in un software progettato specificamente per il proxying e il servizio web.

Ti permette anche di eseguire più app Node sullo stesso VPS senza conflitti di porte. In produzione, Node ascolta su localhost; NGINX si affaccia su internet pubblico.

Node.js su un VPS è più economico di Heroku o Vercel?

Sì, spesso. Un VPS da 4 GB si colloca comunemente in una fascia di prezzo di $15-$25 al mese a tariffe di mercato e può consolidare i costi di runtime dell’app, del database e della cache che sono fatturati separatamente su molte piattaforme PaaS.

Il prezzo di Vercel Pro è basato su ogni utente, e le piattaforme serverless impongono ancora limiti sulla durata dell’esecuzione a seconda del runtime e del piano.

Il compromesso è che ti occupi tu stesso delle operazioni, circa da una a tre ore al mese.

Posso eseguire più app Node su un unico VPS?

Sì, ed è la ragione più comune per cui i team passano da PaaS a un VPS. Esegui ogni app sulla sua porta interna (3000, 3001, 3002) e indirizza il traffico con i blocchi server di NGINX per Nome host. PM2 gestisce tutti come processi separati; systemd utilizza un file unità per app.

Un VPS da 4 GB può spesso gestire diversi servizi Node leggeri insieme a un piccolo carico di lavoro del database.

Posso eseguire Node.js su DreamHost Hosting Condiviso?

No. Node.js richiede processi persistenti, installazioni di pacchetti a livello di root e associazione diretta delle porte, nessuna delle quali è fornita dall’hosting condiviso. I piani VPS Self-Managed di DreamHost (Stack 4 e superiori) sono adatti per i carichi di lavoro Node con pieno accesso root, storage NVMe e larghezza di banda illimitata.

Ti è piaciuto questo articolo?

Dallas Kashuba