Cos’è un server cloud: hosting condiviso, VPS o cosa serve al Suo sito

Hosting condiviso, VPS e server cloud nel listino sembrano tre livelli di potenza, ma differiscono in tre punti: che cosa La separa dai vicini sulla stessa macchina, dove l’account va a sbattere e chi aggiorna il software.

Un mercoledì mattina, verso le dieci, il sito diventa lento — non cade, è solo lento: la pagina si apre in cinque secondi, il pannello di amministrazione rifiuta di salvare una voce e, dopo mezz’ora, tutto è di nuovo a posto, come se non fosse successo nulla. L’assistenza del provider risponde dopo pranzo che l’account ha superato i limiti del proprio piano, e propone di passare al livello successivo, che costa tre volte tanto e nel listino si chiama «server cloud».

Cos'è un server cloud, che cosa sono l’hosting condiviso e il VPS: in questo momento la maggior parte di chi compra non sa che cosa sta acquistando davvero, e non è un rimprovero — nel listino i tre stanno uno sotto l’altro come tre livelli di potenza dello stesso servizio, mentre sono tre soluzioni tecniche diverse, che differiscono in tre punti concreti. Lei può verificare ciascuno di questi tre punti con i numeri del Suo sito in mano, e nessuno si legge dal nome del piano.

Tre punti in cui i piani differiscono davvero

Il primo è l’isolamento, cioè che cosa esattamente separa il Suo sito dai siti degli altri clienti sulla stessa macchina fisica. Nell’hosting condiviso è un account nel sistema operativo insieme a un contenitore di risorse a livello di kernel; nel caso del VPS è una macchina virtuale separata con un proprio sistema operativo; nel server cloud è la stessa macchina virtuale, solo ordinata e fatturata in un altro modo. La differenza pratica tra queste tre varianti sta in quanto il carico di un vicino può influire sul Suo sito e in quanto della macchina Le è lecito cambiare, quando la configurazione predefinita non Le va.

Il secondo punto è il limite, cioè dove l’account va a sbattere e come si manifesta, ed è proprio qui che nascono più malintesi, perché si aspetta che il sovraccarico significhi una pagina lenta, mentre in una parte dei casi significa una pagina che non si apre affatto e restituisce un codice di errore che chi compra, in vita sua, non ha visto neanche una volta. Il terzo punto è la responsabilità, cioè chi aggiorna il sistema operativo, chi il server web, chi PHP e chi il sito stesso, ed è proprio qui che chi compra un VPS sbaglia i conti più spesso, perché l’accesso root non è un regalo che il provider consegna insieme a una macchina più potente — è il passaggio dell’elenco dei doveri da lui a Lei, e avviene in silenzio, nello stesso minuto in cui viene inviata la password.

Tutto il resto, che nella tabella di confronto dell’hosting occupa le righe, o è uguale in tutti i piani, o non è ciò che non regge: i dischi NVMe oggi sono praticamente ovunque, ma «traffico illimitato» è un’affermazione sul volume di dati trasmessi, non sulle risorse, e di solito sta proprio accanto alla tabella in cui le risorse sono contate fino all’ultimo megabyte. Il 99,9%, invece, è un numero con un significato giuridico preciso e con un elenco di eccezioni sotto, e la maggior parte di chi compra pensa che copra tutt’altra cosa da quella che copre davvero.

Hosting condiviso: un server, molti account

L’hosting condiviso è un account utente su una macchina su cui vivono ancora centinaia di account uguali, e i provider italiani chiamano lo stesso prodotto in tre modi diversi: OVH lo scrive come hosting condiviso, Aruba lo vende come Hosting Linux, Register.it come Web Hosting. Sul piano tecnico, in tutti e tre i casi, significa lo stesso accordo — a Lei appartiene l’account, non la macchina, e il sito Lei lo gestisce attraverso cPanel o un pannello simile, e tutto ciò che sta sotto quel pannello appartiene a qualcun altro.

