Composer risolve le dipendenze, e questo richiede memoria e accesso alla rete: due cose scarse sull'hosting condiviso. Inoltre scarica codice direttamente su un server di produzione, che non è il posto in cui vuoi scoprire che un pacchetto è cambiato.

La forma migliore

Risolvi le dipendenze dove hai le risorse e spedisci il risultato. Così il server non esegue mai Composer.

# on your machine or in CI
composer install --no-dev --optimize-autoloader --classmap-authoritative
rsync -az --delete vendor/ user@server:/var/www/site/vendor/
  • --no-dev — i framework di test e i debugger non stanno in produzione.
  • --optimize-autoloader — una mappa delle classi al posto delle ricerche sul filesystem, e un guadagno di velocità misurabile.
  • --classmap-authoritative — nessuna chiamata stat di ripiego. Usalo solo quando nulla genera classi durante l'esecuzione.

Se proprio devi eseguirlo sul server

php -d memory_limit=-1 /usr/local/bin/composer install --no-dev --optimize-autoloader

L'ostacolo abituale è il limite di memoria. Alzarlo solo per quel comando ti evita di alzarlo per tutto il sito.

Metti nel repository il file di blocco, mai la cartella vendor

composer.lock sta in git: è ciò che rende identiche due installazioni. La cartella vendor no: gonfia il repository a dismisura e rende impossibili le fusioni.

Pubblica senza finestre rotte

Copiare i file in una cartella in servizio significa che alcune richieste vedono metà del codice nuovo. Costruisci in una cartella nuova e sposta un collegamento simbolico, così il cambiamento è tutto d'un pezzo.

ln -sfn /var/www/releases/2026-09-05 /var/www/current
sudo systemctl reload php8.3-fpm       # clear the opcache of the old paths
Ricarica PHP-FPM dopo una pubblicazione, altrimenti opcache continuerà a servire il codice precedente dalla memoria — vedi Cosa tiene in cache opcache.