Runtime und PHP-Einstellungen

Beide Entscheidungen liegen im Tab Einstellungen der Website und lassen sich jederzeit ändern.

Runtime

Runtime	Was läuft
PHP 8.2 bis PHP 8.5	PHP, mit den unten gelisteten Extensions
Static	Gar kein PHP. HTML, CSS, JavaScript und andere Dateien werden ausgeliefert, wie sie sind

Neue Websites starten mit der neuesten PHP-Version. Nimm die neueste, die deine Anwendung unterstützt: ältere Versionen verlieren zuerst die Sicherheitsupdates, und es gibt keinen Performance-Grund, zurückzubleiben.

Static ist kein abgespecktes PHP. Eine .php-Datei auf einer statischen Website wird als reine Datei ausgeliefert, Quelltext inklusive. Stell also nie eine PHP-Website auf Static um, solange noch PHP-Dateien im Document Root liegen.

Webserver

Webserver	Wähl ihn, wenn
nginx	Standard. Schneller, und schöne URLs funktionieren ohne Konfiguration
Apache	Deine Anwendung .htaccess braucht

.htaccess bewirkt unter nginx nichts

nginx liest .htaccess nie. Jede Rewrite-Regel, Weiterleitung, jeder Header und jede Zugriffsregel in dieser Datei wird stillschweigend ignoriert, und nirgends erscheint ein Fehler. Eine von woanders migrierte Website bringt ihre .htaccess mit, sieht konfiguriert aus und ist es nicht.

Wenn deine Anwendung wirklich auf ihre .htaccess angewiesen ist, stell den Webserver auf Apache um. Wenn sie nur schöne URLs braucht, kann nginx das bereits.

Unter nginx wird eine Anfrage nach einer nicht existierenden Datei an index.php übergeben. WordPress-Permalinks, Laravel-Routen und jeder andere Front Controller funktionieren also unverändert. Was eine fehlende Seite zurückgibt, entscheidet deine Anwendung, nicht der Webserver.

Zwei weitere Unterschiede, die du kennen solltest:

• Versteckte Dateien. Unter nginx wird jeder Pfad mit einem Namensteil, der mit einem Punkt beginnt, mit 403 abgelehnt, also auch .env, .git/ und Ähnliches. Apache hat diese Regel nicht, dort musst du sie selbst in der .htaccess setzen.
• Verzeichnislisten. nginx listet nie ein Verzeichnis auf. Unter Apache hängt das Verhalten an deiner eigenen .htaccess; ergänz Options -Indexes, wenn du dich darauf verlässt.

Nachträglich umstellen

Runtime oder Webserver zu ändern ersetzt die Container der Website. Das Portal warnt vor dem Speichern:

Beim Speichern ist deine Website kurz nicht erreichbar (wenige Sekunden während die neue Runtime startet). Fortfahren?

Der Austausch wartet, bis die neuen Container eine Prüfung beantworten, bevor die alten aufhören. In der Praxis siehst du also ein paar Sekunden Mischbetrieb statt eines harten Ausfalls. Beim ersten Einsatz einer PHP-Version auf der Maschine, auf der deine Website landet, dauert es länger.

Document Root

Deine Dateien liegen in public_html. Standardmäßig ist dieses Verzeichnis komplett das Document Root, was für WordPress, Drupal, einfaches PHP und statische Websites richtig ist.

Anwendungen, deren Einstiegspunkt eine Ebene tiefer liegt (Laravel, Symfony, Flarum), setzen Document-Root-Unterordner auf public. Alles darüber, vendor/, storage/, Konfigurationsdateien, bleibt dann aus dem Web unerreichbar.

Das Feld nimmt nur einen relativen Unterordner:

Nur Unterordner — Buchstaben, Ziffern, _ und -, optional durch / getrennt. Kein führender Schrägstrich, kein Pfad-Traversal.

PHP-Einstellungen

Die Karte PHP-Einstellungen erscheint bei jeder PHP-Runtime. Sechs Einstellungen, jede ein Auswahlfeld, dazu drei Vorlagen (Standard, WordPress, Laravel), die alle sechs auf einmal füllen.

