Ist ein schlichter VPS eine schlechte Idee?

Nein, und für eine einzelne Anwendung ist er oft das Günstigste, was gut funktioniert. Eine schlechte Idee wird er, wenn ihn niemand besitzt - Sicherheitsupdates, Zertifikatserneuerung, Backups, die mindestens einmal zurückgespielt wurden. Das sind die laufenden Kosten, nicht die Monatsrechnung.

Sollten Migrationen im Deployment automatisch laufen?

Die routinemäßigen ja, denn ein manueller Schritt ist ein Schritt, den irgendwann jemand vergisst. Die Ausnahme ist alles, was eine große Tabelle neu schreibt - das will bewusst und beobachtet laufen, getrennt vom Deployment, das davon abhängt.

Brauchen wir Container?

Nur mit einem Grund. Container lösen Umgebungsdrift über mehrere Dienste und Maschinen; für eine Laravel-Anwendung auf einem Server fügen sie eine Build-Pipeline und eine Registry hinzu, die gepflegt werden will. Nehmen Sie sie, wenn Sie das Problem tatsächlich haben.

Welcher Schritt fehlt am häufigsten?

Das Neustarten der Queue-Worker. Ein Worker hält den Code, mit dem er gestartet ist, sodass ein Deployment ohne Neustart die halbe Anwendung mit dem Release der Vorwoche laufen lässt - und die entstehenden Fehler wirken sporadisch und nicht reproduzierbar.

Laravel selbst ausliefern, ohne die zwei Minuten Ausfall

Eine verwaltete Plattform, ein Provisionierungsdienst oder ein schlichter Server - und die vier Dinge, die entscheiden, ob ein Deployment unsichtbar bleibt. Keines davon ist die Hosting-Wahl.

Veröffentlicht am 21. September 20264 Min. Lesezeit

Es gibt drei vernünftige Arten, eine Laravel-Anwendung zu betreiben, und der Streit darüber verdeckt meist, dass das Deployment-Skript wichtiger ist als die Wahl.

Die drei Optionen, ehrlich

Eine verwaltete Plattform. Sie pushen, sie baut und betreibt. Der geringste verfügbare Betriebsaufwand, zum höchsten Preis je Einheit, mit den Einschränkungen der Plattform als Ihren Einschränkungen. Gut für ein Team ohne Betriebskapazität und eine Last, die hineinpasst.

Ein Provisionierungsdienst auf eigenen Servern. Etwas, das einen Server, der Ihnen gehört, konfiguriert und Ihnen Deployments, Zertifikate und Worker gibt, ohne dass Sie das Ansible schreiben. Hier leben die meisten Laravel-Anwendungen, und das ist ein vernünftiger Standard: Sie behalten die Maschine, Sie sparen sich die Einrichtung.

Ein schlichter Server, den Sie konfigurieren. Am günstigsten, größte Kontrolle, und nur günstig, wenn ihn jemand besitzt. Updates, Zertifikate, Backups, Monitoring - die Rechnung ist klein, die Verantwortung nicht.

Es gibt hier keine falsche Antwort. Es gibt nur eine ohne Eigentümer.

Was tatsächlich entscheidet, ob ein Deployment wehtut

1. Atomare Releases. In ein neues Verzeichnis ausliefern und einen Symlink umlegen, wenn es fertig ist. Dateien über eine laufende Anwendung zu kopieren heißt, dass Anfragen für ein paar Sekunden von einer halb aktualisierten Codebasis bedient werden - was Fehler erzeugt, die danach niemand reproduziert.

releases/2026-09-21-140233/
current -> releases/2026-09-21-140233

Zwischen Releases geteilt: storage/ und die .env. Alles andere ist jedes Mal neu, und Rücknahme heißt, den Symlink zurückzulegen.

2. Der Cache-Aufbau, in dieser Reihenfolge.

php artisan config:cache
php artisan route:cache
php artisan view:cache
php artisan event:cache

Führen Sie diese auf dem neuen Release aus, bevor es aktuell wird. Vor allem config:cache bedeutet, dass env() außerhalb von Konfigurationsdateien überall null liefert - was korrektes Verhalten ist und die Leute überrascht, also env() nur in Konfigurationsdateien verwenden.

3. Queue-Worker neu starten. Der am häufigsten fehlende Schritt:

php artisan queue:restart

Ein Worker startet Ihre Anwendung einmal und behält sie. Ohne das läuft Ihre Web-Schicht mit dem neuen Release und Ihre Queue-Schicht mit dem, was aktuell war, als diese Prozesse zuletzt starteten - was eine eigene Fehlerklasse ist.

4. Migrationen, nach Risiko getrennt. Routinemäßige im Deployment. Alles, was eine große Tabelle neu schreibt, bewusst und beobachtet, denn die Sperre überdauert das Anfrage-Timeout, und das Deployment meldet Erfolg, während die Seite Fehler liefert.

Die Reihenfolge, die die Seite oben hält

# im neuen Release-Verzeichnis, bevor es live ist
composer install --no-dev --optimize-autoloader
npm ci && npm run build
php artisan config:cache && php artisan route:cache && php artisan view:cache
 
# aktuell machen
ln -sfn "$RELEASE" current
 
# danach
php artisan migrate --force
php artisan queue:restart
sudo systemctl reload php8.3-fpm

Reload statt Restart, damit laufende Anfragen fertig werden. Und danach prüfen, statt dem Skript zu vertrauen:

ps -eo lstart,cmd | grep "[q]ueue:work"

Startzeiten älter als das Deployment heißen, der Neustart hat sie nicht erreicht.

Die Teile, die oft gar nicht eingerichtet sind

Der Scheduler braucht einen Cron-Eintrag, und nur einen, auf einer Maschine:

* * * * * cd /var/www/app && php artisan schedule:run >> /dev/null 2>&1

Zwei Server, die ihn beide ausführen, heißt, dass jede geplante Aufgabe doppelt läuft.

Worker brauchen einen Supervisor. queue:restart stoppt Worker; es startet sie nicht. Ohne systemd oder Supervisor lässt ein Deployment Sie still ohne Worker zurück, und Jobs stauen sich, bis es jemand bemerkt.

Backups brauchen eine Rückspielung. Ein nie zurückgespieltes Backup ist eine Vermutung. Spielen Sie regelmäßig eines in eine Testumgebung zurück und schreiben Sie auf, wie lange es gedauert hat - diese Zahl ist Ihre tatsächliche Wiederherstellungszeit.

Logs brauchen ein Ziel. Die tägliche Standarddatei auf dem Anwendungsserver reicht, bis Sie zwei Server haben - dann heißt ein Vorfall, zwei Dateisammlungen von Hand zu lesen.

Der Teil, der nichts mit Hosting zu tun hat

Nichts von alldem hängt davon ab, welche der drei Optionen Sie gewählt haben. Eine verwaltete Plattform erledigt einiges für Sie; ein schlichter Server heißt, Sie schreiben es einmal. So oder so startet das Deployment die Worker neu oder eben nicht.

Deshalb ist das Nützlichste an diesem Artikel nicht, das Hosting zu wechseln. Es ist, Ihr eigenes Deployment-Skript zu lesen und herauszufinden, welcher dieser vier Schritte fehlt - nach unserer Erfahrung ist es meist der Worker-Neustart, und er fehlt seit dem Tag, an dem das Skript geschrieben wurde.