Ciò che La separa dai vicini è un software concreto, non una promessa nel listino, e conviene conoscerlo per nome. La maggior parte dei provider con cPanel lavora su CloudLinux, in cui ogni account ha una propria copia del file system: la documentazione di CloudLinux su CageFS scrive che gli utenti non possono né vedere né individuare altri utenti e i loro nomi utente sul server, non possono leggere la configurazione del server web e vedono solo un elenco di processi ridotto. Il secondo strato è LVE — un contenitore di risorse a livello di kernel, che a ogni account assegna limiti di processore, memoria, input/output e processi proprio perché, come formula la documentazione stessa, nessun sito singolo possa far cadere l’intero server web.

Il terzo strato è l’impostazione PHP open_basedir, e su questo conviene sapere che cosa dice il manuale PHP stesso, non il marketing del provider: è soltanto «una rete di sicurezza aggiuntiva, che non è in alcun modo completa e quindi non può essere considerata affidabile quando è richiesta sicurezza». La disattivazione delle funzioni con disable_functions, nello stesso ordine di idee, può essere aggirata e in un ambiente condiviso non è una misura di sicurezza sufficiente. Nulla di questo è un argomento contro l’hosting condiviso; è un argomento sul fatto che l’isolamento, qui, lo danno il kernel e il file system, non una riga in un file di configurazione, e che un provider che alla domanda sull’isolamento risponde con la parola «sicuro» non ha risposto.

Ciò che nell’hosting condiviso non si può scegliere è altrettanto importante di ciò che si può: il kernel è uno per tutti gli account, quindi la versione del kernel non la cambierà; l’elenco delle versioni PHP lo decide il provider e di solito resta indietro di una o due rispetto all’ultima; il server web è quello installato, quindi alla domanda su un pacchetto che lì non c’è la risposta sarà «no», non «lo installi». Un server condiviso è anche il luogo in cui, in caso di incidente, il provider deve controllare gli account vicini, perché un aggressore entrato in un account prova lo stesso con i vicini; che cosa fare quando è già successo lo abbiamo descritto nell’articolo su un sito WordPress hackerato. Nessuno di questi limiti è un difetto: è esattamente l’accordo che rende questo prodotto economico, e chi compra capendolo ne trae vantaggio.

Che cosa succede quando l’account va a sbattere contro il proprio limite

Un piano di hosting condiviso ha più limiti diversi, si raggiungono indipendentemente l’uno dall’altro e si manifestano in modo del tutto differente, quindi il sintomo è uno strumento di diagnosi utile. I limiti predefiniti di CloudLinux per un account sono il 100% di un core del processore, 1 GB di memoria fisica, 1024 KB/s di input/output, cento processi e venti entry processes, ed è proprio l’ultimo numero a sorprendere chi compra, perché venti sembra un numero ridicolmente piccolo per un sito che in un mese riceve diecimila visitatori.

La spiegazione è che un entry process non è un visitatore: è un processo che entra nell’account dall’esterno — una nuova richiesta HTTP a uno script PHP, una sessione SSH o un job cron — mentre i processi che nascono già all’interno contano in un limite del tutto diverso. Quando il numero di entry processes è raggiunto, il modulo Apache non fa più entrare la richiesta successiva e restituisce l’errore 508 Resource Limit Reached, e CloudLinux nella propria knowledge base lo descrive senza addolcirlo: il sito che consuma troppe risorse smette di funzionare, mentre gli altri clienti sullo stesso server continuano a operare normalmente. È proprio questo il senso del meccanismo — tagliare un account, perché la macchina non si fermi.

Gli altri limiti si manifestano in altro modo, e dal sintomo si può leggere quale è stato raggiunto, prima che qualcuno si metta a indovinare: processore e input/output non vengono tagliati, ma rallentati, quindi la pagina diventa lenta e alla fine si apre, mentre i limiti di memoria e di processi di solito danno 500 o 503, cioè una pagina che non si apre affatto. Sui server LiteSpeed gli entry processes si contano in modo diverso rispetto ad Apache, quindi lì lo stesso numero non si può tradurre come numero di visitatori contemporanei, ed è uno dei modi più frequenti in cui un numero corretto finisce in una frase sbagliata.

