Hosting Docker e Node.js 2026: Dal Shared al VPS, Quale Scegliere

Hai un’applicazione Node.js, un servizio impacchettato in container, magari un insieme di strumenti self-hosted, e cerchi un hosting Docker che non ti costringa a pagare una piattaforma gestita al prezzo di un affitto. La domanda sembra tecnica, ma la risposta è soprattutto economica: tra un hosting condiviso da pochi euro e un servizio PaaS da decine di euro per applicazione esiste una fascia intermedia, il VPS con Docker, dove i costi si abbassano e le responsabilità salgono. Questa guida ti mostra come muoverti su quella scala, quanta RAM serve davvero (e quanta ne mangiano gli strumenti di deploy), quali trappole operative colpiscono i container in produzione e quale VPS scegliere con i prezzi di oggi.

Se cerchi invece l’inquadramento generale dell’hosting Docker e non solo, parti dalla guida hosting per sviluppatori; per i framework PHP vedi hosting Laravel, per le API hosting per API e microservizi e per i prodotti software hosting per SaaS e applicazioni.

Hosting Docker e Node.js: la scala dei quattro gradini

Non esiste “il” hosting per Node.js: esistono quattro livelli di controllo, e la scelta giusta è quella dell’ultimo gradino di cui hai davvero bisogno. Salire costa competenze, non solo denaro.

Gradino 1: Node.js su hosting condiviso

Si può, ma non su qualsiasi piano. Node.js non è una funzione predefinita dell’hosting condiviso e la stessa applicazione può funzionare da un provider e fallire da un altro. Il meccanismo tipico è il Node.js Selector di CloudLinux, esposto dal pannello (cPanel o DirectAdmin) e gestito tramite Passenger, che supervisiona il processo e lo riavvia. In pratica scegli la versione di Node, indichi il file di avvio e la cartella dell’applicazione, imposti le variabili d’ambiente e il pannello collega il dominio all’app.

I limiti, invece, sono quelli che rendono questo gradino adatto solo a carichi leggeri:

• tetti di CPU e memoria che possono arrestare l’applicazione sotto carico;
• porte personalizzate di norma bloccate: l’app non sceglie su quale porta ascoltare, la decide Passenger;
• WebSocket e connessioni persistenti spesso limitati, quindi niente chat in tempo reale o dashboard in streaming;
• processi in background e job di lunga durata limitati o vietati;
• nessun PM2 né altri gestori di processi personalizzati;
• compilazione di moduli nativi che spesso fallisce.

Una piccola applicazione Express o una API a basso traffico può funzionare bene qui. Appena ti servono processi persistenti, WebSocket, pacchetti di sistema che richiedono root o più servizi in parallelo, il segnale è chiaro: passa al VPS. Per capire la differenza tra le due famiglie di prodotti leggi cloud server contro VPS.

Gradino 2: hosting Docker, perché serve un VPS e quanta RAM

L’hosting Docker ha bisogno di funzioni del kernel e di privilegi di amministratore che nessun hosting condiviso concede. Per usarlo ti serve un VPS (o un server dedicato) con accesso root e un sistema operativo Linux; se il tuo orientamento è tra Linux e Windows, la guida hosting Linux contro Windows chiarisce perché per i container la scelta è quasi sempre Linux.

Per l’hosting Docker la domanda successiva è quanta memoria comprare. Un’app Node.js tipica in produzione usa una frazione di gigabyte, ma Docker e il resto dello stack ne consumano a loro volta: sistema operativo, daemon dei container, reverse proxy, database, strumenti di monitoraggio. Il criterio pratico che ti consigliamo è partire da 4 GB come minimo operativo e da 8 GB come configurazione comoda se prevedi più servizi o un database sulla stessa macchina.

Prezzi del database FindHost; per Hetzner, listino dopo l’aumento del 15 giugno 2026. Ricorda che in questo elenco la fascia di prezzo non dice nulla sulla costanza delle prestazioni: i piani molto economici concentrano più tenant per host, e per un servizio con utenti reali conviene misurare il steal time della CPU nei primi giorni. Per i dettagli leggi Contabo VPS, Hetzner VPS e IONOS; l’elenco dei piani sotto i 10 euro è in VPS economici.

Gradino 3: hosting Docker con PaaS self-hosted e la tassa nascosta sulla RAM

Gestire i container a mano con Docker Compose funziona benissimo per una o due applicazioni; quando ne hai cinque, con domini, certificati, database e deploy automatici da Git, comincia a pesare. Gli strumenti PaaS self-hosted risolvono il problema: installi un pannello sul tuo VPS e ottieni una piattaforma in stile “Vercel fatto in casa” con deploy da repository, HTTPS automatico via Let’s Encrypt, variabili d’ambiente e database con pochi clic. I due nomi che emergono nei confronti del 2026 sono Coolify e Dokploy.

