Hosting condiviso o VPS: quale scegliere?

Hosting condiviso vs VPS: risposta breve

Il confronto tra hosting condiviso e VPS non riguarda la velocità. Con l’hosting condiviso noleggi un account su una macchina che un altro soggetto configura, aggiorna e condivide tra più clienti. Con un VPS (virtual private server) non gestito noleggi un intero sistema operativo con accesso root. Puoi quindi installare ciò che vuoi, ma devi anche riparare ciò che danneggi.

Le differenze principali sono tre. Hai accesso root oppure no. L’allocazione della memoria e le garanzie dipendono dal piano. Inoltre, quando il server smette di rispondere a mezzanotte, il problema viene risolto dall’host oppure da te. Tutto ciò che compare in una tabella delle funzionalità deriva da questi tre aspetti.

Se il tuo sito contiene pagine, immagini e un modulo di contatto, l’hosting condiviso è la scelta corretta per molti siti. Se il sito richiede un programma che continui a essere eseguito anche quando non ci sono visitatori, verifica che l’hosting condiviso supporti i servizi persistenti prima di scegliere un VPS.

Cosa offre realmente l’hosting condiviso

Un unico server Linux esegue contemporaneamente molti account cliente. Ogni account dispone di una home directory con una document root, un database e una casella di posta. Un solo web server, di solito Apache o LiteSpeed, serve tutti i siti presenti sul server. Hai a disposizione un pannello di controllo e alcuni provider offrono anche una shell. Non disponi dell’account root, ma alcuni provider consentono di installare software nella home directory e di usare determinate porte e servizi in background.

Molti provider di hosting condiviso usano CloudLinux, che inserisce ogni account in un container leggero con limiti sul tempo di CPU, sulla memoria, sull’I/O del disco, sul numero di processi e sul numero di entry process. Il superamento di ciascun limite produce effetti diversi. Il superamento del limite di CPU o di I/O rallenta la risposta del sito, ma non lo interrompe. Il superamento del limite di memoria o di processi si manifesta di solito con errori 500 e 503. Con Apache, la pagina di errore intitolata 508 Resource Limit Reached dipende dal superamento del limite degli entry process; LiteSpeed gestisce gli entry process in modo diverso. In ogni caso, è il tuo account a raggiungere il proprio limite, non un account vicino che consuma la tua quota.

Questo compromesso è intenzionale. Rinunci al controllo e, in cambio, il provider aggiorna il kernel e mantiene il software supportato; il rinnovo dei certificati e la pianificazione dei backup dipendono dal piano. Per moltissimi siti, è un compromesso vantaggioso.

Cosa offre realmente un VPS

Un VPS è una macchina virtuale eseguita su un server host. Con KVM, l'istanza avvia il proprio kernel e dispone del proprio indirizzo IP, del proprio firewall e del proprio sistema init. Su un VPS Linux non gestito con accesso root, sudo funziona. Su un'installazione Debian o Ubuntu, apt install funziona. Un programma avviato tramite systemd continua a essere eseguito dopo la disconnessione e, con la configurazione corretta per il riavvio e l'avvio automatico, viene riavviato dopo un crash e torna operativo dopo un riavvio.

Lo stesso accesso root è il motivo per cui la sicurezza della macchina diventa una tua responsabilità. Nessun altro la monitora. L'ampia gamma di applicazioni eseguite su un VPS dipende esattamente da questo motivo: il server può eseguire qualsiasi attività supportata da un server Linux.

Differenza 1: accesso root e possibilità disponibili

L’account root consente di controllare il sistema operativo. Con questo account è possibile installare qualsiasi pacchetto della distribuzione, associare qualsiasi porta, scrivere un’unità systemd, leggere tutti i log della macchina e modificare le impostazioni del kernel con sysctl. Senza root, il pannello non rappresenta sempre il limite: alwaysdata consente di installare estensioni PHP aggiuntive con ad_install_pecl.

Su un VPS è sempre possibile verificare quali processi sono in ascolto:

ss -ltnp