C’è ancora un quarto limite, che con il carico non c’entra per nulla e per questo arriva all’improvviso: un inode è la voce del file system su un singolo file o cartella, quindi il numero di inode nell’account è semplicemente il numero di file e cartelle, compresa la casella di posta che nessuno svuota da anni. Hostnet, nel proprio listino, pubblica gli inode apertamente — piano MINI 400.000, PLUS 600.000, PRO 800.000 — e nella stessa tabella accanto a MINI e PLUS stanno il 100% di un core e 2048 MB di memoria, a PRO il 200% e 3072 MB, e per tutti e tre 10 MB/s di input/output e 150 connessioni contemporanee, mentre il traffico mensile è «illimitato». Questo accostamento è la vera lezione sulla parola «illimitato» in un listino di hosting: riguarda il volume di dati trasmessi, e tutti gli altri limiti stanno lì accanto, contati fino all’ultimo numero.

VPS: un sistema operativo proprio su hardware condiviso

Un VPS è una macchina virtuale in cui Le appartengono il sistema operativo, l’accesso root e la possibilità di installare ciò che serve, e nel mercato italiano lo si scrive sia in italiano sia con la sigla inglese: OVH nella propria pagina lo chiama server privato virtuale (VPS). Ciò che questo nome non dice sono due questioni tecniche, che decidono quanto del «proprio server» è davvero Suo.

La prima questione è se la virtualizzazione sia a livello di hardware o di sistema operativo. KVM è un modulo del kernel Linux che usa le estensioni di virtualizzazione del processore e dà a ogni guest un proprio hardware virtualizzato — scheda di rete, disco, adattatore video — e, soprattutto, un proprio kernel, quindi su di esso si può far girare anche Windows non modificato. LXC e i container affini sono un altro meccanismo: usano i namespace Linux, i cgroups e la restrizione dei privilegi per creare un ambiente il più vicino possibile a un’installazione Linux separata, però senza un kernel proprio. Le conseguenze sono semplici e pratiche — in un container la versione del kernel, i moduli del kernel e le vulnerabilità del kernel restano condivise con la macchina host, quindi una parte di ciò che Lei pensava di comprare è rimasta davvero ai vicini.

La seconda questione riguarda il processore, perché le parole «proprio server» non significano un processore proprio. Hetzner, per i server cloud, ha due linee di prodotto distinte: nei piani a risorse condivise la capacità di calcolo viene ripartita tra tutte le istanze sullo stesso server fisico, con una prestazione di base e la possibilità di superarla per un po’, mentre nei piani a risorse dedicate una vCPU è un thread di un core fisico ed è soltanto Sua. DigitalOcean lo formula ancora più chiaramente: in un piano condiviso il thread può essere condiviso con altri e, se i vicini hanno un carico alto, l’istanza riceve frazioni del thread, non l’accesso pieno, così che in pratica l’accesso pieno è possibile, ma non è garantito.

Quanti vicini ci sono su una macchina, non lo pubblica nessuno dei grandi fornitori, e il rapporto che troverà nei blog non è la misurazione pubblicata di nessuno, quindi non vale né citarlo né crederci. L’unica grandezza documentata a cui ci si può richiamare è se il piano promette risorse condivise o separate, e questa differenza di solito è scritta del tutto apertamente — con due nomi di prodotto diversi, due specifiche diverse e una differenza di prezzo di diverse volte.

Cos’è un server cloud: lo stesso VPS, comprato in un altro modo

Un server cloud, sul piano tecnico, è una macchina virtuale su un hypervisor, cioè esattamente la stessa cosa di un VPS. OVH, nella guida italiana che risponde a questa domanda, lo descrive come un server creato a partire da un server fisico e reso disponibile in rete, e la documentazione di Hetzner parte dallo stesso enunciato — i server cloud sono macchine virtuali che girano su server fisici. Se da due offerte Lei si aspetta due macchine diverse, l’attesa non ha fondamento.

La differenza non sta nell’hardware, ma nel modo di comprare, e la descrive con più precisione la definizione dell’istituto statunitense di standard NIST, che il settore continua a citare: il cloud ha cinque tratti — self-service su richiesta, accesso in rete, raggruppamento delle risorse con più tenant, elasticità rapida e consumo misurato. In pratica significa un’API con cui la macchina si può creare e smontare via software, una tariffazione a ore con un tetto mensile e pezzi aggiuntivi che si possono collegare a parte: snapshot, storage a blocchi separato, un indirizzo IP trasferibile e un bilanciatore di carico.

