1 22/10/2026 12 min

Magento 2 su hosting: prima scegli lo stack giusto

Magento 2 non è un CMS leggero da “caricare e via”. Se lo tratti come un sito PHP qualunque, finisci quasi sempre con problemi di memoria, timeout, permessi e cache che non tengono. La differenza la fa lo stack: PHP compatibile, database ben dimensionato, web server configurato correttamente e un hosting che non strozza CPU e I/O proprio quando il catalogo cresce.

Se il tuo obiettivo è installarlo su hosting condiviso, la domanda vera non è “si può fare?”, ma “ci sono le condizioni minime per farlo restare stabile?”. Per una installazione pulita servono accesso SSH, Composer, estensioni PHP corrette, possibilità di impostare cron e un database MySQL/MariaDB affidabile. Senza questi elementi, l’installazione può anche partire, ma l’operatività quotidiana diventa fragile.

In questa guida parto da un caso realistico: hosting Linux con accesso SSH, document root dedicata, PHP-FPM o handler equivalente, database separato o locale al piano hosting, e dominio già puntato sullo spazio corretto. Se manca uno di questi pezzi, lo segnalo nei punti giusti e ti dico come chiudere il gap.

Requisiti minimi da verificare prima di toccare il codice

Magento 2 è sensibile alla versione PHP, alle estensioni e alla memoria disponibile. Prima di installare, verifica tre cose: compatibilità del runtime, accesso ai tool da riga di comando e spazio su disco sufficiente per vendor, media, cache e log.

  1. Versione PHP: usa una release supportata dalla tua versione di Magento. Su installazioni recenti, in pratica, conviene stare su PHP 8.1 o 8.2 se il pacchetto Magento lo consente.
  2. Estensioni PHP: in genere servono intl, mbstring, soap, xml, curl, gd, zip, bcmath, openssl, pdo_mysql, dom, simplexml, iconv.
  3. Memoria e timeout: per l’installazione e per l’uso reale, 2 GB di RAM sono il minimo teorico; 4 GB sono più sensati se il catalogo cresce o se il piano hosting è condiviso ma ben dimensionato.

Un controllo rapido lato shell ti evita di scoprire i problemi a metà installazione:

php -v
php -m | egrep 'intl|mbstring|soap|xml|curl|gd|zip|bcmath|openssl|pdo_mysql'
php -i | egrep 'memory_limit|max_execution_time|upload_max_filesize|post_max_size'

Se una o più estensioni mancano, non si forza nulla: si passa dal pannello hosting o si chiede al provider l’abilitazione del modulo corretto. Su molti pannelli, la strada più pulita è la selezione della versione PHP con le estensioni attive nel profilo del dominio. Se il pannello non espone il dettaglio, verifica la pagina “PHP Selector”, “MultiPHP Manager” o equivalente.

Preparare dominio, document root e database senza lasciare margini ambigui

Magento 2 deve stare in una directory dedicata, non nella root del dominio con altri file sparsi. L’obiettivo è avere una struttura pulita, facile da aggiornare e semplice da proteggere. Se il pannello hosting consente di impostare la document root del dominio, puntala alla cartella corretta del progetto, di solito qualcosa come /home/utente/public_html/magento oppure una sottocartella dedicata se il provider impone una struttura propria.

Il database va creato prima dell’installazione, con utente dedicato e privilegi limitati al solo schema dell’applicazione. Evita account condivisi con altri siti. Se il provider offre phpMyAdmin o un database manager nel pannello, usa quello solo per la creazione iniziale; poi lavora via CLI quando serve consistenza.

  1. Crea un database, ad esempio magento_prod.
  2. Crea un utente dedicato, ad esempio magento_user.
  3. Assegna all’utente tutti i privilegi solo sul database di Magento, non globali.
  4. Annota host database, porta, nome DB, utente e password in modo sicuro, senza salvarli in chiaro in file condivisi.

Se il database è su un host remoto, verifica la raggiungibilità prima di proseguire:

mysql -h DB_HOST -u magento_user -p -e 'SELECT VERSION();'

Se il comando fallisce, non è ancora un problema di Magento: è un problema di rete, credenziali o firewall. A quel punto la correzione va fatta sul layer database, non nel codice dell’applicazione.

Installazione dei file: Composer, repository e permessi corretti

La via più pulita è installare Magento con Composer. Questo vale ancora di più su hosting dove la gestione dei pacchetti deve essere ripetibile. Evita upload manuali di archivi “già pronti” se hai accesso SSH: ti complichi gli aggiornamenti e perdi controllo sulle dipendenze.

Prima di lanciare Composer, verifica che l’utente shell sia quello corretto e che la directory di destinazione sia vuota o comunque dedicata al progetto. Una cartella sporca con residui di installazioni precedenti è una delle cause più banali di errori ambigui durante il setup.

