Composer résout des dépendances, ce qui demande de la mémoire et un accès réseau — deux choses limitées en mutualisé. Il télécharge aussi du code directement sur un serveur de production, et ce n'est pas là qu'on souhaite découvrir qu'un paquet a changé.

La meilleure façon de faire

Résolvez les dépendances là où vous avez les ressources, et livrez le résultat. Le serveur ne lance alors jamais 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 — les cadres de test et les débogueurs n'ont rien à faire en production.
  • --optimize-autoloader — une carte des classes au lieu de recherches sur le disque, et un gain de vitesse mesurable.
  • --classmap-authoritative — plus aucun appel stat de repli. À n'utiliser que si rien ne génère de classes à l'exécution.

S'il faut absolument le lancer sur le serveur

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

La limite de mémoire est l'obstacle habituel. La relever pour cette seule commande évite de la relever pour tout le site.

Versionnez le fichier de verrouillage, jamais le répertoire vendor

composer.lock a sa place dans git : c'est lui qui rend deux installations identiques. Le répertoire vendor n'y a pas la sienne : il rend le dépôt énorme et les fusions impossibles.

Déployer sans fenêtre cassée

Copier des fichiers dans un répertoire en service, c'est faire voir à certaines requêtes la moitié du nouveau code. Construisez dans un nouveau répertoire et basculez un lien symbolique : le changement devient atomique.

ln -sfn /var/www/releases/2026-09-05 /var/www/current
sudo systemctl reload php8.3-fpm       # clear the opcache of the old paths
Rechargez PHP-FPM après un déploiement, sinon opcache continuera à servir l'ancien code depuis la mémoire — voir Ce que met en cache opcache.