Ciascuno di questi pezzi ha dei limiti, che conviene conoscere prima dell’acquisto, non un mese dopo. Il cambio di piano di Hetzner non può ridurre la dimensione del disco anche se ne viene usata solo una parte; dopo un aumento del disco la partizione va estesa da sé in modalità rescue, e il cambio di piano stesso è elencato come eccezione alla garanzia di disponibilità. Uno snapshot, a sua volta, non è un backup, anche se sul mercato le due parole si usano come sinonimi: negli snapshot di Hetzner non rientrano i volumi collegati, e la coerenza non è garantita se il server è in esecuzione, quindi è una buona cosa prima di un aggiornamento e una cattiva cosa come unica copia dei dati. L’indirizzo IPv4 trasferibile si paga a parte, come l’indirizzo IPv4 principale accanto all’istanza stessa.

Al sito aziendale di cinque pagine di solito non serve nessuno di questi pezzi, ed è la frase più onesta di questa parte: se il sito non cambia mai potenza, non passa mai su una seconda macchina e non viene mai collegato a un’API, allora un server cloud e un VPS della stessa misura sono la stessa macchina con due fatture diverse. Non è un argomento contro il cloud, perché dove l’elasticità viene usata costa meno di una riserva tenuta sempre accesa. È un argomento sul fatto che la scelta è tra capacità che Lei userà davvero, non tra parole che suonano moderne.

Chi aggiorna che cosa

La differenza pratica più grande tra i tre piani non è la velocità, ma la ripartizione dei doveri, e l’hanno formulata con più chiarezza i provider di cloud stessi. Il modello di responsabilità condivisa di AWS divide tutto in due parti: la sicurezza «del» cloud è responsabilità di AWS — hardware, software, rete e i locali in cui i servizi operano — ma la sicurezza «nel» cloud è responsabilità del cliente. Sulla questione delle patch è persino scritto a parte e parola per parola: AWS è responsabile delle patch e della risoluzione dei problemi dell’infrastruttura, il cliente delle patch del proprio sistema operativo guest e delle proprie applicazioni.

Nell’hosting condiviso questo strato appartiene al provider, ed è il valore più grande di questo prodotto, a cui raramente si pensa: kernel, server web e PHP li aggiornano loro, e Lei non ne sa nulla, finché qualcosa non si rompe. In un VPS o in un server cloud non gestiti tutto questo è passato a Lei insieme alla password root, e Hetzner nei propri termini lo dice anche dall’altra parte: software, configurazione e impostazioni di sistema introdotti dal cliente non si considerano un disturbo di disponibilità, quindi il fornitore non ne risponde e non entrano in alcun indennizzo.

Il sito stesso resta di Sua responsabilità in tutti e tre i casi, ed è il punto in cui le offerte vanno lette con attenzione, perché la parola «gestito» nel settore di solito significa sistema operativo e software del server, non il core di WordPress, i plugin e il tema. Anche nella manutenzione del nostro noleggio di infrastruttura rientrano gli aggiornamenti di sistema operativo e software del server, la configurazione di sicurezza, i backup con ripristino verificato, il monitoraggio e la reazione secondo SLA — e lì non è scritto che aggiorniamo i Suoi plugin, perché quella è un’altra riga del listino e un altro contratto, e lo diciamo con chiarezza, perché nessuno scopra questo confine il giorno dell’incidente.

La prova pratica prima dell’ordine è una domanda sola, posta dritta e in tre parti: chi aggiorna il sistema operativo, chi il server web e PHP, e chi il codice del sito. Se la risposta a una delle tre è «Lei stesso», allora è un lavoro per il quale serve o una persona con del tempo, o un contratto con qualcun altro, e nessuno dei due è gratis. Senza risposta questa domanda non scompare — torna dopo diciotto mesi come un sistema in cui nessuno ha messo una sola patch, e allora non è più una questione di scelta del piano.

Che cosa significa il 99,9% e che cosa non copre

La percentuale di disponibilità nel listino ha l’aria di una promessa, ma in realtà è una formula con un elenco di eccezioni. L’accordo sul livello di servizio di Hetzner per i server cloud promette il 99,9% al mese per una istanza, e Hetzner stesso, nella propria spiegazione, calcola che cosa questo numero significa in pratica: in un mese di trenta giorni, 43 minuti di fermo restano ancora entro i limiti dell’accordo, cioè non sono una violazione e per essi non è previsto alcun indennizzo.

