Hosting Node.js i Next.js. Wypychasz kod, strona działa.

1. Node.js richiede una soluzione intermedia tra PaaS e un server bare metal

Per un'applicazione Node.js, la prima scelta naturale è spesso un modello come quello offerto dalle piattaforme PaaS (Platform as a Service): git push e l'applicazione è attiva, senza dover gestire il server. Il problema inizia con il conto: la maggior parte di queste piattaforme fattura in dollari, con prezzi che, in presenza di traffico reale in produzione, crescono rapidamente, mentre l'infrastruttura si trova fisicamente fuori dalla Polonia.

Su Saplo l'applicazione Node.js è già disponibile come starter (Express), con la possibilità di scegliere la versione di Node (18, 20 o 22, con 20 predefinita), e puoi sostituirne il codice con il tuo tramite git deploy: il push al repository aggiorna automaticamente l'applicazione in esecuzione, senza dover accedere manualmente al server dopo ogni modifica.

Il manifest dell'applicazione dichiara un requisito minimo di 512 MB di RAM e 3 GB di disco. Anche Box S (1 GB di RAM) può quindi ospitare tecnicamente un'applicazione Node semplice, ma per qualcosa di più di un prototipo conviene valutare Box M con accesso SSH completo.

2. Git deploy vs upload manuale

Con git deploy, il repository del codice è l'unica fonte di verità su ciò che è in produzione: il push a un ramo prestabilito attiva l'aggiornamento dell'applicazione su Box, senza caricare manualmente i file via FTP o copiarli via SSH dopo ogni modifica al codice.

Per un team di più persone che lavora alla stessa applicazione Node.js, la differenza è concreta: ogni commit che raggiunge il ramo corretto finisce subito sul server, consentendo iterazioni rapide senza ulteriori passaggi di deployment oltre al git push.

Da Box M, l'accesso SSH con sudo permette anche di gestire manualmente il processo Node, ad esempio riavviarlo dopo aver modificato le variabili d'ambiente o installare pacchetti di sistema aggiuntivi richiesti da alcune dipendenze npm, operazioni non sempre possibili con il solo git deploy.

3. Perché non scegliere un VPS classico

Su un VPS bare metal di Competitor A (1 vCPU, 2 GB RAM, 20 GB di disco per 11 €/mese netti, listino pubblico, stato al 2026-10-10), installare un'applicazione Node.js richiede l'installazione manuale di Node, di un process manager (ad es. PM2), di un reverse proxy e di un certificato SSL, prima che l'applicazione diventi accessibile al pubblico su un dominio con https.

In Saplo questi elementi (reverse proxy nginx, SSL e gestore dei processi nel container) vengono configurati automaticamente durante l'installazione dal catalogo. Dal momento in cui scegli la versione di Node all'applicazione in esecuzione e accessibile pubblicamente sul tuo dominio passano pochi minuti, non ore di configurazione manuale del server.

Costo comparabile a quello di un VPS con risorse simili, ma senza dover amministrare il sistema operativo e senza il rischio che un errore nella configurazione del firewall o negli aggiornamenti di sistema metta fuori uso l'applicazione per un problema non legato al codice Node.js.

4. Più applicazioni Node.js su un unico Box

Con Box non c'è un limite al numero di applicazioni: puoi eseguire contemporaneamente più progetti Node.js indipendenti (ad es. un'API, un pannello di amministrazione o un microservizio separato), ognuno in un proprio container LXC e con un dominio o sottodominio dedicato, senza conflitti di porte tra i progetti.

Per le applicazioni che usano un database sono disponibili moduli separati (Postgres, MySQL e Redis) avviati come container nel proprio compose, non come componenti aggiuntivi a pagamento. Per una configurazione tipica Node.js più database è una combinazione naturale, senza costi aggiuntivi per il database stesso. Aggiungere un database come nuova applicazione sullo stesso Box richiede lo stesso tempo che avviarlo dal catalogo, senza stipulare un contratto separato con un provider cloud esterno.

5. Per chi è adatto

Per uno sviluppatore che realizza un semplice backend API o un microservizio, Box M con SSH completo e deployment tramite git offre un ambiente di produzione pronto in poco tempo, senza configurare il server da zero.

