
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 attivo — node 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.
⚠️ 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.
- 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
- 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.jspersistente
🔨 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.
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.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.## ── 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.
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.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.## ── 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, 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.- 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 ⚠ (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 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.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.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.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.## ── 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
- 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
- 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
⭐ Esperienze Reali: Node.js su Ergonet e Serverplan VPS
Luca F. — Full-stack developer, stack Laravel + React su Ergonet, Bologna
"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
"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.
🟢 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