Hosting PrestaShop: requisiti e configurazione server

L'hosting è il pavimento su cui poggia il Suo negozio

Abbiamo fatto girare PrestaShop praticamente su ogni fascia di hosting che esista: economici spazi condivisi cPanel ereditati dai clienti, VPS su Hetzner e OVH, macchine dedicate nei datacenter e il TrueNAS dell'ufficio che ospita mypresta.rocks stesso. Dopo oltre dieci anni di questo lavoro, la nostra posizione è semplice, nessuna quantità di caching, ottimizzazione delle immagini o messa a punto dei moduli salverà un negozio bloccato su un hosting sottodimensionato o configurato male. Sistema prima il pavimento, poi tutto ciò che ci sta sopra diventa più facile.

Questa pagina è volutamente schierata. È quello che faremmo leggere a un cliente che chiede "su cosa dovrei fare l'hosting?" prima che firmi qualsiasi cosa.

Tipi di hosting, nell'ordine in cui sono davvero appropriati

Hosting condiviso economico (circa 3-15 $/mese)

Il tuo negozio condivide un server con centinaia di altri. Ricevi cPanel o DirectAdmin, una configurazione PHP bloccata e nessun accesso root. I migliori (li abbiamo visti) ti permettono di scegliere un PHP recente, abilitare OPcache e non saturano i dischi vendendo più spazio del disponibile. I peggiori fanno esattamente il contrario.

Cosa ottieni: bolletta mensile bassa, email inclusa, qualcun altro applica le patch al sistema operativo.
A cosa rinunci: vicini rumorosi che fanno crollare i tempi di risposta in modo casuale, niente SSH sui piani base, niente Redis, niente Varnish, versioni di PHP che non scegli tu e un IP condiviso che un altro inquilino può far finire in blacklist al posto tuo.

Va bene per un negozio nuovissimo con meno di 500 prodotti, traffico basso e nessuna pressione temporale per ottimizzare. Non va bene per qualunque cosa tu stia cercando di far crescere.

VPS (gestito o non gestito, 5-60 $/mese)

RAM dedicata, CPU dedicata, disco dedicato, accesso root. È qui che vive la maggior parte dei negozi dei nostri clienti, ed è qui che metteremmo il tuo.

VPS gestito: il provider applica le patch al sistema operativo e gestisce gli aggiornamenti di sicurezza. Tu gestisci PrestaShop. Un pannello di controllo o un servizio gestito di solito aggiunge 5-20 $/mese al prezzo grezzo del VPS.
VPS non gestito: una macchina Debian o Ubuntu vuota con SSH. Più economica, ma sei tu a possedere ogni riga di configurazione di nginx e ogni aggiornamento del kernel.

Per il 90% dei negozi che tocchiamo, un VPS gestito nella fascia 15-30 $/mese supera l'hosting condiviso in ogni dimensione che conta.

Server dedicato (80-300+ $/mese)

Un'intera macchina fisica, senza il sovraccarico dell'hypervisor. Eccessivo per un negozio con 2.000 prodotti. La scelta giusta quando superi i 50.000 prodotti con traffico serio. È lì che spostiamo i clienti dal cloud VPS a qualcosa come un dedicato Hetzner, perché il rapporto prezzo-prestazioni diventa ridicolo a tuo favore.

Cloud VPS

Fatturazione a ore, provisioning rapido, snapshot, un'API. 2GB / 2 vCPU si colloca nella fascia 5-15 $/mese tra i provider che vale la pena usare, e i provider con sede nell'UE battono regolarmente quelli statunitensi per specifiche equivalenti.

Hosting "PrestaShop gestito"

Macchine preconfigurate con supporto specifico per PS. La proposta è allettante se non hai mai messo mano a un server. La realtà è che di solito si tratta di infrastruttura rivenduta con un ricarico, e il supporto conosce il pannello di controllo del negozio, non i tuoi moduli specifici.

L'hosting PS gestito si ripaga quando davvero non hai alcuna voglia di imparare un server. Per tutti gli altri, un VPS gestito con uno stack LEMP sensato rende di più e costa meno.

