Ein Entwickler stellt Laravel auf einem „standortidentischen“ VPS bereit. Die „.env“-Datei wird mit „APP_DEBUG=true“ kopiert, die Warteschlange bleibt im „sync“-Treiber, der Scheduler existiert nicht, das Verzeichnis „storage/“ ist zum Schreiben nicht zugänglich. Die Maschine ist korrekt. Die Produktionsumgebung ist es nicht. Laravel erfordert, dass die Hardwarekomponente klar von der Anwendungskonfiguration getrennt ist – sonst wird jede Bereitstellung zur Lotterie.
Beim Support kommt es immer wieder zu Verwirrung: Wir kaufen einen „Laravel-ready“-Server, weil PHP 8.3 installiert ist, dann vergessen wir, Routen und Ansichten zwischenzuspeichern, Worker zu starten oder Berechtigungen zu sperren. Der Server führt den Code aus; Die Umgebung entscheidet, ob sie im Demo-Modus oder im Produktionsmodus läuft. Solange diese beiden Karten nicht separat gelesen werden, sehen die Vorfälle wie Anwendungsfehler aus, obwohl sie aus der Bereitstellung stammen.
Server und Umgebung: zwei separate Karten
Der Server beinhaltet das Betriebssystem, Nginx oder Apache, PHP-FPM, Redis ggf. Sicherheitspatches. Die Umgebung umfasst die „.env“-Datei, den „APP_KEY“, die Datenbank-URLs, die Mail-Konfiguration, den Warteschlangentreiber und die Laravel-Caches („config:cache“, „route:cache“, „view:cache“). Die Build-Ebene fügt „composer install --no-dev“ und Fast- oder Mix-Kompilierung hinzu. Die Runtime-Ebene fügt die überwachten Worker und die Cron-Zeile hinzu, die jede Minute „schedule:run“ aufruft.
| Schicht | Beispiele | Häufiger Fehler |
|---|---|---|
| Server | nginx, PHP-FPM 8.2, Redis | Glauben Sie, dass PHP installiert = produktionsbereit ist |
| Umwelt | .env, APP_KEY, QUEUE | „.env“ des Stagings live kopiert |
| Bauen | Ohne Entwickler kompilieren, Assets kompilieren | Entwicklungsabhängigkeiten in der Produktion |
| Laufzeit | Arbeiter, Planer | Jobs sind „synchronisiert“, Cron fehlt |
Ein schlecht konfigurierter Laravel-fähiger Server bleibt im Demomodus eine Laravel-Anwendung.
Bereitstellungs-Checkliste, die Bestand hat
Umgebungsvariablen müssen „APP_ENV=Produktion“, „APP_DEBUG=false“, eindeutige Schlüssel und korrekte URLs anzeigen. Abhängigkeiten durchlaufen „composer install --no-dev --optimize-autoloader“. Die Front-Assets werden in CI oder lokal kompiliert und dann bereitgestellt; php artisan storage:link erstellt den erwarteten symbolischen Link. Generieren Sie nach jeder Bereitstellung Konfigurations-Caches, Routen und Ansichten neu. Die Verzeichnisse „storage/“ und „bootstrap/cache/“ müssen für den PHP-FPM-Benutzer beschreibbar sein.
Warteschlangen erfordern Supervisor oder Systemd mit Redis oder eine dedizierte Tabelle; Achten Sie auf „failed_jobs“. Der Scheduler benötigt einen Cron-Eintrag „ * php artisan scheme:run“. Migrationen werden mit „migrate --force“ erst nach dem Speichern der Datenbank gestartet. Jeder Schritt kann automatisiert werden – Forge, Submit, GitHub Actions, Deploy – aber die Liste bleibt gleich, egal ob Sie klicken oder ein Skript ausführen.
Wählen Sie den Host außerhalb des Prozessors
Ein glaubwürdiger Laravel-Host bietet aktuelles PHP, dokumentierte Erweiterungen, installierbares oder verwaltetes Redis, SSH, zuverlässiges Cron und einen unterbrechungsfreien Bereitstellungspfad – Release-Symlink oder schrittweise Bereitstellung, wenn der Datenverkehr kritisch ist. Eine minimale Staging-Umgebung mit separater „.env“ vermeidet unangenehme Überraschungen. Für eine kleine Anwendung kann „Shared“ ausreichend sein; Sobald Warteschlangen und Mitarbeiter ins Spiel kommen, werden VPS oder verwaltete Plattformen zur Norm.
Richten Sie die PHP-Version an PHP-Version auswählen und die Abhängigkeiten an Composer in Produktion aus. Octane und Horizon erhöhen die Komplexität erst dann sinnvoll, wenn ein FPM-Engpass nachgewiesen wurde oder ein Dashboarding für Redis-Dateien erforderlich ist.
Der Gipfel: Eine erfolgreiche Bereitstellung ist unsichtbar
Durchsuchen Sie PHP-Hosts im Verzeichnis und vergleichen Sie Angebote mit Redis und SSH-Zugriff über den Vergleich.
Entscheide dich und gehe ohne blinden Fleck voran
Erstellen Sie eine Version eines „.env.produktion“-Modells ohne Geheimnisse und fügen Sie die Schlüssel über Ihre Pipeline oder Ihren Geheimnismanager ein. Automatisieren Sie die Bereitstellung mit Cache-, Migrations- und Worker-Neustartschritten in dokumentierter Reihenfolge. Konfigurieren Sie Supervisor für Warteschlangen und testen Sie vor dem ersten echten Vorfall ein Rollback auf die vorherige Version. Überwachen Sie „failed_jobs“ und Anwendungsprotokolle, sobald sie live gehen. Überprüfen Sie abschließend, ob der Scheduler wirklich läuft – ein fehlender Cron fällt oft erst drei Wochen später auf, wenn die Berichte nicht mehr kommen.
Häufig gestellte Fragen
Was ist der Unterschied zwischen Server- und Laravel-Umgebung?
Der Server bezeichnet die Maschine – System, Webserver, PHP-Version. Die Umgebung bezeichnet den Anwendungskontext: „.env“-Datei, „APP_ENV=Produktion“-Wert, Konfigurationscaches und API-Schlüssel. Eine Verwechslung der beiden führt zu „APP_DEBUG=true“ in Produktions- oder Online-Staging-Schlüsseln.
FPM oder Laravel Octane in der Produktion?
PHP-FPM bleibt standardmäßig die robuste Wahl. Octane mit Swoole oder RoadRunner kann auf einer API mit hohem Datenverkehr gewinnen, führt jedoch zu Kompatibilitätsbeschränkungen für Pakete. Beginnen Sie mit FPM, es sei denn, der Benchmark beweist das Gegenteil.
Wie verwaltet man Laravel-Warteschlangen?
Supervisor oder Systemd sollten „queue:work“ oder „queue:listen“ neu starten. Verwenden Sie Redis oder eine Datenbankwarteschlange – niemals den „Sync“-Treiber in der Produktion für E-Mails und schwere Aufgaben.
Was kann man von einem Gastgeber für Laravel verlangen?
PHP 8.2 oder neuer, Composer, Redis, zuverlässiges Cron, SSH-Zugriff, nützliche Erweiterungen (intl, bcmath, pcntl für Worker) und ein dokumentiertes nahtloses Bereitstellungsverfahren.
In Laravel beginnt die Produktion, wenn „.env“ Produktion angibt – nicht, wenn DNS auf den VPS verweist.