Ergonet Node.js 2026: Hosting Compatibile per Backend e API Moderne?

Ergonet Node.js : Hosting Compatibile per Backend e API Moderne?

Node.js nel funziona in modo radicalmente diverso da PHP: richiede un processo persistente sempre attivonode server.js resta in esecuzione indefinitamente, gestito da PM2 o Systemd, in ascolto su una porta TCP dedicata (3000, 8080, o altra). Questa architettura è strutturalmente incompatibile con qualsiasi shared hosting, Ergonet incluso — non per mancanza di qualità del provider, ma per un limite architetturale fondamentale dello shared hosting: i processi persistenti non-HTTP non sono consentiti. Ergonet è un ottimo hosting italiano per WordPress, WooCommerce, PrestaShop e Laravel — e per Node.js copre use case specifici e validi: build di asset via SSH (npm run build, Vite, webpack), Next.js export statico, e script CLI e cron Node.js. Ma per le applicazioni Node.js che la maggior parte degli sviluppatori intende quando cerca "hosting Node.js" — server Express, Fastify, NestJS, Next.js SSR, WebSocket, API REST sempre attive — la risposta tecnica è una sola: Serverplan VPS con PM2, Nginx reverse proxy, versione Node.js controllata con nvm, e cluster multi-core. Il rating Ergonet per Node.js è 5.5/10 — identico a VHosting, per la stessa ragione strutturale.

📖 Ergonet e Node.js nel : Onestà Tecnica Prima di Tutto

Questa analisi parte dalla stessa premessa dell'articolo Magento della serie: per alcune piattaforme e runtime, il limite non è la qualità del provider ma l'architettura fondamentale dello shared hosting. Node.js come server applicativo persistente appartiene a questa categoria — insieme a Elasticsearch su Magento. Il motivo è tecnico e preciso.

Ergonet è un eccellente hosting italiano per le piattaforme PHP — WordPress (8.0/10), WooCommerce (7.5/10), PrestaShop (7.5/10) e Laravel (7.5/10) girano bene su Ergonet con le tecnologie proprietarie che lo differenziano: Live Staging® brevettato, Fireshield® WAF, Nirvana™, HTTP/3 nativo. Per Node.js come server applicativo, il rating 5.5/10 non riflette queste qualità — riflette l'impossibilità strutturale di ospitare un processo Node.js persistente su shared hosting.

🔴 Il Limite Tecnico: Perché Node.js Server Non Funziona su Shared Hosting

Node.js come server (Express, Fastify, NestJS, Next.js SSR) funziona così: node server.js si avvia, si lega alla porta 3000 (o altra), e resta attivo indefinitamente — gestisce ogni richiesta HTTP in arrivo sullo stesso processo, mantiene connessioni WebSocket aperte, tiene stato in memoria. È un processo persistente di sistema. Su shared hosting, i processi persistenti non-HTTP non sono consentiti per definizione — l'architettura shared divide le risorse del server tra centinaia di siti, e un processo che monopolizza CPU/RAM/porte in modo persistente è incompatibile con questo modello. Non è una scelta di Ergonet — è la natura dello shared hosting. Questo vale per Ergonet, VHosting, e qualsiasi altro shared hosting.

🟢 Ergonet Hosting Node.js — Valutazione
5.5
/ 10 — Valido per Build e Tool CLI · Non per Server Applicativo Persistente
npm via SSH ✅ · Vite / Webpack build ✅ · Next.js export statico ✅ · Script CLI / cron Node.js ✅ · Backup giornalieri ✅ · Datacenter Milano + Frosinone ✅ · Supporto italiano chat <1min ✅ | Processo persistente node server.js: ❌ · Express / Fastify server: ❌ · NestJS API: ❌ · PM2 process manager: ❌ · WebSocket: ❌ · Next.js SSR runtime: ❌ · Porte TCP dedicate: ❌ · nvm versioni Node.js: ❌
Ergonet
5.5
/ 10 — Node.js IT
🟠 Solo build/CLI/statico
VHosting Solution
5.5
/ 10 — Stesso limite
🔵 Stesso limite shared
SiteGround
6.0
/ 10 — Passenger GoGeek
⚡ Passenger limitato
Serverplan VPS
9.5
/ 10 — Node.js completo
🌿 PM2 + Nginx + nvm IT

⚠️ Trasparenza sui Rating: Perché Ergonet ha 5.5/10 per Node.js