Requisiti minimi, per versione di PrestaShop

PrestaShop 1.7

PHP: 7.1-7.4 • MySQL: 5.5+ (5.7 consigliato) • RAM: 2GB minimo, 4GB sensato
Estensioni: curl, gd, intl, mbstring, zip, xml, json, openssl

PrestaShop 8.x

PHP: 7.2-8.1 (8.1 è quella su cui distribuiamo) • MySQL: 5.6+ • RAM: 4GB minimo
Estensioni: l'elenco di 1.7 più fileinfo e iconv

PrestaShop 9.x

PHP: 8.1-8.4 (in produzione usiamo 8.2) • MySQL: 8.0+ o MariaDB 10.5+ • RAM: 4GB minimo, 8GB se hai traffico reale
Estensioni: l'elenco di 8.x, con i requisiti di Symfony 6.4 che si applicano in aggiunta

Considera questi numeri come "il negozio si installerà", non come "il negozio renderà". La riga Starter da 2GB qui sotto si applica ai piccoli negozi PrestaShop 1.7; per PrestaShop 8 o 9 utilizza almeno 4GB. Un catalogo di 5.000 prodotti con 50 moduli e traffico reale vuole 4-8GB di RAM indipendentemente da quale versione sia sul pavimento.

Schermata Informazioni del pannello di amministrazione PrestaShop con configurazione PHP, MySQL e server

Guida al dimensionamento

Dimensione negozio	Prodotti	Visitatori giornalieri	RAM	CPU	Disco
Starter	<500	<200	2GB	1 core	20GB SSD
Piccolo	500-2K	200-1K	4GB	2 core	40GB SSD
Medio	2K-10K	1K-5K	8GB	4 core	80GB SSD
Grande	10K+	5K+	16GB+	4-8 core	160GB+ SSD

Un promemoria sul disco: 5.000 prodotti con 5 immagini ciascuno, rigenerate attraverso 7 tipi di immagine di PrestaShop, consumano 10-20GB prima ancora che tu abbia aggiunto qualsiasi altra cosa. Pianifica il disco di conseguenza.

Cosa fa davvero la differenza

Ogni host pubblicizza core, RAM e banda. Nella nostra esperienza, ecco l'ordine in cui le cose contano davvero.

1. Versione di PHP e OPcache

PHP 8.1 è circa il 20-40% più veloce di 7.4 sullo stesso codice, e OPcache si rivela il guadagno maggiore in aggiunta a questo. Senza OPcache, PrestaShop ricompila centinaia di file PHP a ogni richiesta. Con esso, il bytecode compilato arriva direttamente dalla memoria.

opcache.enable=1
opcache.memory_consumption=256
opcache.max_accelerated_files=20000
opcache.validate_timestamps=1
opcache.revalidate_freq=60

Se un host non ti permette di abilitare OPcache, o serve ancora PHP 7.x nel 2026, vattene. Non c'è alcun vantaggio.

2. I/O del disco: SSD o NVMe, mai dischi meccanici

PrestaShop legge centinaia di file per pagina. La lettura casuale di un HDD si colloca intorno ai 5-15ms, quella di un SSD a 0,1ms. Già solo questo fa una differenza di 3 volte nel tempo reale di pagina. Non distribuiremo un negozio su HDD. Nemmeno tu dovresti.

3. Configurazione di MySQL

Una tipica pagina PS lancia 100-300 query. L'unica impostazione che conta di più è innodb_buffer_pool_size, controlla quanta parte dei tuoi dati risiede nella RAM. Dal 50 al 70% della RAM totale su un server di database dedicato, dal 25 al 40% su una macchina combinata app+DB. Prima di mettere a punto un database gonfio, usa Database Cleanup o controlli SQL equivalenti per ridurre carrelli abbandonati, log e statistiche obsolete.

4. RAM