Ogni riga del socket mostra un listener TCP. I dettagli del processo dipendono dai permessi disponibili. Di conseguenza, se un servizio che dovrebbe essere in ascolto su TCP non è stato avviato, la relativa riga non compare. Sul shared hosting, l’accesso alle informazioni sui socket e l’autorizzazione a eseguire listener propri dipendono dal provider, anche se l’host controlla le porte 80 e 443.

Differenza 2: memoria assegnata rispetto a memoria presa in prestito

L’hosting condiviso viene venduto presumendo che pochi account siano occupati nello stesso momento. La memoria della macchina è un pool e la quota del tuo account è un limite, non una prenotazione. Su CloudLinux, il superamento del limite di memoria fisica termina i processi e i visitatori possono ricevere un errore 500 o 503.

Su un VPS, free -m segnala la memoria visibile al guest, ma non dimostra l’esistenza di una prenotazione irrevocabile di memoria fisica. Un host può recuperare memoria dal guest tramite ballooning; la possibilità di farlo dipende dalle garanzie sulle risorse previste dal tuo piano.

Il tempo di CPU è un’altra risorsa condivisa nei piani VPS con CPU condivisa e puoi misurare autonomamente lo steal time:

vmstat 1 5

La colonna st indica lo steal time: la percentuale di tempo in cui il processore virtuale era pronto per l’esecuzione mentre il core fisico era assegnato a un altro guest. Non esiste una percentuale normale o una soglia universale che dimostri l’oversubscription; uno steal time sostenuto è un dato che puoi citare in un ticket di supporto. vmstat deve poter accedere ai file /proc pertinenti, ma per le normali letture non richiede root; un host condiviso può limitare questa visibilità. Anche lo storage è una risorsa da verificare. Per questo il tipo di disco alla base di un piano VPS è importante e conviene misurare autonomamente un nuovo VPS nella prima settimana, invece di fidarsi della pagina commerciale.

Differenza 3: chi è responsabile quando qualcosa si guasta

Nel shared hosting, il provider gestisce il sistema operativo, il web server e le build PHP supportate; la copertura per certificati e backup dipende dal piano. Quando la macchina smette di rispondere, apri un ticket; i tempi di risposta dipendono dal servizio di supporto del provider. Il costo di questa soluzione è l'altra faccia della stessa regola: il software che non rientra nell'ambiente supportato deve essere compatibile con le policy di installazione e gestione dei servizi del provider.

In un VPS non gestito, il provider è responsabile dell'hypervisor, della rete e dell'alimentazione. Tutto ciò che parte dal kernel è di tua responsabilità. Aggiornamenti di sicurezza, firewall, backup, rinnovo dei certificati e monitoraggio sono tutti a tuo carico, e il supporto non accederà al server per eseguire il troubleshooting della configurazione del web server. Devi pianificarlo fin dal primo giorno: i primi dieci minuti su un nuovo VPS, poi un firewall che conosci, gli aggiornamenti automatici di sicurezza e backup che hai ripristinato almeno una volta.

Quando l’hosting condiviso è la scelta giusta

Un sito vetrina è il caso più evidente: alcune pagine, immagini, un modulo di contatto, eventualmente WordPress con un plugin di caching, e un traffico entro i limiti di risorse del piano. Nessun job in background. Nessun runtime insolito. Nulla che debba rimanere in memoria tra una richiesta e l’altra. L’hosting condiviso gestisce bene questo tipo di sito e affida la manutenzione del server a professionisti che se ne occupano a tempo pieno; confronta i prezzi, perché non costa meno di ogni VPS. Spostarlo su una VPS non offre alcun vantaggio e aggiunge un’attività che prima non dovevi gestire.

Esiste un secondo caso che riceve meno attenzione. Se nessuno nel tuo team vuole leggere un file di log o eseguire apt upgrade, l’hosting condiviso è la scelta più sicura. Una VPS senza patch e con una porta del database esposta produce un risultato peggiore rispetto a un account condiviso mantenuto aggiornato da un professionista. Il controllo è un vantaggio solo se qualcuno lo utilizza.

