Kapitel 2 von 5

Composer auf Debian 13 installieren und richtig absichern

geprüft am 2 September 2026 · 3 Min.

Schnelle Antwort

Lade das Installationsprogramm herunter, vergleiche seine SHA-384-Prüfsumme mit der auf composer.github.io/installer.sig veröffentlichten und führe es nur aus, wenn beide übereinstimmen. Installiere es nach /usr/local/bin/composer, damit es allen Benutzern zur Verfügung steht. Benutze danach nie sudo composer install: Starte Composer mit dem Konto, dem das Projekt gehört.

Composer installiert Laravel und sämtliche Abhängigkeiten. Unter Debian geht es nicht nur darum, es zu installieren, sondern darum, dabei kein heruntergeladenes Skript ungeprüft auszuführen: Die offizielle Prozedur vergleicht die Prüfsumme des Installationsprogramms, bevor sie es startet.

Die Schritte wurden am 2. September 2026 auf Debian 13 „trixie“ mit PHP 8.4.24 ausgeführt. Dieses Kapitel gehört zur Installation von Laravel auf einem Debian-Server, im Lernpfad Webentwicklung.

Voraussetzungen

Composer ist ein PHP-Programm: Du brauchst vorher PHP auf der Kommandozeile.

bash

php -v
sudo apt install -y php-cli unzip curl ca-certificates

unzip ist kein Beiwerk: Ohne das Paket entpackt Composer die Archive in PHP, und das dauert deutlich länger.

Composer mit Signaturprüfung installieren

Vier Befehle, in dieser Reihenfolge. Der dritte ist der entscheidende: Er vergleicht die Prüfsumme der heruntergeladenen Datei mit der, die das Projekt veröffentlicht.

bash

# 1. die Referenz-Prüfsumme, vom Composer-Projekt veröffentlicht
EXPECTED="$(curl -sS https://composer.github.io/installer.sig)"

# 2. das Installationsprogramm
curl -sS https://getcomposer.org/installer -o composer-setup.php

# 3. die Prüfsumme der empfangenen Datei
ACTUAL="$(php -r 'echo hash_file("sha384", "composer-setup.php");')"

# 4. nichts starten, wenn die beiden abweichen
if [ "$EXPECTED" = "$ACTUAL" ]; then
    sudo php composer-setup.php --install-dir=/usr/local/bin --filename=composer
    rm composer-setup.php
else
    >&2 echo "Signature invalide : téléchargement corrompu ou altéré."
    rm composer-setup.php
    exit 1
fi

Auf der Testinstallation stimmen beide Prüfsummen überein:

code

attendue : c8b085408188070d5f52bcfe4ecfbee5f727afa458b2573b8eaaf77b3419b0bf2768dc67c86944da1544f06fa544fd47
obtenue  : c8b085408188070d5f52bcfe4ecfbee5f727afa458b2573b8eaaf77b3419b0bf2768dc67c86944da1544f06fa544fd47
→ signature valide

Warum dieser Schritt nicht optional ist

Ohne ihn führst du mit sudo-Rechten ein PHP-Skript aus, das du gerade aus dem Netz geladen hast, ohne jede Garantie über seinen Inhalt. Genau deshalb veröffentlicht die offizielle Dokumentation eine Referenzprüfsumme. Tutorials, die curl und danach php composer-setup.php ohne Vergleich aneinanderreihen, überspringen den einzigen verfügbaren Schutz.

Prüf das Ergebnis:

bash

composer --version

code

Composer version 2.10.3 2026-08-27 13:34:23
PHP version 8.4.24 (/usr/bin/php8.4)

Die Ablage in /usr/local/bin unter dem Namen composer macht den Befehl für alle Benutzer des Servers verfügbar, ohne dass du PATH anfassen musst.

Und das Debian-Paket?

Debian bietet ein Paket composer an. Es funktioniert, folgt aber dem Takt der Distribution: Die Version aus den Repositories hinkt der aktuellen fast immer hinterher. Da Composer sich mit einem einzigen Befehl selbst aktualisiert, bleibt die manuelle Installation auf einem Anwendungsserver die bessere Wahl.

bash

sudo composer self-update          # letzte stabile Version
sudo composer self-update --rollback   # zurück zur vorherigen

Composer nicht als root starten

Die Binärdatei mit sudo zu installieren, ist normal. Sie mit sudo zu benutzen, ist es nicht.

bash

# zu vermeiden
sudo composer install

# richtig: der Benutzer, dem das Projekt gehört
su - deploy
cd /var/www/mon-projet
composer install --no-dev --optimize-autoloader

Auf einem macOS-Rechner stellt sich das Problem anders und zeigt sich oft als nicht gefundener laravel-Befehl.

Dafür gibt es zwei Gründe. Die post-install-Skripte der Abhängigkeiten laufen mit den Rechten, die du ihnen gibst. sudo composer install ist damit fremder Code, der als root ausgeführt wird. Und die erzeugten Dateien gehören anschließend root, was zu Schreibfehlern führt, sobald der Webserver in storage/ schreiben will.

Composer warnt übrigens von sich aus, wenn es ohne COMPOSER_ALLOW_SUPERUSER als root gestartet wird.

Nützliche Optionen in Produktion

bash

composer install --no-dev --optimize-autoloader --no-interaction

Option	Wirkung
`--no-dev`	überspringt die Entwicklungsabhängigkeiten (Tests, Debugging-Werkzeuge)
`--optimize-autoloader`	erzeugt eine statische Klassentabelle, die schneller lädt
`--no-interaction`	stellt keine Rückfragen, unverzichtbar im automatisierten Deployment

Rolle die Datei composer.lock immer mit dem Projekt aus und führe composer install aus, nicht composer update: Der erste Befehl installiert genau die Versionen aus dem Lock, der zweite berechnet sie neu und kann mitten im Produktivgang ungetestete Änderungen einschleppen.

Häufige Fehler

Den Installer ohne Signaturprüfung ausführen Du startest mit sudo ein PHP-Skript aus dem Netz, ohne Garantie über seinen Inhalt. Der Prüfsummenvergleich ist der einzige verfügbare Schutz.

sudo composer install Die post-install-Skripte der Abhängigkeiten laufen als root, und die erzeugten Dateien gehören root, was danach das Schreiben durch den Webserver blockiert.

composer update in Produktion Berechnet die Versionen neu und kann ungetestete Änderungen einschleppen. Im Deployment gilt composer install auf Basis der composer.lock.

unzip vergessen Composer entpackt die Archive dann in PHP, deutlich langsamer.

Auf das Debian-Paket setzen Es funktioniert, hinkt aber der aktuellen Version hinterher, während Composer sich mit self-update selbst aktualisiert.

Composer auf Debian 13 installieren und richtig absichern

Voraussetzungen

Composer mit Signaturprüfung installieren

Und das Debian-Paket?

Composer nicht als root starten

Nützliche Optionen in Produktion

Häufige Fehler

Neue Tests, Tutorials und Projekte, per E-Mail.