Composer löst Abhängigkeiten auf, und das braucht Speicher und Netzzugang — beides ist auf Shared Hosting knapp. Außerdem lädt es Code direkt auf einen Produktionsserver, und dort will man nicht entdecken, dass sich ein Paket geändert hat.

Die bessere Form

Lösen Sie Abhängigkeiten dort auf, wo Sie die Ressourcen haben, und liefern Sie das Ergebnis aus. Der Server führt Composer dann gar nicht mehr aus.

# 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 — Test-Frameworks und Debugger gehören nicht in die Produktion.
  • --optimize-autoloader — eine Klassenkarte statt Dateisystem-Abfragen, und ein messbarer Geschwindigkeitsgewinn.
  • --classmap-authoritative — überhaupt keine Rückfall-stat-Aufrufe. Nur verwenden, wenn zur Laufzeit nichts Klassen erzeugt.

Wenn Sie es doch auf dem Server ausführen müssen

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

Das Speicherlimit ist der übliche Stolperstein. Es nur für diesen einen Befehl anzuheben erspart es, es für die ganze Website anzuheben.

Die Lock-Datei ins Repository, das vendor-Verzeichnis niemals

composer.lock gehört in git — sie ist es, die zwei Installationen identisch macht. Das vendor-Verzeichnis gehört nicht hinein: Es bläht das Repository auf und macht Merges unmöglich.

Ausrollen ohne zerbrochenes Fenster

Dateien in ein laufendes Verzeichnis zu kopieren heißt, dass manche Anfragen den neuen Code halb sehen. Bauen Sie in ein neues Verzeichnis und schalten Sie einen Symlink um — dann ist die Änderung atomar.

ln -sfn /var/www/releases/2026-09-05 /var/www/current
sudo systemctl reload php8.3-fpm       # clear the opcache of the old paths
Laden Sie PHP-FPM nach einem Deploy neu, sonst liefert opcache weiterhin den alten Code aus dem Speicher — siehe Was opcache cacht.