Wer mehr als eine PHP-Seite hostet, stößt irgendwann an die Versions-Wand. Eine ältere Kundenseite betreibt ein Theme oder Plugin, das bei allem jenseits von PHP 7.4 bricht. Die App, die Sie heute bauen, will 8.3 oder 8.4 für typisierte Eigenschaften und Performance. Ein drittes Projekt hängt an 5.6-Ära-Code fest, den niemand modernisieren will. Der Reflex ist, pro Ära einen eigenen Server aufzusetzen — aber das ist verschwenderisch und unnötig. Eine Linux-Maschine kann jede PHP-Version gleichzeitig betreiben, jede Site auf genau die gepinnt, die sie braucht. So funktioniert das, und so bleibt es sauber.

Warum Multi-PHP wichtig ist

Legacy und modern, nebeneinander. Sie müssen eine alte Seite nicht auf ein neues PHP zwingen (und den Weißbild-Absturz erleben) oder eine neue App auf einem alten zurückhalten. Jede bekommt ihre korrekte Version.
Sichere Upgrades. Sie können eine Seite für sich von 8.1 auf 8.3 heben, testen und zurückrollen — ohne die zwölf anderen Seiten der Maschine zu berühren.
Ein Server, viele Ären. Kein Zahlen für zusätzliche VPSe, nur um PHP-Versionen zu trennen. Eine 5.6-Seite neben einer 8.4-Seite zu hosten kostet praktisch nichts.

Der Mechanismus, der das ermöglicht, ist PHP-FPM (FastCGI Process Manager), und ihn zu verstehen ist die ganze Sache.

Wie das Betreiben vieler Versionen funktioniert

Moderne Linux-Distributionen erlauben, mehrere PHP-Versionen parallel zu installieren. Auf Ubuntu/Debian ist der übliche Weg das ondrej/php-PPA, das php5.6-fpm, php7.4-fpm, php8.1-fpm, … php8.4-fpm als getrennte Dienste paketiert, die problemlos koexistieren.

Jede installierte Version betreibt ihren eigenen FPM-Master, und jeder Master kann mehrere Pools betreiben. Ein Pool ist eine isolierte Worker-Prozessgruppe mit eigener Konfiguration: unter welchem Benutzer er läuft, seine Ressourcenlimits und — entscheidend — seinem eigenen Lausch-Socket. Das Bild ist also:

php7.4-fpm  →  Pool: siteA  →  /run/php/siteA.sock   (läuft als Benutzer siteA)
php8.4-fpm  →  Pool: siteB  →  /run/php/siteB.sock   (läuft als Benutzer siteB)

Ihr Webserver (Nginx) führt PHP nicht selbst aus — er reicht .php-Anfragen über FastCGI an einen Socket weiter. Also wird „welche PHP-Version nutzt diese Seite?" durch eine Zeile in der Nginx-Konfiguration der Seite beantwortet: an welchen Socket sie weiterleitet.

# Site A auf PHP 7.4
location ~ \.php$ {
    fastcgi_pass unix:/run/php/siteA.sock;
    include fastcgi_params;
}

Zeigen Sie dieses fastcgi_pass auf den Socket des 7.4-Pools, läuft die Seite mit 7.4; zeigen Sie es auf den Socket des 8.4-Pools, läuft sie mit 8.4. Die PHP-Version einer Seite zu wechseln heißt eigentlich nur, ihren Socket umzuzeigen und Nginx neu zu laden. Alles andere — Dateien, Datenbank — bleibt unberührt.

Isolation: der Teil, den man überspringt

Einen Pool pro Site zu betreiben geht nicht nur um Versionen; so hält man auch Mandanten auseinander. Zwei Regeln leisten die Hauptarbeit:

Ein Linux-Benutzer pro Pool. Betreiben Sie den FPM-Pool jeder Site unter ihrem eigenen dedizierten Benutzer (kein geteiltes www-data). Dann kann ein kompromittiertes Plugin auf einer Seite nicht die Dateien oder DB-Zugangsdaten einer anderen lesen — die OS-Rechte verhindern es.
open_basedir pro Pool. Setzen Sie open_basedir in der Konfiguration jedes Pools, um sein PHP an den Document-Root dieser Seite (plus Temp-Verzeichnis) zu binden. Selbst ein fehlerhaftes oder bösartiges Skript kann dann physisch nicht außerhalb seines Verzeichnisses lesen.