Segnale 1: serve un programma che resti in esecuzione

Un daemon è un programma che rimane in memoria e attende attività: un'API, un chatbot, un worker per una coda o un game server. Le regole dell'hosting condiviso variano: DreamHost vieta i processi persistenti sui piani condivisi, mentre alwaysdata offre servizi personalizzati supervisionati sui piani a pagamento.

Su un VPS, lo stesso programma diventa un'unità systemd:

sudo systemctl enable --now myapp
systemctl status myapp

systemctl status dovrebbe restituire Active: active (running) con un ID di processo. Se restituisce Active: failed (Result: exit-code), il motivo è indicato in journalctl -u myapp -n 50, che mostra l'output del programma nel momento in cui si è arrestato. Restart=always nel file dell'unità lo riavvia dopo un crash, mentre enable lo riavvia dopo un reboot. Scrivere servizi e timer systemd è la prima competenza sui VPS che vale la pena imparare correttamente.

Segnale 2: serve un runtime che il pannello non offre

Il pannello fornisce un elenco. Se l'applicazione richiede una versione del linguaggio che non compare nell'elenco, una libreria da compilare, ffmpeg, un browser headless o un database che il pannello non offre (cPanel supporta MySQL e, se il provider lo abilita, PostgreSQL), verifica le regole di installazione del provider. L'installazione del software nella directory home non richiede sempre root: DreamHost documenta la compilazione di zlib e di una versione personalizzata di Python sui server condivisi.

Su un VPS puoi installarlo con apt install oppure eseguirlo in un container, mantenendo pulito l'host. Docker Compose su un VPS è la soluzione abituale quando l'applicazione comprende più componenti interdipendenti.

Segnale 3: il cron job deve essere eseguito nei tempi previsti

Gli hosting condivisi accettano i cron job tramite un modulo e il provider può imporre un intervallo minimo. Su CloudLinux, un job che raggiunge il limite di CPU dell'account viene rallentato anziché terminato. Un job di lunga durata può quindi essere ancora in esecuzione quando arriva il momento del successivo. Se l'account ha già raggiunto il limite di processi, il job non può avviare nuovi processi. È possibile osservare una parte di questo comportamento: l'impostazione Cron Email di cPanel invia tramite email l'output di ogni job e, sugli host CloudLinux che offrono questa funzione, la pagina Resource Usage del pannello indica il limite raggiunto dall'account e conta gli sforamenti. L'accesso ai log di sistema e l'autorizzazione ad aumentare i limiti restano di competenza del provider, ma alcuni provider rendono disponibili i log delle attività con gli orari di avvio e di fine.

Su un VPS, crontab -e accetta le pianificazioni supportate dall'implementazione cron installata, ma un timer systemd è una soluzione ancora migliore:

systemctl list-timers
journalctl -u cron -n 20

list-timers mostra gli orari della prossima e dell'ultima attivazione dei timer attualmente caricati in memoria, non i codici di uscita dei relativi servizi. Il journal di cron dipende dal servizio cron installato e dalla configurazione del logging. Quando un job non viene eseguito, controlla lo stato e i log del relativo servizio per capire se non è mai stato avviato oppure se è stato avviato ma è terminato con un errore. Questa distinzione costituisce gran parte del troubleshooting di un'attività pianificata.

Segnale 4: gli account vicini stanno aumentando i tempi di risposta

Il sintomo è specifico. La stessa pagina, senza modifiche al codice, risponde rapidamente di notte e lentamente alle sette di sera. Misurala dal tuo computer prima di attribuire la colpa ad altri:

for i in $(seq 1 20); do curl -o /dev/null -s -w '%{time_starttransfer}\n' https://example.com/; sleep 5; done

