Technologie

Laravel Hosting und Deployment ohne Server-Bastelei

Laravel bringt viel mit, aber nicht den Server. Datenbank, Migrationen, Queue-Worker, Cronjobs und .env-Verwaltung bleiben Handarbeit. Die Plattform richtet das beim Projektstart ein.

Produktionsreifes Laravel-Template mit Repository und Projektstruktur
Datenbank, Reverse-Proxy, SSL, Firewall und Backups automatisch aufgesetzt
Deployment per Docker auf deinen eigenen oder einen Managed Server

Kostenlos registrieren Funktionen ansehen

Kostenlos starten. Keine Kreditkarte nötig.

Domain und SSL gehören zum Setup, nicht zur Nacharbeit.

Kurz gesagt

Laravel selbst zu betreiben bedeutet vor allem, eine Serverumgebung zu pflegen. Die Plattform übernimmt diesen Teil und lässt dir den Zugriff.

Aus dem Template entstehen Repository, Projektstruktur und eine Pipeline für Test bis Release.
Die Serverseite kommt mit Docker, MySQL, Reverse-Proxy, SSL, Firewall und Backups, eigen oder managed.

Laravel selbst aufsetzen oder über die Plattform betreiben

Die Gegenüberstellung zeigt, welche Aufgaben ein eigenes Laravel-Setup mit sich bringt und was die Plattform davon abnimmt.

Aufgabe	Mit der Application Platform	Selbst aufgesetzt
Projektstruktur und Repository	Vollständig abgedeckt: Entstehen aus einem produktionsreifen Laravel-Template mit festen Konventionen	Nicht vorgesehen: Repository anlegen, Struktur festlegen, Konventionen im Team abstimmen
PHP-Laufzeit und Abhängigkeiten	Vollständig abgedeckt: Laufen im Container, in CI und auf dem Server identisch	Nicht vorgesehen: PHP-Version, Extensions und Composer auf jedem Server einzeln pflegen
Datenbank	Vollständig abgedeckt: MySQL wird beim Server-Setup mit eingerichtet, inklusive Backups	Nicht vorgesehen: Datenbank installieren, absichern, Nutzer anlegen und Backups planen
Migrationen beim Release	Vollständig abgedeckt: Laufen als Schritt der Pipeline, die im Repository konfiguriert ist	Teilweise abgedeckt: Per Hand oder über selbstgeschriebene Deploy-Skripte
Queue-Worker und Cronjobs	Vollständig abgedeckt: Laufen als Container-Dienste auf dem eingerichteten Server neben der Anwendung	Teilweise abgedeckt: Prozessverwaltung, Neustarts und Crontab-Einträge selbst betreuen
Konfiguration und Secrets	Vollständig abgedeckt: Umgebungsvariablen und Zugangsdaten zentral im Projekt, pro Umgebung getrennt	Nicht vorgesehen: .env-Dateien auf Servern, oft ohne Historie und ohne Backup
Composer-Pakete veröffentlichen	Vollständig abgedeckt: Eigene Composer-Pakete werden in CI gebaut und im Projekt veröffentlicht	Teilweise abgedeckt: Eigenes Paket-Repository betreiben oder auf öffentliche Registries ausweichen
Datenbank ansehen und pflegen	Vollständig abgedeckt: phpMyAdmin steht im Remote-Workspace zur Verfügung	Teilweise abgedeckt: Zusätzliches Tool installieren und den Zugang absichern
Fehler im Betrieb	Vollständig abgedeckt: Sentry wird komplett aufgesetzt, Fehler kommen mit Stacktrace, Release und Kontext	Teilweise abgedeckt: Logdateien durchsuchen oder Error-Tracking selbst integrieren
Nachvollziehbarkeit der Umgebungen	Vollständig abgedeckt: Umgebungen und Deployments liegen als Konfiguration im Git-Verlauf	Nicht vorgesehen: Serverzustand wächst über Jahre und ist selten dokumentiert

Grün bedeutet vollständig abgedeckt, gelb teilweise, grau offen. Ein eigenes Setup ist möglich, bindet aber dauerhaft Aufmerksamkeit.

Stand: 10. August 2026. Die Gegenüberstellung beschreibt typische Abläufe und kann je nach Projekt abweichen.

Was du für Laravel konkret bekommst

Die Bausteine, die ein PHP-Backend im Betrieb braucht.

Produktionsreifes Template

Das Laravel-Template bringt Struktur, Konventionen und ein lauffähiges Setup mit. Für Mehrmarkenprodukte gibt es eine Whitelabel-Variante.

Datenbank und Backups

MySQL, Reverse-Proxy, SSL, Firewall und Backups werden beim Server-Setup automatisch eingerichtet, auf eigenen wie auf Managed Servern.

Pipeline mit Migrationen

Test, Build, Publish und Release laufen über GitLab CI. Migrationen sind ein regulärer Pipeline-Schritt statt ein manueller Handgriff.

Konfiguration an einer Stelle

Eigene Composer-Pakete werden in der Pipeline gebaut und veröffentlicht, ebenso Docker-Images und Pakete anderer Ökosysteme.

Docker
Datenbanken
Reverse-Proxy
SSL
Backups
Firewall
Demnächst Kubernetes
Demnächst Monitoring

Datenbank, Reverse-Proxy und Backups werden mit dem Server eingerichtet.

So kommt dein Laravel-Projekt live

Vier Schritte vom Projektstart bis zum ersten Release.

Server verbinden

Binde einen eigenen Server per SSH an oder nutze einen Managed Server. Docker, Datenbank, Reverse-Proxy, SSL, Firewall und Backups werden eingerichtet.
Projekt aus dem Template anlegen

Wähle Laravel im Assistenten. Repository, Projektstruktur und CI/CD-Pipeline entstehen gemeinsam mit dem Projekt.
Code und Konfiguration übernehmen

Übertrage deine bestehende Anwendung und hinterlege die Werte aus deiner .env als Umgebungsvariablen im Projekt.
Deployen und Migrationen laufen lassen

Ein Push startet die Pipeline. Build, Release und Migrationen laufen in derselben Reihenfolge wie bei jedem weiteren Deployment.

Häufige Fragen

Welche Datenbank kommt zum Einsatz?

Die Templates arbeiten mit MySQL, das beim Server-Setup mit eingerichtet wird. Zugangsdaten liegen zentral im Projekt und gehen an die Anwendung. Backups gehören zum Grundsetup, phpMyAdmin steht im Remote-Workspace bereit.

Wie laufen Migrationen beim Deployment?

Migrationen sind ein Schritt in der Pipeline und laufen bei jedem Release gleich ab. Die Konfiguration liegt lesbar im Repository, du kannst die Reihenfolge anpassen. Das manuelle Einloggen per SSH entfällt.

Was ist mit Queues und geplanten Aufgaben?

Ja. Du bindest ihn per SSH an, die Plattform richtet Docker, Datenbank, Reverse-Proxy, SSL, Firewall und Backups ein. Der Zugang bleibt bei dir. Ein Managed Server übernimmt zusätzlich die Wartung. Kubernetes und Monitoring fehlen noch.

Laravel-Projekt anlegen und deployen

Registriere dich kostenlos, wähle Laravel als Stack und sieh dir an, wie viel Serverarbeit dabei entfällt.

Kostenlos registrieren Mit uns sprechen