Machen Sie diese zwei richtig, bedeutet „viele PHP-Versionen auf einer Maschine" auch „viele sicher isolierte Seiten auf einer Maschine". (Mehr zu dieser geschichteten Isolation in mehrere Kundenseiten auf einem VPS hosten.)

Die Fallen, auf die zu achten ist

CLI-PHP ist eine andere Version. Das php auf der Kommandozeile (für Composer, WP-CLI, Cron) ist der Systemstandard — oft nicht die Version, die der FPM-Pool einer Seite nutzt. Verwenden Sie versionsspezifische Binaries (php7.4, php8.4) oder setzen Sie den Standard pro Site, damit Cronjobs nicht unter der falschen Version laufen.
Erweiterungen sind pro Version. php-redis, php-imagick, php-gd und Co. müssen für jede PHP-Version separat installiert werden (php8.4-redis, php7.4-redis). Eine Seite, die nach einem Versionswechsel eine Erweiterung „verloren" hat, braucht meist einfach das Erweiterungspaket für die neue Version.
Jeder Pool kostet Speicher. Jeder Pool hält Worker-Prozesse im RAM. Ein Dutzend ausgelasteter Pools summiert sich — dimensionieren Sie pm.max_children pro Pool und beobachten Sie den Speicher, statt jeden Pool annehmen zu lassen, ihm gehöre die ganze Maschine.
Neu laden, nicht vergessen. Nach dem Ändern eines Pools oder Sockets laden Sie den FPM-Dienst und Nginx neu. Eine erneuerte, nicht neu geladene Konfiguration ist eine nicht aktive Konfiguration.

Es von Hand zu machen ist fummelig — machen Sie es zum Ein-Klick

Nichts davon ist für sich schwer. Aber es für jede Site korrekt zu verdrahten — die richtige FPM-Version installieren, einen Pool als Benutzer der Site mit dem richtigen open_basedir und Limits erstellen, einen Socket erzeugen, Nginx umzeigen, beide Dienste neu laden, CLI und Erweiterungen abgestimmt halten — sind viele fummelige, fehleranfällige Schritte, die man bei jedem neuen Site oder Versionswechsel von Hand wiederholt.

Genau das sollte ein Panel abnehmen. ShadowPanel verwaltet den gesamten Multi-PHP-Stack für Sie:

PHP 5.6 bis 8.4, parallel installiert und pro Site bereit.
Wechseln Sie die Version einer Site per Dropdown — das Panel regeneriert den isolierten FPM-Pool der Site, zeigt den Nginx-Socket um und lädt beide Dienste neu. Kein SSH, keine Konfigurationsbearbeitung.
Isolation standardmäßig angewandt — jeder Pool läuft unter dem eigenen Linux-Benutzer der Site mit erzwungenem open_basedir.
Erweiterungen und Konfiguration pro Site über das Panel verwaltet, damit ein Versionswechsel nicht still fallen lässt, was die Site braucht.

Sie wählen die Version; das Panel macht die Verrohrung — sicher, jedes Mal gleich.

Fazit

Sie brauchen keinen Server pro PHP-Ära. Eine Maschine, PHP-FPM und ein isolierter Pool pro Site lassen Sie 5.6 neben 8.4 betreiben, jede Site auf genau der Version, die sie braucht — und, richtig gemacht, jede Site von den anderen abgeschottet. Die Konzepte sind einfach; die Verdrahtung pro Site ist mühsam und subtil fehleranfällig. ShadowPanel macht aus „die PHP-Version dieser Site wechseln" ein Dropdown, mit eingebauter Isolation.

curl -fsSL https://shadowpanel.de/install.sh | bash

Preise ansehen und herunterladen →

Mehrere PHP-Versionen auf einem Server betreiben (5.6 bis 8.4), pro Site