Ogni worker PHP-FPM usa 30-80MB di memoria residente. Dieci worker significano 300-800MB solo per PHP, poi aggiungi MySQL, Redis, OPcache stesso e il sistema operativo. 2GB sono stretti prima ancora che tu abbia servito una singola richiesta.

5. HTTP/2

Multiplexa tutto su una singola connessione. Dal 20 al 40% più veloce su pagine che caricano 60-80 asset, che sono la maggior parte delle pagine PrestaShop. Richiede HTTPS, di cui avevi comunque bisogno.

Hosting condiviso: i muri contro cui sbatterà

Il condiviso può funzionare per i negozi più piccoli, ma incapperai in questi problemi all'incirca in quest'ordine:

Niente SSH. Non puoi eseguire Composer da CLI, comandi della console o nessuno degli script di pulizia su cui normalmente ci appoggeremmo.
Limiti sul cron. Molti host condivisi limitano il cron a ogni 15 minuti. La manutenzione di PrestaShop ne vuole di più.
memory_limit limitato. 128-256MB è normale sui piani economici. Le importazioni grandi falliscono silenziosamente quando lo raggiungono.
Niente Redis. Sei bloccato sul caching su filesystem, su storage condiviso che è già impegnato.
IP condiviso. L'abitudine allo spam di un vicino mette il tuo IP in blacklist, e le email di conferma d'ordine smettono di arrivare. Trattiamo la soluzione nella nostra guida sulla deliverability delle email.

Se intendi comunque cercare un condiviso, dai priorità all'accesso SSH, a un pannello di controllo che ti permetta di scegliere la versione di PHP, al supporto per OPcache e a un limite di memoria che tu possa aumentare. E leggi sempre il prezzo di rinnovo. Il numero introduttivo è marketing.

2,99 $/mese si rinnova a 10,99 $ un anno dopo. Ogni sito di recensioni sul condiviso economico glissa su questo. Noi no.

VPS: la scelta giusta per la maggior parte dei negozi

Perché finiamo sempre qui

Accesso root. Installa Redis, Varnish, l'intero stack.
CPU e RAM dedicate. Nessun vicino da incolpare alle 14 del Black Friday.
Controllo completo di PHP-FPM e OPcache.
SSH e cron senza restrizioni.
nginx, non Apache, a meno che tu non scelga diversamente.
Snapshot prima degli aggiornamenti rischiosi: tre clic per tornare indietro.

Cosa controllare davvero prima di iscriversi

Storage SSD o NVMe. Se la scheda tecnica non lo dice, presumi HDD e passa oltre.
Prezzo equo. 2GB / 2 vCPU a 5-15 $/mese è normale. 30 $ è pagare troppo.
Posizione del datacenter. I negozi UE vogliono datacenter UE. La latenza è reale, il GDPR lo è ancora di più.
Snapshot economici. L'unica funzione che si ripaga la prima volta che l'aggiornamento di un modulo va storto.
Documentazione. Passerai del tempo sulla loro documentazione. Se è scarna, questo ti dice qualcosa.

Se non hai mai gestito una macchina Linux, paga il sovrapprezzo per il servizio gestito o per un pannello di controllo. Un VPS configurato male supererà l'hosting condiviso nei benchmark e renderà meno nella vita reale perché nessuno ha applicato le patch al kernel.

Base dello stack LEMP

# Debian 12 / Ubuntu 22.04
apt install nginx php8.2-fpm php8.2-mysql php8.2-curl \\
    php8.2-gd php8.2-intl php8.2-mbstring php8.2-xml \\
    php8.2-zip php8.2-opcache mariadb-server redis-server -y
mysql_secure_installation

Non hai mai gestito un server Linux? Inizia con un VPS gestito o un pannello. Un VPS fai-da-te rotto è peggio dell'hosting condiviso. La nostra guida al rafforzamento della sicurezza copre cosa blindare dopo che è operativo.

Dedicato e cloud: quando il VPS non basta

Sali di livello quando hai 50K+ prodotti, 5K+ visitatori giornalieri sostenuti, un multistore con cinque o più negozi che condividono la macchina, o un vero requisito di uptime al 99,99%.