Esempio di installazione base con Composer, da adattare alla versione di Magento che vuoi deployare:

cd /home/utente/public_html
composer create-project --repository-url=https://repo.magento.com/ magento/project-community-edition magento2

Per l’accesso al repository Magento servono le chiavi di autenticazione fornite dal tuo account Adobe/Magento. Non vanno mai lasciate in chiaro dentro documenti condivisi o repository Git. Se devi configurarle, usa l’auth di Composer nel profilo utente o in un file controllato con permessi stretti.

Una volta scaricati i file, controlla i permessi. L’installazione non deve essere scrivibile dal web server in modo indiscriminato. La regola pratica è semplice: il processo di deploy scrive dove serve, il runtime legge e scrive solo in directory specifiche come var, pub/static, pub/media e, in alcuni casi, generated.

Se il provider usa PHP-FPM con utente separato per sito, allinea proprietario e gruppo alle direttive del piano hosting. Se invece hai un hosting più tradizionale, verifica che il web server possa leggere i file senza rendere l’intero progetto world-writable. Il classico errore è risolvere tutto con chmod 777: funziona solo per nascondere un problema di ownership e apre un buco inutile.

Configura Magento con setup:upgrade e parametri database

Quando i file sono al posto giusto, l’installazione vera parte dalla CLI. Qui Magento costruisce la configurazione iniziale, scrive il file di sistema e prepara lo schema del database. Il comando va eseguito dalla root del progetto.

bin/magento setup:install \ --base-url=https://www.esempio.it/ \ --db-host=localhost \ --db-name=magento_prod \ --db-user=magento_user \ --db-password='PASSWORD_FORTE' \ --admin-firstname=Admin \ --admin-lastname=Store \ --admin-email=admin@esempio.it \ --admin-user=admin \ --admin-password='ALTRA_PASSWORD_FORTE' \ --language=it_IT \ --currency=EUR \ --timezone=Europe/Rome \ --use-rewrites=1

Se il database non è locale, sostituisci localhost con l’host corretto. Se il tuo hosting richiede una porta diversa, aggiungila in modo esplicito. In caso di errore, il primo controllo da fare è il log del setup e non il browser: il problema spesso è già scritto nella console.

Se il comando termina bene, troverai il file di configurazione generato e lo schema inizializzato nel database. Se fallisce, i colpevoli più comuni sono questi: estensione PHP mancante, memoria insufficiente, credenziali errate, database non raggiungibile o URL base non coerente con il dominio effettivo.

Controlla anche il file app/etc/env.php: contiene parametri sensibili come accesso al database e chiavi di configurazione. Va protetto con permessi stretti e non va esposto via web. Se il tuo hosting permette regole di protezione extra, blocca l’accesso diretto a questa area con una regola del server o tramite configurazione del pannello.

Web server: document root, rewrite e blocco dell’accesso alle aree sensibili

Magento 2 espone pubblicamente solo la cartella pub. Questo dettaglio è fondamentale. Se punti la document root alla root del progetto, stai esponendo file che non dovrebbero essere serviti direttamente. La configurazione corretta del virtual host o del dominio deve quindi indirizzare il traffico verso pub.

Se hai accesso al virtual host Apache, la logica è questa: document root verso /path/to/magento/pub, mod_rewrite attivo e regole standard di Magento. Su Nginx, serve un blocco server con rewrite adeguato e gestione esplicita dei file statici. L’obiettivo è evitare 404 sui contenuti e mantenere i rewrite puliti per le URL amichevoli.

Esempio di direttiva concettuale per Apache:

DocumentRoot /home/utente/public_html/magento2/pub
<Directory /home/utente/public_html/magento2/pub> AllowOverride All Require all granted
</Directory>

Se usi un pannello hosting, cerca l’impostazione “document root” del dominio o della sottodirectory. Molti problemi di homepage bianca o 404 su Magento nascono da un puntamento errato, non dal codice. Una verifica rapida è aprire il browser e controllare che la root del sito non mostri un indice di directory o file fuori posto.

Un controllo semplice via CLI aiuta a capire se il rewrite è funzionante:

curl -I https://www.esempio.it/
curl -I https://www.esempio.it/static/frontend/

Se ricevi 200 o 301 coerenti, sei nella direzione giusta. Se vedi 403, 404 o redirect ciclici, il problema è quasi sempre nel vhost, nel rewrite o nella base URL configurata in Magento.

Cron, cache e indicizzazione: il punto in cui molte installazioni si rompono