Einstellung	Standard	Angebotene Werte
Max. Upload-Größe	2M	2M bis 512M
Max. POST-Größe	8M	2M bis 512M
Max. Ausführungszeit	30s	30s, 60s, 120s, 300s, 600s
Speicherlimit	128M	64M, 128M, 256M, 512M
Fehler anzeigen	Off	On, Off
Fehlerberichterstattung	E_ALL & ~E_DEPRECATED	E_ALL, E_ALL & ~E_NOTICE, E_ALL & ~E_DEPRECATED

Eine höhere Upload-Größe hebt auch das Anfragelimit vor der Website an, du musst also nichts weiter ändern. Die harte Obergrenze liegt bei 512 MiB, egal was die Einstellung sagt.

Speichern der PHP-Einstellungen wendet sie nicht an

Beim ersten Speichern dieser Karte startet die Website neu und die Werte werden wirksam. Jede spätere Änderung derselben Einstellungen wird gespeichert, erreicht PHP aber nicht. Die Website läuft mit den alten Werten weiter, und nichts weist dich darauf hin.

Nach einer Änderung gehst du auf Aktionen und nutzt Website neu starten. Danach prüfst du den Wert in der Konsole:

php -i | grep memory_limit

Grenzen, die deine Einstellungen überstimmen

• Speicherlimit gilt pro Anfrage, die ganze Website hat aber 512 MiB. Unter nginx laufen bis zu 15 PHP-Anfragen gleichzeitig, alle aus diesem einen Budget. 512M gibt einer Anfrage also keine 512 MiB, sondern nimmt PHP die eigene Bremse und lässt wenige gleichzeitige Anfragen die Website leerräumen. Was dann passiert, ist kein sauberer PHP-Fatal-Error: der Website geht als Ganzes der Speicher aus, und Anfragen, die damit nichts zu tun hatten, sterben mit. 256M ist der höchste Wert, den man als normal behandeln kann.
• Unter nginx wird eine Anfrage nach 300 Sekunden abgeschnitten, egal was Max. Ausführungszeit sagt. Die Option 600s hat dort also keine Wirkung. Lange Arbeit gehört in einen Cron-Job, der ein eigenes Zeitlimit von bis zu 3600 Sekunden hat.
• Max. POST-Größe darf nie unter Max. Upload-Größe liegen. Uploads dieser Größe scheitern still. Das Portal warnt bei einer falschen Kombination.
• Fehler anzeigen gehört in Produktion auf Off. On gibt Dateipfade und teils Quelltext an Besucher aus.

Statische Websites haben ein festes Limit von 8 MiB

Bei einer Static-Website erscheint die Karte mit den PHP-Einstellungen nicht, und das Limit für den Anfragekörper liegt fest bei 8 MiB. Anheben lässt es sich nicht. Wenn ein Formular auf einer statischen Website größere Uploads annehmen soll, ist es keine statische Website.

Extensions

Jede PHP-Version bringt denselben Satz mit. Die nennenswerten:

mysqli, pdo_mysql, pdo_sqlite, mbstring, gd, imagick, curl, xml, dom, simplexml, zip, zlib, intl, bcmath, exif, sodium, openssl, opcache, redis, sqlite3, fileinfo, iconv, posix.

Nicht installiert und von dir nicht nachinstallierbar: soap, ldap, imap, apcu, memcached, mongodb, xsl, tidy, gmp, ssh2, xdebug. Wenn deine Anwendung eine davon braucht, ist Hosting das falsche Produkt.

Sämtliche pcntl_*-Funktionen und dl() sind deaktiviert. Code, der forkt oder zur Laufzeit Extensions nachlädt, scheitert. exec() und shell_exec() stehen zur Verfügung.

Eine geänderte Datei kann 60 Sekunden brauchen, bis sie live ist

Kompiliertes PHP wird zwischengespeichert, und der Cache wird einmal pro Minute geprüft. Nach einem Upload oder Deployment kann eine Seite bis zu 60 Sekunden den alten Code ausliefern. Das ist kein Caching-Plugin und nicht dein Browser. Warte ab, oder nutz Website neu starten unter Aktionen, um es sofort zu leeren.

Weiter

• Dateien, Konsole und Cron, um Code hochzuladen und Befehle auszuführen
• Fehlersuche, wenn eine Änderung nicht gewirkt hat