Una macchina dedicata da 64GB / NVMe di un provider europeo può arrivare a 40-60 EUR/mese, più capacità di quanta la maggior parte dei negozi userà mai, ma il divario prezzo-prestazioni rispetto a un cloud VPS della stessa specifica è difficile da contestare.

L'ordine di scalata, quando hai davvero bisogno di scalare: prima sposta MySQL sul suo server (il salto singolo più grande), poi metti Redis su una propria istanza, poi pensa a un bilanciatore di carico con più server applicativi, e a quel punto ti servono anche storage condiviso e sessioni su Redis, quindi non saltare avanti.

Configurazione del server per PrestaShop

nginx, non Apache

Apache è l'impostazione predefinita perché lo usa l'hosting condiviso, non perché sia la scelta migliore. nginx usa un I/O guidato dagli eventi (10-30MB per processo contro 300-800MB per il prefork di Apache), serve file statici senza passare per PHP e include una cache FastCGI già pronta.

Se sei vincolato ad Apache, usa mpm_event con PHP-FPM, mai mpm_prefork con mod_php. Quest'ultimo è la distribuzione PrestaShop più lenta che abbiamo visto sul campo.

Impostazioni di PHP-FPM

pm = dynamic
pm.max_children = 20
pm.start_servers = 5
pm.min_spare_servers = 3
pm.max_spare_servers = 10
pm.max_requests = 500
php_admin_value[memory_limit] = 512M
php_admin_value[max_execution_time] = 300

La formula che usiamo per pm.max_children: (RAM in MB - impronta di MySQL - SO) / 50MB per worker. Su una macchina da 4GB: (4000 - 1500 - 500) / 50 = 40. Impostiamo 20-30 per lasciare un margine, perché un pool FPM saturo significa errori 502 in faccia al cliente.

Messa a punto di MySQL

[mysqld]
innodb_buffer_pool_size = 2G
innodb_log_file_size = 256M
innodb_flush_log_at_trx_commit = 2
tmp_table_size = 64M
max_heap_table_size = 64M
slow_query_log = 1
long_query_time = 1

Attiva il log delle query lente il primo giorno. Una singola query difettosa che gira 200 volte per pagina batte qualsiasi diagnosi di "server lento" che abbiamo mai fatto, e il log è il modo in cui la trovi. La nostra guida alle prestazioni illustra cosa fare una volta individuati i colpevoli.

Redis per sessioni e cache

PrestaShop mette sessioni e cache su disco per impostazione predefinita. Sposta entrambe su Redis e le pagine dell'amministrazione smettono di bloccarsi sul lock delle sessioni su filesystem, che è la singola causa più comune dei ticket "il pannello di amministrazione è lentissimo" che apriamo. Redis ti costa 50-100MB di RAM e li ripaga immediatamente.

SSL/TLS: non opzionale

Ogni negozio ha bisogno di HTTPS. Google penalizza l'HTTP nel posizionamento, i browser lo mettono alla berlina e nessun fornitore di pagamenti funzionerà senza. La discussione è chiusa.

Let's Encrypt

Gratuito, automatico, rinnovo a 90 giorni. Certbot lo installi una volta e poi te ne dimentichi:

apt install certbot python3-certbot-nginx -y
certbot --nginx -d yourshop.com -d www.yourshop.com

Cloudflare SSL

Gratuito tramite il loro proxy, con un'insidia: usa sempre Full (Strict). La modalità Flexible invia testo in chiaro tra Cloudflare e la tua origine, il che vanifica tutto lo scopo. Imposta X-Forwarded-Proto in modo che PrestaShop sappia di essere dietro HTTPS; con Full (Strict), anche la connessione da Cloudflare alla tua origine usa HTTPS.

Forzare HTTPS

Abilita in Parametri del negozio → Generale, poi aggiungi il reindirizzamento del server:

# Nginx
server {
    listen 80;
    server_name yourshop.com;
    return 301 https://yourshop.com$request_uri;
}