Il dato che nessuno mette in evidenza è il costo in memoria. Se prendi per buoni i consumi a riposo riportati dall’analisi (da verificare nel tuo ambiente, perché cambiano con la versione e con i servizi attivi), su un VPS da 4 GB la piattaforma si porta via il 30% della RAM con Coolify (1,2 GB) e il 20% con Dokploy (0,8 GB) prima ancora di avviare la tua prima applicazione. Su un VPS da 8 GB le percentuali scendono al 15% e al 10%. È la ragione per cui il confronto sui prezzi della tabella precedente cambia valore: un piano da 4 GB è sufficiente per Compose, ma per un PaaS la soglia comoda è 8 GB.

Hosting Docker in produzione: sette trappole di Compose che colpiscono tutti

La parte che le guide ai container saltano è quella operativa. Questi sono gli errori che vediamo più spesso quando un’applicazione Docker passa dal portatile al VPS:

1. Le porte pubblicate aggirano il firewall. Quando in Compose scrivi una porta aperta, Docker modifica direttamente le regole di rete del sistema e in molte configurazioni ignora le regole di UFW. Un database pubblicato per comodità può risultare raggiungibile da Internet pur con il firewall “attivo”. Soluzione: pubblica solo su 127.0.0.1 e lascia che il reverse proxy sia l’unico ingresso.
2. I log riempiono il disco. Il driver predefinito non ruota i log: dopo qualche mese un container verboso può esaurire i 40 o 75 GB del VPS. Imposta sempre una dimensione massima e un numero di file.
3. Niente politica di riavvio. Senza restart: unless-stopped un riavvio del server lascia i servizi spenti.
4. Niente controlli di salute. Un processo vivo non è un servizio funzionante: aggiungi un healthcheck per far riavviare i container bloccati.
5. Immagini senza versione. Usare l’etichetta latest significa che un deploy di domani può rompere l’app di oggi. Fissa la versione.
6. Volumi senza backup. I dati vivono nei volumi: serve un dump regolare dei database e una copia fuori dal server (vedi backup automatico).
7. Limiti di memoria assenti. Un servizio con una perdita di memoria può far intervenire l’OOM killer sul container sbagliato: imposta un limite per servizio.

Una configurazione di partenza che copre quasi tutte queste voci:

services:
  app:
    image: ghcr.io/tuo-utente/tuo-app:1.4.2
    restart: unless-stopped
    env_file: .env
    ports:
      - '127.0.0.1:3000:3000'
    healthcheck:
      test: ['CMD', 'wget', '-qO-', 'http://localhost:3000/health']
      interval: 30s
      timeout: 5s
      retries: 3
    logging:
      driver: json-file
      options:
        max-size: '10m'
        max-file: '3'
    deploy:
      resources:
        limits:
          memory: 512M

Nota le due scelte chiave: la porta è legata a localhost, quindi l’unico ingresso pubblico sarà il proxy, e i log hanno un tetto. Ricordati di aggiungere al sistema le difese di base (accesso SSH con chiave, aggiornamenti automatici, fail2ban, monitoraggio esterno): la checklist è nella guida alla sicurezza dell’hosting.

Hosting Docker: reverse proxy e HTTPS davanti ai container

Un’applicazione Node.js non dovrebbe mai esporre direttamente la porta 80 o 443: davanti ci va un reverse proxy che gestisce il certificato, la compressione e il routing verso i container. Le tre scelte più diffuse hanno caratteristiche diverse. Caddy ottiene e rinnova i certificati in automatico con pochissima configurazione, ed è il più semplice per chi parte da zero. Traefik si configura con le etichette dei container e rileva da solo i nuovi servizi, ottimo se aggiungi applicazioni di frequente. Nginx (spesso in coppia con un gestore grafico) è il più diffuso e documentato, ma richiede più lavoro per i certificati. Con un PaaS come Coolify o Dokploy la scelta è già fatta, perché integrano Traefik. Per i concetti su certificati e protocolli leggi SSL, HTTPS e HTTP/2.

Hosting Docker, sede dei server e GDPR

Se la tua applicazione tratta dati di utenti italiani o europei, la sede del VPS conta. Le opzioni che abbiamo analizzato hanno datacenter in Germania, Francia e Finlandia e nessuna sede in Italia: una scelta compatibile con il GDPR a patto di documentarla nel registro dei trattamenti e di verificare dove finiscono i backup e i servizi esterni collegati. Per chi ha bisogno di una presenza italiana, la panoramica è in VPS Italia: migliori provider. Quando cambi fornitore, la procedura di migrazione senza downtime vale anche per i container: la differenza è che sposti volumi e configurazioni, non file PHP.

Quale hosting Docker scegliere in base al progetto

Pro e contro dell’hosting Docker su VPS

Domande frequenti su hosting Docker e Node.js

Per il quadro generale sull’hosting Docker e sugli altri tipi di hosting leggi la guida completa all’hosting, e se stai ancora decidendo tra le fasce di prezzo, come scegliere l’hosting.