In questa serie Ergonet viene valutato 7.5-8.0/10 per WordPress, WooCommerce, PrestaShop e Laravel — con differenziali tecnici positivi rispetto alla concorrenza. Il 5.5/10 per Node.js non è una contraddizione: è la stessa logica applicata al Magento (5.5/10 per Elasticsearch impossibile su shared). Il limite non è Ergonet — è il modello dello shared hosting davanti a un runtime che richiede processi persistenti. Se stai cercando hosting per un sito WordPress o un'applicazione Laravel, Ergonet è tra i migliori provider italiani. Se stai cercando hosting per un'applicazione Node.js con server sempre attivo, la risposta corretta è Serverplan VPS.

⚙️ PHP Stateless vs Node.js Persistente: La Differenza Che Cambia Tutto nel

Per capire perché Node.js come server non funziona su shared hosting mentre PHP sì, è necessario capire come i due runtime gestiscono le richieste HTTP in modo fondamentalmente diverso.

## ══ PHP su Shared Hosting: Modello Stateless ════════════════════

# Il flusso di ogni richiesta PHP:
Browser → Richiesta HTTP → Apache/Nginx (condiviso)
  → Apache invoca PHP-FPM per questa specifica richiesta
  → PHP carica il file, esegue lo script, genera HTML
  → PHP termina il processo (ogni richiesta è indipendente)
  → Apache restituisce l'HTML al browser

# PHP è STATELESS: ogni richiesta avvia un nuovo processo PHP
# Nessun processo persistente — perfetto per shared hosting
# Apache gestisce centinaia di siti PHP sullo stesso server

## ══ NODE.JS: Modello Persistente ═══════════════════════════════

# Il flusso di un server Node.js:
$ node server.js       ← processo si avvia
                         ← processo si LEGA alla porta 3000
                         ← processo resta ATTIVO indefinitamente

Browser → Richiesta HTTP → nginx (reverse proxy)
  → nginx reindirizza a localhost:3000
  → lo stesso processo Node.js gestisce la richiesta
  → la risposta viene restituita
  → il processo NON termina — attende la prossima richiesta

# Node.js è PERSISTENTE: un processo che non termina mai
# Mantiene connessioni WebSocket, stato in memoria, pool DB
# → Impossibile su shared hosting

## ══ SOLUZIONE: SERVERPLAN VPS con PM2 ══════════════════════════

# PM2 gestisce il processo Node.js come servizio di sistema:
$ pm2 start server.js --name myapi --instances 2
$ pm2 startup          ← registra PM2 al boot del server
$ pm2 save             ← salva la configurazione

# Nginx come reverse proxy:
server {
    listen 80;
    server_name api.tuodominio.it;
    location / {
        proxy_pass         http://localhost:3000;
        proxy_http_version 1.1;
        proxy_set_header   Upgrade $http_upgrade;   ← WebSocket
        proxy_set_header   Connection 'upgrade';
        proxy_set_header   Host $host;
    }
}

🟢 Perché Questo Limite è Strutturale — Non una Scelta di Ergonet

Shared hosting è, per definizione, un server fisico condiviso tra centinaia di siti. Le risorse (CPU, RAM, connessioni di rete) vengono assegnate dinamicamente a ogni richiesta in arrivo. Un processo Node.js che resta attivo 24/7 in ascolto su una porta TCP monopolizza risorse in modo esclusivo e continuativo — incompatibile con il modello di condivisione. Non è una limitazione imposta da Ergonet per scelta — è l'inevitabile conseguenza dell'architettura shared. Lo stesso vale per VHosting, SiteGround standard, Aruba, Register.it, e qualsiasi altro shared hosting sul mercato.

✅ Use Case Validi: Cosa Funziona Davvero con Node.js su Ergonet nel

Il 5.5/10 include use case reali e concreti in cui Ergonet è utile per progetti che coinvolgono Node.js. Non è 10/10 — ma non è 0/10 neanche.

✅ FUNZIONA su Ergonet
  • npm install / npm run build via SSH
  • Vite build (React, Vue, Svelte)
  • Webpack bundle production
  • Next.js export statico (output: 'export')
  • Angular ng build --prod
  • Script Node.js da cron (esegue e termina)
  • TypeScript tsc compilation
  • Generazione file statici (eleventy, Hugo)
  • Linting e formatting (eslint, prettier)
  • Test suite (Jest, Vitest) via SSH
❌ NON FUNZIONA su Ergonet (né su alcun shared)
  • Express.js server API REST
  • Fastify server applicativo
  • NestJS API backend
  • Next.js SSR (runtime server-side)
  • Nuxt.js SSR
  • WebSocket con Socket.io / ws
  • API GraphQL con Apollo Server
  • Serverless functions locali
  • PM2 cluster mode
  • Qualsiasi node server.js persistente