time_starttransfer indica il tempo necessario per ricevere il primo byte della risposta, in secondi. Se i venti valori sono ravvicinati, questo indica tempi uniformi, ma non chiarisce se la causa sia nel server, nel codice o nel database. Se alle 3am i valori sono stabili e nelle ore di punta variano di diverse centinaia di millisecondi, confronta l'utilizzo delle risorse dell'account, il volume delle richieste e i log del server prima di attribuire la colpa agli account vicini. Queste misurazioni includono l'instaurazione della connessione e l'elaborazione sul server, quindi da sole non stabiliscono la causa.

Quanto costa realmente il passaggio

Questi sono esempi pubblicizzati e verificati il 4 novembre 2026, non medie dell'intera categoria né i piani più economici disponibili. Gli esempi di hosting condiviso, VPS da 4 GB e servizio gestito sono rispettivamente Web Hosting Launch, Stack 4 e Managed VPS Business di DreamHost con fatturazione annuale; il VPS da 1 GiB è il Droplet Basic standard di DigitalOcean, al limite massimo mensile. Verifica il prezzo corrente prima dell'acquisto.

[
  {
    "plan": "Shared hosting, DreamHost",
    "first_term_usd": 2.89,
    "renewal_usd": 10.99
  },
  {
    "plan": "VPS, 1 vCPU 1 GiB, DigitalOcean",
    "first_term_usd": 6,
    "renewal_usd": 6
  },
  {
    "plan": "VPS, 2 vCPU 4 GB, DreamHost",
    "first_term_usd": 6.99,
    "renewal_usd": 11.99
  },
  {
    "plan": "Managed VPS, 2 cores 2 GB, DreamHost",
    "first_term_usd": 13.75,
    "renewal_usd": 31.99
  }
]

La differenza iniziale indicata va da 2.89 a 6 dollari al mese, ma non è questo il dato decisivo. L'esempio di hosting condiviso richiede il pagamento anticipato di un anno e, al rinnovo, costa 10.99 dollari al mese. Se confronti i prezzi di rinnovo, il quadro cambia: 10.99 dollari per l'account condiviso contro 6 dollari per un VPS entry-level. Le due cifre di DigitalOcean sono uguali perché questo esempio non prevede uno sconto introduttivo.

Presta attenzione a questo confronto, perché le dimensioni non sono equivalenti. Un VPS con 1 vCPU e 1 GB esegue il web server e il database sullo stesso server di piccole dimensioni; quando arriva traffico reale, questa configurazione è al limite per WordPress. L'esempio con 2 vCPU e 4 GB si rinnova a 11.99 dollari al mese, ma i limiti di un account condiviso e la capacità di un VPS non sono direttamente confrontabili. In questi esempi, il sovrapprezzo al rinnovo rispetto all'hosting condiviso è di un dollaro al mese.

Il costo maggiore non compare mai in fattura. Un VPS richiede un'ora per la configurazione iniziale, alcuni minuti ogni mese per gli aggiornamenti e la serata che dovrai dedicare alla prima risoluzione di un problema. Valuta questo tempo in base alla tua tariffa oraria e la differenza si riduce rapidamente. Quanto costa un VPS nella pratica analizza più dettagliatamente le diverse dimensioni.

Spostare un sito dall'hosting condiviso senza perdere traffico

1. Il giorno precedente, riduci il TTL (time to live) DNS (domain name system) del dominio a 300 secondi e attendi la scadenza del TTL precedente prima di effettuare il passaggio; le cache locali possono comunque richiedere più tempo per aggiornarsi.
2. Prepara il nuovo server e fai funzionare il sito sul relativo indirizzo IP prima di modificare il DNS.
3. Copia i file, quindi esegui il dump del database e ripristinalo sul nuovo server.
4. Esegui i test tramite il file hosts del laptop, che associa il dominio al nuovo IP solo per il tuo computer.
5. Emetti il certificato TLS (transport layer security) sul nuovo server usando la convalida DNS oppure un certificato valido già esistente prima di modificare il record A, e mantieni attivo l'account di hosting condiviso per una settimana.

dig example.com A +noall +answer
rsync -avz ~/public_html/ deploy@203.0.113.10:/srv/www/example.com/
mysqldump --single-transaction -u dbuser -p dbname > site.sql