Per uno startup che sviluppa contemporaneamente più servizi Node.js (API, pannello, worker), Box L permette di ospitarli tutti su un unico account, in container separati, senza fatture separate per ogni microservizio presso diversi provider PaaS.

Per chi migra da una piattaforma PaaS estera fatturata in dollari, Saplo offre un'esperienza di deployment simile (git push), ma con fatturazione in złoty e infrastruttura in un data center europeo.

6. Primo deployment di un'applicazione Node.js su Saplo

Dopo aver avviato lo starter Express con la versione di Node scelta (18, 20 o 22), collega il repository Git dal pannello, così ogni modifica successiva del codice verrà applicata automaticamente al server a ogni push verso il branch impostato.

Sostituisci il codice dello starter con la tua applicazione, mantenendo la porta prevista e le variabili d'ambiente richieste dal runtime Saplo, così il reverse proxy continua a instradare correttamente il traffico verso la tua applicazione sul dominio collegato.

Le variabili d'ambiente (chiavi API, stringa di connessione al database) le imposti nel pannello dell'applicazione, senza memorizzarle direttamente nel repository del codice. È una buona pratica di sicurezza, indipendentemente da dove è ospitata l'applicazione.

Se l'applicazione usa un database, aggiungi un modulo separato (Postgres, MySQL o Redis) sullo stesso Box e collegati tramite l'indirizzo interno, senza esporre il database pubblicamente su internet.

Monitora i log dell'applicazione tramite SSH (da Box M), così puoi individuare rapidamente gli errori dopo ogni deployment, prima che diventino evidenti agli utenti dell'applicazione in produzione.

7. Node.js in un'architettura a microservizi su un unico Box

Puoi distribuire più servizi Node.js indipendenti (API, worker che gestisce una coda, pannello di amministrazione) come applicazioni separate sullo stesso Box, ognuno in un container dedicato, che comunicano tramite la rete interna o API pubbliche.

Questa separazione semplifica il deployment indipendente di ogni servizio (un git push a un servizio non richiede il ridistribuire gli altri), risultando più comoda di un unico grande processo monolitico Node.js che gestisce tutto insieme, man mano che il progetto cresce.

Redis, come modulo separato sullo stesso Box, serve spesso come coda di task o cache tra microservizi, senza dover ricorrere a un servizio Redis esterno a pagamento al di fuori dell'infrastruttura Saplo.

Con un'architettura a microservizi, valuta Box L o superiore: più processi Node.js indipendenti, insieme al database e a Redis, occupano più memoria di una singola applicazione semplice.

8. Monitoraggio e log dell'applicazione Node.js in produzione

Un'applicazione Node.js in produzione prima o poi incontra un errore che non si era verificato durante i test locali. Per questo, l'accesso ai log del processo tramite SSH (da Box M) è uno strumento diagnostico essenziale, che permette di capire cosa è successo davvero quando si verifica un errore o un comportamento inatteso.

È buona pratica usare log strutturati (ad es. in formato JSON, con livello di gravità e timestamp) invece di semplici chiamate console.log sparse nel codice. Questo facilita poi il filtraggio per tipo di evento o livello di errore, soprattutto quando l'applicazione cresce e i log aumentano.