L’indennizzo stesso è altrettanto concreto e molto più piccolo di quanto si aspetti: si calcola dai minuti sopra la soglia, convertiti in ore e moltiplicati per la tariffa oraria dell’istanza, e viene erogato come credito per il consumo futuro, non come denaro. Nell’esempio di Hetzner, 185 minuti di fermo danno 142 minuti sopra la soglia, ossia 2,37 ore, e un credito di 0,87 €, che è meno di quanto costa un’ora di lavoro per calcolarlo. Il fatturato non recuperato, gli ordini persi e le posizioni cadute nei motori di ricerca non ci rientrano da nessuna parte, e nessun accordo di hosting che abbiamo letto li copre.

L’elenco delle eccezioni è altrettanto importante del numero, perché è proprio quello a decidere quanto spesso questo numero viene applicato: restano fuori dall’accordo la manutenzione preannunciata, il software e la configurazione del cliente, il cambio di piano richiesto dal cliente, le migrazioni a caldo per la stabilità della macchina host e la rete oltre la rete principale del fornitore. Tutto questo è scritto in modo onesto e aperto, e ne viene una cosa semplice: la percentuale riguarda la macchina, non il Suo sito, quindi un sito caduto dopo un aggiornamento andato male è del tutto fuori da questo contratto.

Inoltre il 99,9% non è una costante di settore, anche se spesso lo si usa come se lo fosse. L’accordo di Amazon EC2 per una singola istanza promette il 99,5%, e il 99,99% soltanto se le istanze sono collocate in almeno due zone di disponibilità, cioè sono due contratti diversi con due numeri diversi, e la frase «nel settore è il 99,9%» li appiattisce in uno. Nell’hosting condiviso un documento del genere di solito non c’è affatto — c’è solo un numero sul sito, senza definizione, senza metodo di misura e senza conseguenze, e quello è un’affermazione, non un impegno.

Come misurare il Suo sito prima di scegliere

Il numero che decide non è il numero di visitatori al mese, anche se è proprio quello che chi compra sa a memoria e proprio quello che il venditore chiede per primo. Decide il numero di richieste PHP contemporanee nel momento in cui il carico è più alto, ed è una grandezza del tutto diversa, che con il traffico mensile correla debolmente.

Due siti con lo stesso traffico possono trovarsi da parti opposte dello stesso limite, e la differenza sta in quanto tempo ciascuna pagina tiene un processo. Un sito aziendale statico, messo in cache, lo serve per lo più il server web senza PHP, quindi quasi non consuma entry processes e diecimila visitatori al mese non gli dicono nulla. Un e-commerce in cui ogni carrello, ogni accesso e ogni ritorno dal gateway di pagamento tiene il processo PHP due secondi può raggiungere lo stesso limite già a venti acquirenti contemporanei, ed è proprio per questo che nella prima ora di una campagna cadono proprio quei negozi che la campagna l’hanno pagata.

Insieme a questo numero conviene leggerne ancora tre, e tutti e tre sono disponibili senza l’aiuto di uno sviluppatore. Il primo è la dimensione del database e la query più lenta al suo interno, perché di solito è proprio quella la vera causa della lentezza, non la potenza della macchina. Il secondo è il numero di file nell’account, perché il limite di inode i siti con grandi librerie di media e con una casella di posta vecchia lo raggiungono all’improvviso e senza preavviso. Il terzo è ciò che il sito fa fuori dal browser — job cron, invio di posta, integrazioni con il sistema di contabilità — perché anche questi processi entrano nell’account dall’esterno e contano nello stesso limite che Lei ha appena misurato per gli acquirenti.

Tutti e quattro i numeri si leggono in un pomeriggio dalla statistica del pannello di hosting e dai log del server, ed è l’unico posto in cui sta il carico vero del Suo sito, non un’idea su di esso. Il nome del piano questi numeri non li conosce, il venditore che non li ha visti neanche, e una conversazione che parte da essi di solito finisce con una risposta più economica di una conversazione che parte da un elenco di piani.

Quando il passaggio aiuta e quando non risolve nulla

