Checkliste für die Hosting-Bereitschaft

Verwenden Sie diese Checkliste vor dem Kauf von Hosting, vor der ersten Produktionsbereitstellung und nach einer wesentlichen Server- oder PHP-Konfigurationsänderung. Notieren Sie für jeden Gegenstand die Beweise und den Besitzer; ein mündliches „Laravel wird unterstützt“ reicht nicht aus.

Die verbindlichen Plattform- und Funktionsanforderungen stehen in Hosting-Anforderungen. Ressourcenwerte müssen aus aufgezeichneten Quellen stammen Hosting-Kapazitätsergebnisse produziert mit Hosting-Kapazitätsvalidierung, nicht aus einer ungemessenen Schätzung. Ein als vorläufig gekennzeichnetes Ergebnis dient nur als Vergleichsnachweis; qualifizieren Sie das tatsächliche Produktionsprofil, bevor Sie seine Werte als zertifizierte Anforderungen behandeln.

• PHP 8.3 oder neuer steht sowohl für Webanfragen als auch in der CLI zur Verfügung; der Anbieter beschreibt die Pflege der Patch-Releases.
• Composer 2 kann im Anwendungsverzeichnis ohne künstliche Zeitüberschreitung bei der Abhängigkeitsinstallation ausgeführt werden.
• mbstring, sodium, zipund pdo_mysql sind sowohl im Web als auch im CLI PHP aktiviert.
• MySQL 8.0 mit InnoDB ist verfügbar, einschließlich der Berechtigung zum Erstellen und Ändern von Tabellen, Indizes und Fremdschlüsseln.
• Der Domänendokumentstamm kann direkt auf die Laravel-Anwendungen verweisen public/ .
• HTTPS-Zertifikate und automatische Verlängerung sind verfügbar.
• Der Anbieter gibt PHP-Speicher, Upload, POST-Text, Anforderungszeitlimit, Prozess, Inode und Festplattenkontingente an.
• Der Anbieter erklärt, ob proc_open, PHP CLI, Composer und Datenbank-Client-Binärdateien stehen der PHP-Laufzeit zur Verfügung.
• Der Anbieter erklärt, ob Symlinks zulässig sind public/storage.
• Cron ist verfügbar, wenn die geplante Verwaltung aktiviert wird.
• Ausgehendes HTTPS ist für Composer, CMS-Updates oder den Remote-Medienimport zulässig.
• Backup-Aufbewahrung, Wiederherstellungsverfahren, Überwachung und Support-Eskalation sind dokumentiert.
• Die ausgewählten Kern-, Medien-, Betriebs- und Verkehrsprofile werden als anwendbar oder nicht anwendbar identifiziert.

Jede „Nein“-Antwort muss vor der Genehmigung einer absichtlich deaktivierten Funktion oder einem externen Bereitstellungs-/Betriebsverfahren zugeordnet werden.

• Das Produktionsrelease ist in einer Laravel-12.55+- oder Laravel-13-Host-Anwendung installiert und wird nicht direkt aus dem Paketquellrepository ausgeliefert.
• Web- und CLI-Bericht kompatible PHP-Versionen und Erweiterungssätze.
• composer check-platform-reqs übergibt die bereitgestellte Hostanwendung.
• Die Datenbankverbindung ist erfolgreich und verwendet die vorgesehene Produktionsdatenbank.
• APP_KEY ist gesetzt, APP_DEBUG=falseund APP_URL ist die kanonische HTTPS-URL.
• Das Webstammverzeichnis ist public/; /.env und /.git/config Rückkehr 404.
• Laravel Rewrite/Front-Controller-Verhalten funktioniert für eine Nicht-Datei-Route.
• /webadmin leitet währenddessen über Laravel weiter /cms stellt paketeigene statische Assets bereit.
• storage/, bootstrap/cache, der Sicherungsdatenträger, und erforderlich public/site -Pfade sind von der PHP-Laufzeit ohne beschreibbar 777.
• public/storage funktioniert, wenn die standardmäßige öffentliche Festplatte verwendet wird.
• Datenbank- und Dateisicherungen sind außerhalb der Anwendung vorhanden und ein Wiederherstellungstest hat einen Besitzer und ein Datum.
• Die Speicher-, Timeout-, Upload-, Datenträger- und Funktionsannahmen des ausgewählten Kapazitätsprofils stimmen mit diesem Server überein.

Markieren Sie ungenutzte Funktionen als nicht anwendbar und notieren Sie den Grund dafür.