# Apache (.htaccess)
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

CDN: quando e come

Se servi una sola regione da un server locale, la CDN non ti compra molta velocità. Ciò che ti compra è il caching degli asset statici e uno strato anti-DDoS gratuito.

Il piano gratuito di Cloudflare copre la maggior parte dei negozi: CDN globale, SSL gratuito, DDoS di base, HTTP/2, Brotli. Collegalo in Parametri avanzati → Prestazioni → Server multimediali.

Metti in cache in modo aggressivo: immagini, CSS, JS, font.
Non mettere mai in cache: amministrazione, carrello, checkout, area cliente, qualsiasi cosa che tocchi un cookie di PrestaShop.

Non attivare mai "Cache Everything" per l'intero dominio. L'abbiamo visto: un cliente vede il carrello di un altro cliente perché il checkout è stato messo in cache al margine. Metti in cache solo gli asset statici e i pattern di URL nominati.

Backup: gli snapshot dell'host non sono una strategia

I backup del provider sono di solito settimanali, girano sulla stessa infrastruttura e hanno una probabilità non nulla di non ripristinarsi quando ne hai bisogno. Sono una coperta di Linus. Se il provider passa una brutta notte, i backup se ne vanno con il negozio. Se un ransomware cifra i tuoi file, le versioni cifrate vengono diligentemente messe in backup. E probabilmente vuoi un database di due ore fa, non di martedì scorso.

Quello che vuoi, come minimo: dump giornalieri automatici del DB più backup dei file, conservati fuori dal server di produzione, mantenuti per 30 giorni, con un test di ripristino ogni mese. Pianifica quei lavori in un posto visibile; MPR Cron Manager è l'opzione lato PrestaShop quando vuoi che le attività di backup siano tracciate invece che nascoste in righe anonime di crontab. La nostra guida ai backup contiene la procedura operativa.

Migrazione tra host