Magento senza cron è un sistema zoppo. Anche quando il frontend sembra funzionare, in background restano fermi indicizzazione, email transazionali, pulizia cache e processi programmati. Su hosting condiviso, l’assenza del cron è spesso il motivo per cui il sito “funziona ma non si aggiorna”.

Installa i cron job dell’utente corretto e verifica che il provider li esegua davvero. Il comando standard è questo:

bin/magento cron:install

Poi controlla il crontab e gli output generati. Se il pannello hosting offre un gestore cron grafico, puoi usarlo, ma devi comunque verificare che il percorso al binario PHP sia corretto e che il progetto punti al path giusto. Un errore comune è usare una versione di PHP diversa da quella del sito: il cron parte, ma Magento va in errore silenzioso o con log incompleti.

La cache va gestita con criterio. Non disabilitarla per “vedere subito le modifiche” se il sito è già in produzione. Piuttosto, lavora con i comandi Magento e con gli strumenti del pannello quando serve svuotare solo ciò che è necessario.

bin/magento cache:status
bin/magento cache:flush

Se il catalogo è grande o il traffico sale, valuta una cache backend più solida e un layer di accelerazione esterno, ma questa è una fase successiva. Per l’installazione base, basta che il sistema sia coerente e che i cron partano regolarmente.

Permessi, ownership e file sensibili: il minimo indispensabile per non aprire falle inutili

Magento scrive in alcune directory specifiche e legge moltissimo dal resto del filesystem. Questo significa che i permessi devono essere restrittivi ma funzionali. La soluzione più robusta è distinguere chiaramente tra file del codice, directory scrivibili dall’applicazione e file di configurazione sensibili.

  1. Proteggi app/etc/env.php con permessi stretti.
  2. Lascia scrivibili solo le directory richieste da Magento.
  3. Evita permessi globali e ownership mista tra più utenti se non hai una ragione tecnica precisa.
  4. Se il provider usa policy particolari, adeguati al modello del piano invece di forzare workaround.

Per una verifica rapida dei file più delicati, controlla che non siano leggibili da utenti esterni al dominio se la tua piattaforma consente separazione degli account. Se hai accesso SSH, un controllo utile è:

ls -l app/etc/env.php
find var pub/static pub/media generated -maxdepth 1 -type d -print

La regola pratica è semplice: se un file contiene credenziali, chiavi o configurazioni sensibili, deve essere trattato come materiale operativo, non come contenuto pubblico. In caso di dubbio, restringi, testa e allarga solo se emerge un requisito reale.

Primo avvio: cosa controllare quando il sito non risponde come previsto

Il primo accesso al frontend e al pannello amministrativo non è solo una verifica visiva. Devi controllare che il layer HTTP risponda in modo coerente, che le URL siano corrette, che il backend non mostri errori PHP e che il pannello admin sia raggiungibile senza loop di redirect.

  1. Apri la homepage e verifica status code e contenuto.
  2. Apri il pannello admin con l’URL generato durante l’installazione.
  3. Controlla i log di Magento in var/log.
  4. Verifica che il database abbia tabelle create e che il cron stia girando.

Se il sito mostra pagina bianca, il primo sospetto è quasi sempre PHP: memory limit troppo basso, estensione mancante o errore fatale non mostrato a schermo. I log da guardare sono quelli applicativi, non solo quelli del web server. Su un hosting tipico, cerca in var/log/system.log e var/log/exception.log, oltre ai log di Apache o Nginx messi a disposizione dal pannello.

Se il pannello admin non accetta il login, verifica l’URL base, la cache del browser, eventuali regole di sicurezza del provider e lo stato della sessione. In certi casi il problema è banale: il sito è installato su un dominio, ma l’admin è stato aperto con un indirizzo diverso, magari senza HTTPS o con una sottodirectory sbagliata.

Quando l’hosting condiviso non basta più

Ci sono installazioni che su hosting condiviso partono bene e poi si fermano non appena aumentano prodotti, immagini, visite o integrazioni. I segnali sono abbastanza chiari: TTFB alto, errori 503 sotto carico, cron che accumula ritardi, cache che non si rigenera in tempo, import catalogo che falliscono per timeout.

Se arrivi qui, non serve forzare ulteriormente il piano. Ha più senso valutare un VPS ben dimensionato o un hosting gestito specifico per Magento con risorse garantite, filesystem più veloce e possibilità di configurare worker, cache esterne e tuning del database. Il costo reale di un hosting troppo stretto è il tempo perso a inseguire sintomi che nascono da limiti strutturali, non dal codice del negozio.

In sintesi operativa: se il tuo hosting ti consente accesso SSH, Composer, cron affidabili, database stabile e configurazione corretta del web server, Magento 2 si installa in modo pulito. Se uno di questi pezzi manca, la guida non cambia: cambia la piattaforma.