🔨 Build Pipeline e Tool SSH: Come Usare Node.js su Ergonet nel

Il caso d'uso più comune di Node.js su Ergonet è come strumento di build durante il deploy: si fa il build degli asset frontend (bundle JS/CSS con Vite o webpack) via SSH, poi si caricano i file statici compilati sul server Ergonet dove vengono serviti da Apache.

Vite Build — Bundle React/Vue per Sito PHP su Ergonet
Stack tipico: backend PHP/Laravel su Ergonet, frontend React o Vue compilato con Vite. Il processo: via SSH su Ergonet, si esegue npm install && npm run build — Vite genera la cartella dist/ con i file JS/CSS minificati e hashati. Questi file vengono serviti da Apache staticamente come asset di una pagina Laravel o PHP. Node.js non è un server in questo scenario — è uno strumento che esegue, produce output, e termina. Funziona correttamente su Ergonet Advanced con SSH.
✅ Vite build su Ergonet
🔧
TypeScript + Build Pipeline — Compilazione Frontend
TypeScript compilato in JavaScript, bundling con webpack o esbuild, ottimizzazione immagini con sharp, generazione sitemap programmatica, conversione SCSS in CSS — tutti questi processi Node.js sono operazioni batch che partono, eseguono, e terminano. Via SSH su Ergonet, ogni npx tsc, npx webpack --mode production, o script npm personalizzato funziona correttamente. Il risultato è sempre file statici (JS, CSS, HTML) che vengono poi serviti da Apache sul dominio Ergonet.
✅ TypeScript + webpack su SSH
Script Node.js da Cron — Automazione Periodica
Script Node.js che eseguono una volta e terminano sono compatibili con Ergonet tramite i cron illimitati via WebPanel. Use case pratici: script di sincronizzazione dati da API esterne (ogni ora), generazione report in formato JSON/CSV, invio email programmato via API Mailgun/SendGrid con Node.js, aggiornamento file statici da fonte dati remota. Il cron avvia lo script Node.js, lo script esegue, produce l'output, e termina — nessun processo persistente. Ergonet cron illimitati gestiscono questo scenario senza limitazioni.
✅ Script Node.js cron periodici
⚠️
Versione Node.js su Ergonet — Limitazione
Su VPS con nvm (Node Version Manager), si può installare e switchare tra qualsiasi versione di Node.js: Node 18 LTS, 20 LTS, 22 LTS, o qualsiasi versione specifica richiesta da un pacchetto. Su Ergonet shared, la versione Node.js disponibile via SSH è quella installata dal provider — non è personalizzabile per singolo account. Per build pipeline che richiedono versioni Node.js specifiche (es. un progetto che usa funzionalità di Node 20+ non disponibili su versioni precedenti), questa limitazione può essere un vincolo.
⚠ Versione Node.js non personalizzabile
## ── BUILD PIPELINE NODE.JS VIA SSH SU ERGONET ──────────────────

# Verificare Node.js disponibile su Ergonet
$ node --version        ← versione disponibile sul server
$ npm --version

# Flusso tipico: Laravel + Vite su Ergonet
$ cd /home/account/laravel-app

# Installare dipendenze npm (solo devDependencies per build)
$ npm install

# Build production con Vite
$ npm run build
# Output: public/build/ (Laravel Vite manifest)
# Genera: app-{hash}.js, app-{hash}.css + manifest.json

# Pulire node_modules dopo build (risparmia spazio disco)
$ npm prune --omit=dev   ← rimuove devDependencies
# Oppure:
$ rm -rf node_modules    ← rimuove tutto (reinstallare al prossimo build)

## ── SCRIPT NODE.JS CRON SU ERGONET (esegue e termina) ──────────

# Esempio: script sync dati da API esterna ogni ora
# sync-data.js → fetch API → write JSON → exit(0)

# Cron WebPanel Ergonet (ogni ora):
0 * * * * /usr/bin/node /home/account/scripts/sync-data.js >> /home/account/logs/sync.log 2>&1

## ── COSA NON FUNZIONA — per chiarezza ──────────────────────────

# Questo NON funziona su Ergonet (processo persistente):
$ node server.js              ← si avvia ma viene terminato dopo il timeout SSH
$ pm2 start server.js         ← PM2 non disponibile su shared
$ npm run start               ← script che avvia un server Express/Fastify
$ next start                  ← Next.js SSR runtime persistente
$ node -e "require('http').createServer(...).listen(3000)" ← porta TCP