Il passaggio a un piano più grande è la risposta giusta assai più di rado di quanto venga offerto, e il primo caso in cui non aiuta è anche il più frequente. Se il sito è lento perché una query legge l’intera tabella dei prodotti a ogni apertura di pagina, allora una macchina più potente la eseguirà più in fretta, il problema resterà, e Lei avrà comprato del tempo, non una soluzione. Lo stesso vale per quaranta plugin, per immagini non elaborate a dimensione reale e per un tema che a ogni richiesta ricostruisce il menu da zero.

Il passaggio è la risposta giusta quando il limite è raggiunto con codice corretto: se il sito è in cache, le query sono a posto e l’account va ancora a sbattere contro il numero di entry processes, allora è un limite del piano, non un difetto nel codice, e non c’è più nulla da ottimizzare. Allo stesso modo il passaggio è l’unica risposta quando serve qualcosa che in un account condiviso non si può installare — un’altra versione PHP, un gestore di code, Redis, un cron proprio con passo di un minuto — o quando un requisito di settore, di gara o del cliente stabilisce in quale Paese i dati si trovano fisicamente.

C’è anche un terzo caso, di cui i venditori parlano di rado, perché riduce la fattura: a volte il movimento giusto è verso il basso. Un sito che tre anni fa è stato spostato su un VPS per una campagna pubblicitaria e da allora riceve duecento visitatori al giorno paga una macchina che non usa, e la paga due volte — con i soldi in fattura e con il tempo di una persona, perché il sistema operativo di un VPS qualcuno deve aggiornarlo anche quando lì non entra nessuno.

Prima di qualsiasi spostamento conviene risolvere ancora una questione, che con la potenza non c’entra per nulla: a nome di chi è registrato il dominio e a nome di chi è l’account di hosting. Ne abbiamo scritto a parte nell’articolo sugli errori da evitare nella realizzazione di un sito web, ed è una di quelle domande che il giorno della migrazione non si riparano più in fretta, perché la risposta dipende da una persona con cui Lei forse non parla più.

Che cosa compra, quando il piano si chiama hosting gestito

La differenza di prezzo tra una macchina non gestita e una gestita è grande, e non è un ricarico sulla stessa merce, quindi è onesto mettere i due numeri uno accanto all’altro. Nel listino Hetzner entrato in vigore il 15 giugno 2026, un server cloud CX23 con due vCPU, quattro gigabyte di memoria e 40 GB di disco costa 5,49 € al mese IVA esclusa, e l’indirizzo IPv4 principale gli si aggiunge per 0,50 € al mese. Il nostro hosting gestito e infrastruttura server parte da 45 € al mese, e la differenza tra questi due numeri è proprio l’argomento di queste righe.

La differenza è lavoro, e lo si può elencare pezzo per pezzo: aggiornamenti di sistema operativo e software del server, configurazione di sicurezza, monitoraggio con Zabbix 24 ore su 24 e reazione secondo SLA, backup ogni giorno con conservazione di 30 giorni e ripristino verificato con regolarità, e per un’infrastruttura particolarmente critica — fino a 365 giorni e in due Paesi diversi dell’Unione europea. La preparazione dell’ambiente e lo spostamento occupano 3–10 giorni, la migrazione la facciamo in parallelo e il DNS lo commutiamo in una finestra pianificata, e dopo Lei ha un unico referente responsabile, non un ticket di assistenza in un altro fuso orario.

Va detta con onestà anche l’altra faccia, perché senza di essa questa parte sarebbe un listino con un articolo intorno. Se il Suo sito è statico, il traffico è piccolo e nessuno chiede mai una versione PHP che il provider non ha, allora l’hosting condiviso per pochi euro al mese è la risposta giusta, e un ambiente gestito sarebbe un prezzo per una tranquillità che ha già. Lo diciamo anche a chi chiama con questa domanda, perché vendere un ambiente che non viene usato è un affare di breve periodo — dopo un anno torna come domanda su che cosa si è pagato davvero, e a quella non c’è una buona risposta.

Se non è sicuro da quale parte di questo confine sta il Suo sito, quei quattro numeri si possono leggere insieme: ci scriva, e Le diremo che cosa mostra la statistica del Suo account attuale e quale limite Le è più vicino — anche se la risposta risulta che non c’è alcun bisogno di spostarsi e i soldi conviene investirli nella velocità del sito.