Il riavvio del processo dopo un arresto anomalo (ad es. un'eccezione non gestita che arresta Node.js) può essere configurato tramite il gestore dei processi in esecuzione nel container. In questo modo, un'interruzione breve non comporta un lungo periodo di indisponibilità prima che il team se ne accorga e intervenga manualmente.

Per le applicazioni con molte dipendenze npm, controlla periodicamente le vulnerabilità note nei pacchetti utilizzati con gli strumenti standard dell'audit npm, perché le dipendenze obsolete sono un vettore di attacco comune per le applicazioni Node.js, indipendentemente dalla qualità del codice.

Monitorare in tempo reale l'uso di RAM del processo Node.js aiuta a individuare perdite di memoria prima che portino al crash dell'intera applicazione, un rischio concreto nei processi a lungo termine (server WebSocket, connessioni persistenti). Controllare regolarmente l'andamento del consumo di memoria, anche senza strumenti avanzati di profilazione, permette di individuare per tempo un problema in crescita e pianificarne la correzione prima che causi un crash in produzione.

Il pannello Saplo mostra l'attuale utilizzo delle risorse del container ed è il primo punto di riferimento per diagnosticare i problemi di prestazioni, prima di dover ricorrere a strumenti di profilazione più avanzati per l'applicazione Node.js.

9. La community e l'ecosistema npm come criterio di scelta dello stack

Node.js ha uno dei più grandi ecosistemi di pacchetti (npm) tra i linguaggi e le piattaforme più diffusi. Questo significa che la maggior parte delle esigenze tipiche (autenticazione, connessione al database, gestione dei file) dispone di librerie pronte e collaudate, invece di dover scrivere quella logica da zero per ogni nuovo progetto.

Su Saplo questo ecosistema è completamente disponibile, perché l'applicazione gira in un ambiente Node.js standard con accesso al registro npm, senza limiti imposti dalla piattaforma di hosting, come invece accade su alcune piattaforme PaaS chiuse che supportano solo un elenco limitato di pacchetti.

La scelta tra i framework più diffusi basati su Node.js (Express, Fastify, NestJS) spetta interamente a te: lo starter fornito da Saplo (Express) è un punto di partenza che puoi sostituire, non un vincolo rigido, se il progetto richiede un altro framework.

Gli aggiornamenti dell'ambiente Node.js, come il passaggio a una versione LTS più recente, sono disponibili come opzione durante la riconfigurazione dell'applicazione. Puoi così restare al passo con il ciclo di rilascio di Node.js senza migrare a un altro provider soltanto perché cambiano i requisiti della versione dell'ambiente.

Per i team che seguono l'evoluzione dell'ecosistema JavaScript, con nuovi strumenti di build e nuovi pattern architetturali, l'elasticità dell'accesso SSH completo e dell'ambiente Node.js standard su Saplo non impone limiti aggiuntivi rispetto a quanto sia possibile fare su un server classico gestito autonomamente.

10. Testare le applicazioni Node.js prima del rilascio in produzione

Prima di ogni rilascio in produzione, conviene testare la nuova versione dell'applicazione in un ambiente simile a quello di produzione, ad esempio su un'applicazione separata e temporanea sullo stesso Box, prima che la modifica raggiunga il dominio finale usato realmente dai clienti.

I test automatici, unitari e di integrazione, eseguiti prima del rilascio anche solo in una semplice pipeline CI a livello di repository, aiutano a individuare regressioni nel codice prima che raggiungano il server di produzione tramite git deploy. Questo è molto più economico che correggere un errore già visibile agli utenti.

Per le applicazioni con carichi di produzione elevati, valuta di rilasciare le modifiche fuori dagli orari di picco. In questo modo limiti il numero di utenti colpiti da un eventuale breve errore durante il processo di aggiornamento del codice tramite git deploy.

Il rollback alla versione precedente e funzionante del codice, tornando a un commit precedente ed eseguendo di nuovo git push, è un semplice meccanismo di sicurezza quando il nuovo rilascio si rivela problematico. Il backup del Box, disponibile da Box L, protegge inoltre il database dell'applicazione in caso di problemi più gravi.

11. Sintesi: Node.js con git deploy, una rapida strada verso la produzione

La combinazione di uno starter Express già pronto, della scelta della versione di Node e del rilascio automatico tramite git push riduce il tempo tra l'idea e un'applicazione Node.js funzionante e accessibile pubblicamente da minuti, non da ore. Su un VPS appena creato, non devi dedicare ore alla configurazione manuale di server, firewall e reverse proxy prima ancora che la prima riga di codice dell'applicazione possa funzionare su un indirizzo di produzione con certificato SSL attivo. Per uno sviluppatore che sperimenta una nuova idea, il tempo guadagnato all'avvio può fare la differenza, perché permette di dedicare le prime ore di lavoro alla logica dell'applicazione anziché alla configurazione dell'infrastruttura che deve sostenerla. Il ragionamento vale ancora di più quando testi più idee in parallelo: il costo per verificarne una si riduce al tempo necessario per scrivere il codice, senza ripetere da zero la stessa configurazione del server a ogni tentativo.