• Medien: Ein Upload kann gespeichert und bereitgestellt werden. Wenn Bildvarianten erforderlich sind, stehen GD und der Quellformat-Codec zur Verfügung.
• E-Mail: Das Zurücksetzen des Passworts und die Zustellung der Kontaktbenachrichtigung erreichen das vorgesehene Testpostfach über einen echten Transport.
• Panel-Benachrichtigungen: Bei deaktivierter E-Mail und ohne laufenden Scheduler kann ein Site-Betriebsmanager gespeicherte ungelesene/auf Antwort wartende Kontaktnachrichten zählen und den richtigen sitegefilterten Posteingang öffnen. Andere Sites bleiben ausgeschlossen; das Öffnen des Panels ändert weder Nachrichten- noch Zustellstatus.
• Planer: Wenn gestapelte/tägliche Benachrichtigungen, tägliche Zusammenfassungen oder geplante Bereinigung ausgewählt werden, hat der Serveradministrator/Anbieter Laravel konfiguriert schedule:run jede Minute unter dem Anwendungsbenutzer mit dem richtigen CLI-PHP-Programm ausführt. Erfassen Sie die verantwortliche Person und den tatsächlichen Anwendungspfad; ein vorhandener funktionierender Scheduler benötigt keinen zweiten Cron-Eintrag.
• Benachrichtigungsabhängigkeiten: ein echter ausgehender E-Mail-Transport, kanonisch APP_URLund ein gemeinsam genutzter Cache mit atomaren Sperren für mehrere Worker sind konfiguriert. Neue Websites verwenden standardmäßig Sammelbenachrichtigungen und tägliche Zusammenfassungen.
• Scheduler-Beweis: auf CMS 1.95.1+, Dashboard-/Site-Einstellungen oder php artisan webblocks:scheduler:status --json einen aktuellen geplanten Heartbeat und einen abgeschlossenen Benachrichtigungslauf anzeigen. Prüfen Sie, dass die Belege nach fünf Minuten ohne Ausführung als verzögert gelten. Manuelles Ausführen des Dispatch-Befehls oder Auflisten der Aufgaben ist kein Nachweis einer Scheduler-Ausführung.
• Systemaktualisierung: Sein Admin-Preflight besteht Datenbank-, Erweiterungs-, Prozess-, Schreibzugriffs-, Sperr- und Freiraumprüfungen.
• MySQL-Sicherung/Wiederherstellung: -Dump und Client-Binärdateien sind verfügbar, wenn native Datenbanksicherungen auf Anwendungsebene verwendet werden.
• Remote-Medien: funktionieren nur, wenn ein Remote-Import erforderlich ist.

• Die öffentliche Homepage gibt die erwartete sichere Antwort zurück.
• /webadmin/login wird über HTTPS geladen und ein autorisierter Administrator kann sich anmelden.
• CMS CSS, JavaScript und Markenwerte unter /cms geben erfolgreiche Antworten zurück.
• Ein Entwurf kann erstellt und in der Vorschau angezeigt werden, ohne dass er öffentlich sichtbar wird.
• Ein Medienelement kann gemäß der Richtlinie hochgeladen, angezeigt und gelöscht werden.
• -Protokolle enthalten keine Berechtigungs-, Datenbank-, gemischten Inhalts- oder fehlende Erweiterungsfehler aus dem Rauchtest.
• Backups, Bereitstellungs-/Update-Besitz, Überwachung und Notfallkontakte werden in der Übergabe aufgezeichnet.

Behalten Sie Folgendes im Bereitstellungsdatensatz bei, ohne Geheimnisse einzubeziehen:

• Hostingplan oder Serverprofil und Region;
• PHP und Datenbankversionen;
• aktivierte Erweiterungsnamen;
• composer check-platform-reqs Ergebnis;
• konfigurierte Ressourcengrenzen und verfügbarer Datenträger zum Zeitpunkt der Abnahme;
• Kapazitäts-Fixture-/Profilversion, Ort des Rohergebnisses, Qualifikationsdatum und Worst-Case mit fünf Läufen;
• Dokument-Root- und Dateisystem-Besitzmodell;
• Aktivierte optionale Funktionen und ihre Abhängigkeiten;
• Rauchtestdatum und Betreiber; und
• Backup-/Wiederherstellungstestdatum, Aufbewahrung und verantwortliche Partei.

Wiederholen Sie die entsprechenden Abschnitte, nachdem Sie die PHP-Version, die Datenbank-Engine, das Dokumentstammverzeichnis, den Dateisystembesitz, die Bereitstellungsmethode oder den Hosting-Anbieter geändert haben.