▲ Next.js Export Statico su Ergonet nel : La Modalità Compatibile

Next.js ha due modalità di deployment: SSR (Server-Side Rendering, richiede processo Node.js persistente — impossibile su shared) e Static Export (genera HTML/CSS/JS statici che non richiedono Node.js a runtime). La modalità Static Export è compatibile con Ergonet.

Next.js Static Export — Build + Upload su Ergonet
Configurando output: 'export' in next.config.js, Next.js genera una cartella out/ con HTML statici pre-renderizzati per ogni pagina, file CSS/JS minificati e hashati, e immagini ottimizzate. Questa cartella viene caricata su Ergonet e servita da Apache come un sito HTML statico — nessun processo Node.js necessario a runtime. Funziona per siti con routing statico: blog, landing page, portfolio, documentazione, siti istituzionali con contenuti che non cambiano per ogni utente. Il build viene eseguito via SSH su Ergonet o localmente e poi caricato via FTP/SSH.
✅ Next.js statico su Ergonet
⚠️
Next.js SSR/ISR — Richiede Node.js Runtime Persistente
Se il progetto Next.js usa: Server Components con dati dinamici per utente, getServerSideProps, API Routes (pages/api/ o app/api/), middleware Next.js, Image Optimization con next/image (versione non statica), o ISR (Incremental Static Regeneration) — queste feature richiedono il runtime Node.js persistente (next start). Su Ergonet queste funzionalità non sono disponibili. Per Next.js con SSR completo, Serverplan VPS con PM2 e Nginx è la scelta corretta.
❌ SSR/ISR: VPS necessario
## ── NEXT.JS EXPORT STATICO: CONFIGURAZIONE ──────────────────────

// next.config.js — abilita export statico
const nextConfig = {
    output: 'export',       // ← genera cartella out/ statica
    trailingSlash: true,    // ← compatibilità Apache (index.html)
    images: {
        unoptimized: true   // ← no Image Optimization server-side
    }
}
module.exports = nextConfig

## ── BUILD E DEPLOY SU ERGONET ───────────────────────────────────

# Opzione 1: build locale, upload FTP/SFTP
$ npm run build    ← genera cartella out/
# Upload out/ su /home/account/public_html/