dig stampa il TTL nella seconda colonna della risposta, così puoi verificare che il valore ridotto sia effettivo prima di eseguire il passaggio. --single-transaction crea uno snapshot coerente delle tabelle InnoDB senza bloccarle; le tabelle non transazionali e le modifiche simultanee allo schema richiedono verifiche separate e gli ordini successivi non sono inclusi nello snapshot. Sul nuovo server, configura i certificati lo stesso giorno: Let's Encrypt su Ubuntu con nginx richiede pochi minuti quando il record DNS punta al server.

Risorse senza la responsabilità

Se i quattro segnali descrivono il tuo sito ma non vuoi occuparti della manutenzione, l'opzione intermedia è un VPS gestito. Il provider si occupa della manutenzione concordata, ma l'accesso root e la copertura della gestione dipendono dal piano; il VPS gestito di DreamHost non include l'accesso root. Il grafico sopra indica 31.99 dollari per l'esempio di VPS gestito da 2 GB, contro 11.99 per l'esempio di VPS non gestito da 4 GB. Non si tratta quindi di un confronto tra risorse equivalenti. La differenza serve a pagare l'intervento di qualcun altro quando il server smette di rispondere durante la notte.

La scelta tra VPS gestito e non gestito è il prossimo contenuto da leggere se questa situazione ti riguarda. Se invece gestisci già un VPS molto utilizzato e il furto di tempo resta un problema nelle ore di punta, il passo successivo è un server dedicato senza vicini.

FAQ

Un VPS è più veloce dell'hosting condiviso?

Non automaticamente. Un server condiviso poco carico può superare un VPS con 1 vCPU nel caricamento di una singola pagina WordPress. La memoria assegnata non elimina la contesa sulla CPU: su un VPS con CPU condivisa, le istanze vicine possono comunque influire sui tempi di risposta e le garanzie sulla memoria dipendono dal provider. Se le pagine sono lente sia alle 3am sia alle 7pm, controlla il codice, le query al database e i limiti delle risorse dell'hosting; l'orario non identifica la causa.

Posso eseguire un'app Node.js o Python su un hosting condiviso?

A volte, entro i limiti del provider. Alcuni pannelli avviano un'applicazione tramite Passenger e questa viene eseguita quando arriva una richiesta. Il fatto che l'host controlli le porte 80 e 443 non impedisce l'uso di altri listener autorizzati: alwaysdata consente servizi personalizzati sulle porte da 8300 a 8499 tramite IPv6 nel suo Public Cloud. Anche le regole sui processi persistenti variano in base all'host. Per eseguire un bot, un worker di coda o un server websocket serve quindi un piano che lo supporti esplicitamente, non necessariamente un VPS.

Devo conoscere Linux per gestire un VPS?

Per un VPS non gestito, sì. Devi conoscere le chiavi SSH, un firewall, gli aggiornamenti, i backup e la lettura dei log. Considera un'ora per la configurazione iniziale e alcuni minuti al mese in seguito. Se non vuoi occuparti di queste attività, un piano gestito affida al provider la manutenzione concordata. Questo è il compromesso descritto in hosting VPS gestito e non gestito.

Il mio sito sarà irraggiungibile durante il passaggio dall'hosting condiviso a un VPS?

Ridurre il TTL DNS e mantenere attivi entrambi gli account aiuta a evitare l'interruzione del servizio, ma non garantisce un passaggio senza disservizi. Imposta il TTL su 300 secondi il giorno precedente e attendi la scadenza del TTL precedente. Copia i file e il database, testa il nuovo server tramite il file hosts del laptop, quindi modifica il record A. Durante il passaggio alcuni visitatori raggiungeranno il vecchio server e altri il nuovo. Le cache possono impiegare più di cinque minuti per aggiornarsi, quindi mantieni attivo l'account condiviso per una settimana. Sospendi le scritture per l'ultimo dump e ripristino del database. Mantieni il vecchio sito in sola lettura oppure inoltra le relative richieste al nuovo server, così le scritture successive non andranno perse.