Predisponi il nuovo server con la stessa versione di PHP e le stesse estensioni.
Esegui il dump del database: mysqldump -u root -p prestashop_db | gzip > backup.sql.gz
Sincronizza i file: rsync -avz /var/www/html/prestashop/ newserver:/var/www/html/prestashop/
Importa il database sul nuovo server.
Aggiorna le credenziali in app/config/parameters.php.
Correggi i permessi: chown -R www-data:www-data, directory 755, file 644.
Svuota la cache: rm -rf var/cache/*
Testa tramite /etc/hosts: punta il tuo portatile al nuovo IP e percorri checkout e amministrazione prima di chiunque altro.
Abbassa il TTL del DNS a 300 secondi 24 ore prima della commutazione.
Sincronizzazione finale del DB subito prima di cambiare il DNS, così gli ultimi ordini non vanno persi.

Dove le migrazioni vanno storte

Proprietà dei file. L'utente web deve possedere i file. Cache, img, upload, download devono essere tutti scrivibili.
.htaccess mancante. Le GUI di migrazione adorano saltare i file nascosti. Apache ha anche bisogno di AllowOverride All per rispettarlo.
Mancata corrispondenza dell'URL di base. Se il dominio è cambiato, aggiorna ps_shop_url o ogni link si rompe.
Salto di versione di PHP. Passare da 7.4 a 8.1 rompe qualsiasi modulo che chiami ancora funzioni deprecate.

Non cambiare mai il DNS prima di aver testato tramite /etc/hosts. Abbiamo visto due migrazioni rompere il checkout in produzione perché nessuno aveva cliccato "compra" sul nuovo server per primo.

Segnali d'allarme: se ne vada quando vede questi

Tecnici

Niente SSH. Non puoi distribuire, non puoi fare il debug, non puoi eseguire nessuno degli strumenti che risolvono davvero i problemi.
PHP 7.x nel 2026. Fine vita. Vulnerabilità note che non verranno corrette.
Niente OPcache. Da 3 a 5 volte più lento dello stesso codice con OPcache attivo. Non c'è ragione per farlo.
Storage HDD. Se non dicono SSD o NVMe per iscritto, presumi HDD.
php.ini bloccato. Non puoi far girare PrestaShop correttamente senza alzare almeno memory_limit.

Commerciali

"Illimitato" qualsiasi cosa. Niente è illimitato. Limitano gli inquilini rumorosi invece di dirlo.
Marchi di holding. Cinque host "diversi" posseduti dalla stessa casa madre, tutti sulla stessa latta sovravenduta, loghi diversi.
Nessuno SLA di uptime. Non si fidano abbastanza della propria infrastruttura da metterci un numero.
Il supporto risponde in giorni. Un'interruzione alle 2 di notte ha bisogno di minuti, non di "il prossimo giorno lavorativo".
Fatturazione annuale forzata. Contano sul fatto che non te ne andrai quando ti renderai conto che è stato un errore.

L'hosting più economico è quello che resta in piedi durante il Black Friday. Risparmiare 5 $/mese su un host che ti fa perdere 5.000 $ di conversioni in un fine settimana non è risparmiare nulla.

Lista di controllo pre-acquisto

Ogni riga qui conta. Spuntale prima di mettere una carta.

Server

La versione di PHP corrisponde alla tua versione di PrestaShop
Tutte le estensioni PHP richieste disponibili (intl, mbstring, gd come minimo)
php.ini è configurabile (memory_limit, impostazioni di OPcache)
MySQL o MariaDB a una versione che PrestaShop supporta davvero
SSD o NVMe per iscritto
Accesso SSH
Frequenza del cron senza restrizioni

Prestazioni

OPcache abilitato e configurabile
4GB+ di RAM sul piano che stai scegliendo, oppure 2GB per un piccolo negozio PrestaShop 1.7 agli inizi
HTTP/2 abilitato
Redis o Memcached disponibile

Affidabilità

SLA di uptime del 99,9% o migliore
Opzioni di backup automatiche e manuali
Tempo di risposta del supporto critico misurato in ore, non in giorni
Datacenter vicino ai tuoi clienti

Prezzo

Prezzo di rinnovo (non prezzo introduttivo) verificato
Fatturazione mensile disponibile
Limiti di banda o di traffico compresi
Nessuna clausola che ti impedisca di migrare altrove

Cosa Le faremmo usare, per fase

Negozio nuovissimo: Cloud VPS con almeno 4GB di RAM per PrestaShop 8 o 9, oppure 2GB per un piccolo negozio PrestaShop 1.7, più una CDN gratuita e Let's Encrypt. Batte di gran lunga la maggior parte dei condivisi da 15 $/mese.
Negozio in crescita: VPS gestito a 15-30 $/mese. Paga qualcuno per tenere il sistema operativo aggiornato mentre tu ti concentri sul vendere.
Affermato (1K+ visitatori al giorno): VPS con 8-16GB di RAM, MariaDB messa a punto, Redis attivo, nginx con cache FastCGI. 15-40 $/mese ti portano lì.
Catalogo grande o traffico intenso: Server dedicato (un dedicato europeo economico supera un cloud VPS a questa scala) o un'architettura cloud opportunamente separata. 50-100+ $/mese e vale ogni centesimo.

Imposta il monitoraggio dell'uptime il primo giorno. UptimeRobot è gratuito per 50 monitor e abbastanza buono. Una volta sistemato l'hosting, il resto del lavoro di ottimizzazione ha un posto solido su cui atterrare.

Letture correlate

Ottimizzazione delle prestazioni PrestaShop: velocizzare il Suo negozio: cosa mettere a punto una volta sistemato l'hosting
Rafforzamento della sicurezza PrestaShop: la lista di controllo completa: blindatura a livello di server
Risoluzione dei problemi PrestaShop: correggere schermate bianche ed errori 500: quando il problema è l'host e devi dimostrarlo
Backup PrestaShop: backup reali, non coperte di sicurezza: la procedura operativa che usiamo noi stessi
Performance Revolution: uno dei nostri moduli; si abbina bene a un VPS opportunamente dimensionato