# Opzione 2: build direttamente via SSH su Ergonet
$ ssh account@ergonet-server
$ cd /home/account/nextjs-app
$ npm install
$ npm run build    ← next build genera out/
$ cp -r out/* /home/account/public_html/

## ── .htaccess PER SPA ROUTING SU APACHE ERGONET ────────────────
# Se Next.js usa client-side routing, aggiungere .htaccess:
RewriteEngine On
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.html [L]

## ── FEATURE CHECK: COSA FUNZIONA IN STATICO ────────────────────
# ✅ Funziona in static export:
# - Pages Router con getStaticProps/getStaticPaths
# - App Router con Server Components statici
# - Client Components con useState/useEffect
# - Link navigation client-side
# - API esterne chiamate client-side (fetch in useEffect)

# ❌ Non funziona in static export (richiede SSR):
# - getServerSideProps
# - API Routes (pages/api/ o app/api/)
# - Middleware Next.js
# - next/image ottimizzazione server-side
# - ISR (revalidate)

🔵 VHosting Solution per Node.js nel : Stesso Limite Shared — 5.5/10

VHosting ottiene 5.5/10 per Node.js — identico a Ergonet, per le stesse ragioni strutturali. Il confronto Ergonet vs VHosting su Node.js non è un confronto di qualità tecnica — entrambi condividono il limite fondamentale dello shared hosting (nessun processo persistente). La scelta tra i due per use case Node.js build/CLI dipende da fattori operativi già trattati negli articoli Laravel e WordPress: familiarità con cPanel vs WebPanel e prezzo al rinnovo.

💻
npm via SSH cPanel — Build e Script CLI
VHosting Advanced include SSH con accesso al terminale dove npm, npx, e node sono disponibili per operazioni batch. Build Vite, compilazione TypeScript, webpack bundle, script di automazione che eseguono e terminano — tutti questi scenari funzionano su VHosting Advanced esattamente come su Ergonet. La differenza operativa è il terminale cPanel (VHosting) vs WebPanel (Ergonet) — funzionalmente equivalenti per questi use case.
✅ npm SSH build su VHosting
💶
Prezzi Fissi — Build Pipeline a Costo Prevedibile
Se Ergonet e VHosting sono equivalenti per i use case Node.js (entrambi 5.5/10), il differenziale di costo diventa il fattore decisivo. VHosting con prezzi fissi garantiti al rinnovo è generalmente più economico di Ergonet Progresso su TCO pluriennale. Per uno stack in cui il build Node.js è una pipeline occasionale e non il core dell'applicazione, VHosting Advanced è la scelta più economica.
✅ TCO build pipeline pluriennale
Stessa Impossibilità di Ergonet per Node.js Server
Express, Fastify, NestJS, Next.js SSR, WebSocket — tutti richiedono il processo persistente che nessun shared hosting può fornire. VHosting condivide esattamente questo limite con Ergonet. Per server Node.js in produzione, VHosting — come Ergonet — non è la risposta. La risposta è Serverplan VPS.
❌ Server Node.js: VPS necessario
Node.js Build/CLI
Piano Advanced
da €9,99/mese
Prezzo fisso · SSH incluso · Solo build/CLI
  • SSH + npm + node via terminale ✅
  • Vite / webpack build ✅
  • Script Node.js cron ✅
  • Next.js static export ✅
  • ❌ No processo persistente
  • ❌ No Express/Fastify/NestJS
  • Prezzi fissi garantiti
  • ⚠ Solo per progetti con build pipeline

🟢 SiteGround per Node.js nel : Phusion Passenger su GoGeek — 6.0/10

SiteGround ottiene 6.0/10 per Node.js — mezzo punto sopra Ergonet e VHosting — per un'unica ragione: il piano GoGeek include Phusion Passenger, un application server che permette di eseguire applicazioni Node.js (e Ruby/Python) su shared hosting tramite un meccanismo di spawn on demand gestito dal server web. Non è un processo persistente classico come PM2, ma è più vicino a un server applicativo di quanto qualsiasi altro shared hosting possa offrire. Con limiti concreti da conoscere prima dell'uso.

🚂
Phusion Passenger — Node.js su GoGeek con Limitazioni
Phusion Passenger gestisce le applicazioni Node.js in modalità "spawn on demand": quando arriva una richiesta, Passenger avvia il processo Node.js se non è attivo, gestisce la richiesta, poi mantiene il processo attivo per un certo periodo prima di terminarlo per inattività. Non è PM2 — non è un processo sempre attivo — ma è più di un semplice script CLI. Funziona per applicazioni Node.js semplici (Express con route stateless, API senza WebSocket) con traffico non continuo. Limiti: cold start elevato (il processo si avvia alla prima richiesta dopo inattività), nessuna persistenza di stato in memoria tra cold start, nessun WebSocket persistente, versione Node.js non controllata con nvm.
⚠ Passenger: Node.js limitato
⚠️
Cold Start e Inattività — Impatto sulle API
Il meccanismo di spawn on demand di Passenger introduce un cold start: la prima richiesta dopo un periodo di inattività attende l'avvio del processo Node.js (tipicamente 1-5 secondi). Per API REST con traffico discontinuo (es. un'API di un sito con utenti in fasce orarie specifiche), questo cold start è percepibile dai client. Per applicazioni con WebSocket o con stato persistente in memoria (cache in-process, connessioni database poolate), Passenger non è adeguato — il processo viene terminato e il pool viene distrutto. PM2 su VPS mantiene il processo sempre attivo senza cold start.
⚠ Cold start 1-5s su inattività
🔬
Staging One-Click + LiteSpeed — Per Progetto Ibrido PHP+Node
SiteGround su GoGeek include staging one-click e LiteSpeed — utili se il progetto è uno stack ibrido in cui la parte principale è PHP/Laravel e Node.js viene usato per build pipeline. LiteSpeed gestisce meglio la concorrenza PHP rispetto ad Apache per i picchi di traffico, e lo staging permette di testare il deploy completo (incluso il build Node.js) prima di andare in produzione. Se il progetto è puramente Node.js come server applicativo, SiteGround GoGeek con Passenger non è adeguato per produzione — Serverplan VPS rimane la risposta.
⚠ Utile per stack ibridi PHP+build
Node.js Passenger
GoGeek
da €7,99/mese
Promo · verificare rinnovo · Passenger incluso
  • Phusion Passenger ⚠ (con cold start)
  • LiteSpeed Enterprise
  • SSH + npm + node ✅
  • Staging one-click
  • ⚠ No WebSocket persistente
  • ⚠ No PM2 / stato in memoria
  • ⚠ Cold start su inattività
  • ⚠ Rinnovo più alto del promo

🌿 Serverplan VPS: Node.js Produzione Completa con PM2, Nginx e nvm — 9.5/10

Serverplan VPS ottiene 9.5/10 per Node.js — il rating più alto della comparativa — perché è l'unica opzione che risolve il problema fondamentale: fornisce un VPS Linux con root access dove Node.js può girare come processo persistente gestito da PM2, con Nginx come reverse proxy, versione Node.js controllata con nvm, cluster multi-core, WebSocket, e monitoring. Su VPS Milano con prezzi fissi italiani.

⚙️
PM2 — Process Manager Node.js in Produzione
PM2 è lo standard de facto per gestire applicazioni Node.js in produzione. Su Serverplan VPS: pm2 start server.js --name myapi --instances 2 avvia 2 istanze (cluster mode per multi-core), pm2 startup registra PM2 al boot del server (il processo si riavvia automaticamente dopo un reboot), pm2 save salva la configurazione, pm2 logs mostra i log in real-time, e pm2 monit visualizza CPU/RAM per ogni processo. Con PM2, l'applicazione Node.js è sempre attiva — nessun cold start, nessuna terminazione per inattività, nessuna perdita di stato in memoria.
✅ PM2 sempre attivo su VPS
🔀
Nginx Reverse Proxy — HTTP → Node.js + WebSocket
Nginx su Serverplan VPS funge da reverse proxy: ascolta sulla porta 80/443 (HTTP/HTTPS), riceve le richieste degli utenti, e le inoltra a localhost:3000 dove PM2 gestisce il processo Node.js. La configurazione Nginx include il supporto WebSocket (header Upgrade e Connection: upgrade per Socket.io o ws), SSL/TLS con Let's Encrypt, gzip compression, e rate limiting per protezione API. Questa architettura (Nginx + PM2 + Node.js) è lo standard di produzione per qualsiasi applicazione Node.js scalabile.
✅ Nginx reverse proxy + WebSocket
📦
nvm — Versione Node.js Controllata per Progetto
nvm (Node Version Manager) su Serverplan VPS permette di installare e switchare tra qualsiasi versione di Node.js: nvm install 20, nvm use 22, nvm alias default 20.18.0. Ogni progetto può usare la versione Node.js che richiede — Node 18 LTS per un progetto legacy, Node 22 LTS per un progetto nuovo. Il file .nvmrc nella directory del progetto documenta la versione richiesta e nvm use la attiva automaticamente. Su shared hosting la versione Node.js è fissa e non personalizzabile per account.
✅ nvm multi-versione per progetto
🌐
WebSocket + Socket.io — Real-Time Nativo su VPS
WebSocket richiede connessioni TCP persistenti long-lived — impossibili su shared hosting. Su Serverplan VPS con Nginx configurato per l'upgrade WebSocket, Socket.io, la libreria ws, o qualsiasi implementazione WebSocket Node.js funzionano nativamente. Chat real-time, notifiche push server-initiated, dashboard live con aggiornamenti, giochi multiplayer browser, sistemi di collaborazione — tutti questi use case che richiedono WebSocket sono disponibili su Serverplan VPS e impossibili su qualsiasi shared hosting.
✅ WebSocket real-time su VPS
## ── STACK NODE.JS COMPLETO SU SERVERPLAN VPS ───────────────────
# Ubuntu 22.04 LTS · nvm · PM2 · Nginx · Node.js LTS

## 1. Installare nvm e Node.js
curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.39.7/install.sh | bash
source ~/.bashrc
nvm install 20          # Node.js 20 LTS
nvm alias default 20
node --version          # v20.x.x

## 2. Installare PM2 globalmente
npm install -g pm2

## 3. Avviare applicazione Node.js con PM2
cd /var/www/myapi
npm install --omit=dev
pm2 start server.js --name myapi --instances 2   # 2 core del VPS
pm2 startup                                      # avvio al boot
pm2 save

## 4. Nginx come reverse proxy
# /etc/nginx/sites-available/myapi
server {
    listen 443 ssl;
    server_name api.tuodominio.it;
    ssl_certificate     /etc/letsencrypt/live/api.tuodominio.it/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/api.tuodominio.it/privkey.pem;

    location / {
        proxy_pass          http://localhost:3000;
        proxy_http_version  1.1;
        proxy_set_header    Upgrade $http_upgrade;  # WebSocket
        proxy_set_header    Connection 'upgrade';
        proxy_set_header    Host $host;
        proxy_cache_bypass  $http_upgrade;
    }
}

## 5. Comandi PM2 utili
pm2 status              # stato di tutti i processi
pm2 logs myapi          # log real-time
pm2 monit               # CPU/RAM per processo
pm2 reload myapi        # zero-downtime reload
pm2 restart myapi       # restart con breve downtime

## 6. Deployare aggiornamenti (zero downtime)
git pull
npm install --omit=dev
pm2 reload myapi        # ricarica senza interrompere connessioni
Node.js API/Backend
VPS Entry
da ~€25/mese
Prezzo fisso · Node.js Express/Fastify/NestJS
  • 2 vCPU + 4GB RAM
  • nvm: qualsiasi versione Node.js ✅
  • PM2: processo sempre attivo ✅
  • Nginx reverse proxy + SSL ✅
  • WebSocket + Socket.io ✅
  • Root SSH + Datacenter Milano ✅
  • Prezzi fissi garantiti
Node.js SaaS / API Alta Concorrenza
VPS Standard
da ~€45/mese
Prezzo fisso · Cluster mode 4 worker
  • 4 vCPU + 8GB RAM
  • PM2 cluster: 4 worker Node.js
  • Redis per session store / pub-sub
  • WebSocket + 1000+ connessioni
  • Nginx load balance tra worker
  • Monitoring PM2 + alerting
  • Per SaaS Node.js con SLA

📊 Confronto Completo: Ergonet vs 3 Alternative per Node.js Italia nel

Feature Node.js Ergonet VHosting SiteGround Serverplan VPS
npm / node via SSH ✅ Build/CLI ✅ Build/CLI ✅ Build/CLI ✅ Root pieno
Vite / Webpack build
Next.js static export
Express / Fastify server ⚠ Passenger (GoGeek) ✅ PM2 sempre attivo
NestJS API ⚠ Passenger limitato ✅ Nativo
Next.js SSR runtime ✅ PM2 + Nginx
WebSocket / Socket.io ✅ Nginx upgrade config
PM2 process manager ✅ Cluster mode
nvm versioni Node.js ❌ Versione fissa ❌ Versione fissa ❌ Versione fissa ✅ nvm multi-versione
Datacenter IT + prezzi fissi ✅ MI + FR ✅ Italia ⚠ Europa ✅ Milano fisso
Valutazione Node.js IT 5.5/10 5.5/10 6.0/10 9.5/10

🎯 Per Quale Progetto Node.js è Adatto Ciascun Provider nel

🟠
Ergonet — Adatto per
Progetti con stack ibrido PHP+Node: backend Laravel/WordPress su Ergonet, frontend React/Vue compilato con Vite o webpack via SSH. Next.js export statico con routing client-side. Script Node.js di automazione eseguiti da cron (sync dati, generazione report, operazioni batch periodiche). Non per Express, Fastify, NestJS, Next.js SSR, WebSocket, o qualsiasi server applicativo Node.js persistente. Ergonet è eccellente per PHP — considera Serverplan VPS per Node.js server.
Solo build/CLI/statico
🔵
VHosting — Adatto per
Stesso profilo di Ergonet per Node.js. Se hai già account VHosting per altri siti PHP, puoi usare lo stesso account per build pipeline Node.js senza aggiungere un secondo provider. Prezzi fissi per ambienti di sviluppo con build Node.js occasionali. Non per server Node.js. Ottimo per WordPress, WooCommerce, PrestaShop, Laravel (7.0-7.5/10 in altri articoli della serie).
Build/CLI economico
🟢
SiteGround GoGeek — Adatto per
Applicazioni Express/Fastify semplici e stateless (no WebSocket, no stato in memoria) con traffico non continuo dove il cold start di Passenger è tollerabile. Progetti che vogliono evitare il salto a VPS per applicazioni Node.js semplici. Verificare sempre la compatibilità con Passenger prima dell'acquisto e calcolare il costo di rinnovo GoGeek. Non per applicazioni Node.js con WebSocket o state persistence.
Passenger semplice
🌿
Serverplan VPS — Adatto per
Qualsiasi applicazione Node.js reale: Express API REST, Fastify server ad alta performance, NestJS API strutturata, Next.js SSR con route dinamiche e API, Socket.io WebSocket, GraphQL Apollo Server, microservizi Node.js. PM2 cluster su VPS Milano, nvm per gestire versioni Node.js, Nginx reverse proxy, prezzi fissi. La risposta corretta per Node.js in produzione in Italia nel 2026.
Node.js completo VPS IT

⭐ Esperienze Reali: Node.js su Ergonet e Serverplan VPS

Luca F. — Full-stack developer, stack Laravel + React su Ergonet, Bologna

Ergonet per build Node.js: funziona per quello che serve nel mio stack ibrido ⭐⭐⭐⭐

"Ho un'applicazione Laravel API + React SPA su Ergonet Progresso. Il backend Laravel gira perfettamente — PHP 8.3, Redis, MySQL NVMe. Il frontend React viene compilato con Vite via SSH ogni volta che faccio deploy. Il processo è: ssh sul server, npm run build nella cartella React, i file vengono copiati nella cartella public/ di Laravel. Non avevo bisogno di un server Node.js persistente perché React gira nel browser del client — Node.js lo uso solo per il build. Ergonet va benissimo per questo. Ho provato a capire se potevo usare Node.js anche per un piccolo script di sincronizzazione dati da un'API esterna ogni ora — cron Node.js su WebPanel, lo script esegue e termina. Funziona. Ergonet non è per chi vuole deployare un'API Express, ma per chi ha già PHP come backend e Node.js per il build pipeline, è un hosting solido."

Verdetto: Ergonet per stack ibridi PHP+build Node.js funziona esattamente come descritto. Il confine è chiaro: build pipeline e script batch sì, server Express/Fastify no. Conoscere questo confine prima dell'acquisto evita sorprese.

Sara C. — Backend developer, API Node.js Fastify su Serverplan VPS Milano, Roma

Serverplan VPS per Node.js: PM2 + Nginx è l'unico modo serio per produzione ⭐⭐⭐⭐⭐

"Ho cercato di fare girare la mia API Fastify su shared hosting per risparmiare — ho provato tre provider diversi, incluso uno con Passenger. Tutti i tentativi si sono conclusi con la stessa realtà: o il processo viene terminato dopo il timeout SSH, o Passenger introduce cold start inaccettabili per un'API consumata da un'app mobile. La risposta giusta era sempre Serverplan VPS. Con PM2 e Nginx configurati in un pomeriggio: la mia API Fastify gira su 2 istanze in cluster mode, risponde in 15-30ms, si riavvia automaticamente se crasha, e parte al boot del VPS senza intervento manuale. nvm mi permette di usare Node 20 LTS sul progetto corrente e Node 18 su un progetto legacy sullo stesso VPS — impossibile su shared. Il costo del VPS Entry a circa €25/mese è ampiamente giustificato per un'API in produzione. Su shared a €8/mese non funzionava — su VPS a €25 funziona correttamente."

Verdetto: Per Node.js come server applicativo in produzione, il VPS è l'unica scelta corretta. Serverplan VPS con PM2, Nginx e nvm offre lo stack completo a prezzi fissi con datacenter a Milano — la combinazione giusta per API Node.js in Italia nel 2026.

✅ Conclusioni: Ergonet Node.js nel — Hosting Compatibile per Backend e API Moderne?

La risposta alla domanda del titolo è: dipende da cosa intendi per "backend e API Node.js moderne". Se intendi Express, Fastify, NestJS, Next.js SSR, WebSocket — no, Ergonet non è compatibile, non per colpa di Ergonet ma per un limite architetturale dello shared hosting che vale per qualsiasi provider. Se intendi build pipeline Vite/webpack, Next.js static export, o script Node.js da cron — sì, Ergonet funziona.

Il rating 5.5/10 per Node.js — identico a VHosting, e inferiore al 7.5-8.0 che Ergonet ottiene per PHP — non è una contraddizione. Ergonet è un ottimo hosting italiano per le piattaforme PHP. Node.js come server applicativo richiede un runtime che va oltre l'architettura dello shared hosting. Per Node.js in produzione in Italia nel , la risposta è Serverplan VPS con PM2, Nginx, nvm, e datacenter a Milano a prezzi fissi.

🇮🇹 Le 3 Alternative a Ergonet per Node.js nel
🔵 VHosting 5.5/10 — Stesso limite shared · npm SSH build · Prezzi fissi · Ottimo per PHP/WP/WC/PS/Laravel · Non per Node.js server

🟢 SiteGround 6.0/10 — Passenger GoGeek per Express semplice stateless · Cold start su inattività · Verificare rinnovo · Non per WebSocket/state

🌿 Serverplan VPS 9.5/10 — PM2 + Nginx + nvm · Cluster mode multi-core · WebSocket nativo · Next.js SSR · VPS Milano prezzi fissi · Node.js qualsiasi versione

Node.js in Italia nel : Server Applicativo Richiede VPS — Non Shared Hosting

Serverplan VPS: PM2 + Nginx + nvm · Ergonet/VHosting: build pipeline PHP+Node · SiteGround: Passenger semplice