Laravel-Hosting, gebaut für Ihre Art zu deployen

Ja. Jeder Tarif enthält eine vollwertige SSH-Shell, sodass das Deployment genau dem Git-basierten Workflow entspricht, den Sie lokal bereits nutzen. Klonen Sie Ihr Repository direkt von GitHub, GitLab oder Bitbucket in Ihr Konto, führen Sie composer install für Ihre Vendor-Pakete aus und übertragen Sie anschließend Ihre Produktivwerte in die .env. Ab da übernimmt Artisan: php artisan key:generate setzt Ihren App-Key und php artisan migrate baut Ihr Datenbankschema auf. Ein späteres Release ist genauso schnell ausgeliefert — git pull für die neuen Commits, composer install für aktualisierte Abhängigkeiten, php artisan migrate für neue Migrationen und ein Cache-Refresh, der die alte Konfiguration entfernt. Weil Sie eine echte Shell statt eines abgeriegelten Panels haben, können Sie Logs verfolgen, Storage-Rechte korrigieren und jeden Befehl erneut ausführen, wenn etwas einen zweiten Blick braucht. Richten Sie das Document Root auf den public-Ordner, und die Website ist per HTTPS erreichbar.

Ja — Composer ist auf jedem Konto installiert und liegt bereits in Ihrem PATH. Vor dem ersten Deployment müssen Sie also nichts herunterladen, entpacken oder konfigurieren. Öffnen Sie eine SSH-Sitzung, sobald Ihr Konto bereitgestellt ist, und composer install, composer update, composer require sowie composer dump-autoload funktionieren sofort mit der korrekten PHP-Binärdatei. Für Laravel ist das entscheidend, denn das Framework und praktisch jedes Paket, das Sie ergänzen — von den Starter Kits über Sanctum und Horizon bis zum Rest — kommen über Composer und nicht über Ihr Repository. Sie behalten Ihre eigene composer.json und composer.lock, sodass genau die Versionen auf dem Server landen, die Sie lokal getestet haben. Und wenn Sie Composer einmal unter einem bestimmten PHP-Release ausführen möchten, geht auch das, denn die PHP-Version ist pro Website wählbar. Kurz gesagt: Ihr Abhängigkeits-Workflow verhält sich exakt wie auf Ihrem eigenen Rechner.

Sie erhalten modernes PHP 8.x und legen im Control Panel selbst fest, welches Release jede Website nutzt. Diese Flexibilität ist wichtig, weil jede Laravel-Version eine Mindestanforderung an PHP stellt: Aktuelle Releases erwarten PHP 8.1 oder neuer, während eine ältere Long-Term-Support-App auf einen früheren 8.x-Build festgelegt sein kann. Statt eine einzige Laufzeitumgebung für alles zu erzwingen, setzen Sie die Version pro Domain — so leben ein älteres Kundenprojekt und eine brandneue App konfliktfrei im selben Konto. Neben der Auswahl können Sie die Einstellungen justieren, auf die es Laravel ankommt: memory_limit für schwerere Artisan-Befehle und Importe, max_execution_time für langlaufende Aufgaben und OPcache, damit Ihr kompilierter Code im Arbeitsspeicher warm bleibt. Der Wechsel ist sofort wirksam und umkehrbar, was das Testen eines PHP-Upgrades risikoarm macht: Stellen Sie zuerst eine Staging-Domain um, prüfen Sie Ihre Testsuite und ziehen Sie die Produktion anschließend mit einem Klick nach.

Beides ist hier erstklassig unterstützt. Für Queue-Arbeit starten Sie mit php artisan queue:work einen dauerhaften Worker, damit Jobs, Benachrichtigungen, Mailables und schwere Exporte außerhalb des Web-Requests laufen und nicht den Seitenaufbau eines Besuchers blockieren. Hinterlegen Sie die Queue mit Redis, dann werden Jobs auch unter echtem Traffic zügig aufgenommen und abgearbeitet. Für geplante Aufgaben legen Sie keine lange Liste einzelner Cron-Zeilen an. Stattdessen registrieren Sie alles im Laravel-Scheduler in Ihrem App-Code und ergänzen einen einzigen Cron-Eintrag, der jede Minute php artisan schedule:run ausführt. Aus dieser einen Aufgabe entscheidet Laravel, welche Befehle fällig sind, und startet sie — stündliche Zusammenfassungen, nächtliche Aufräumarbeiten, Wochenberichte und so weiter. Führen Sie nach jedem Deployment php artisan queue:restart aus, damit Ihre Worker den neuen Code laden. Es ist das Standard-Laravel-Setup genau so, wie es die Dokumentation beschreibt — ohne plattformspezifische Umwege.

Ja. Redis steht für Caching, Session-Speicherung und Queues bereit — genau die Kombination, zu der die meisten produktiven Laravel-Apps greifen. Richten Sie Ihren Cache-Treiber auf Redis, und teure Query-Ergebnisse, gerenderte Fragmente und berechnete Werte kommen aus dem Arbeitsspeicher, statt bei jedem Aufruf neu erzeugt zu werden. Verlagern Sie Sessions auf Redis, und der Login-Status bleibt schnell und konsistent, während der Traffic wächst. Setzen Sie Ihre Queue-Verbindung auf Redis, und Hintergrundjobs werden mit sehr wenig Overhead eingereiht und verarbeitet, sodass Worker auch bei Lastspitzen reaktionsschnell bleiben. All das konfigurieren Sie in Ihrer .env über die üblichen Cache-, Session- und Queue-Treiber-Einstellungen — auf unserer Seite ist keine Sonderkonfiguration nötig. Weil Redis diesen Arbeitsdatensatz im RAM statt auf der Festplatte hält, werden vormals träge Seiten spürbar flotter, und die Hintergrundverarbeitung kommt mit, statt sich bei einem Traffic-Schub zu einem Rückstau aufzutürmen.

Ja, und genau so serviert man eine Laravel-App korrekt. Laravel hält einen einzigen Einstiegspunkt im public-Verzeichnis und legt Ihren Anwendungscode, die .env und storage oberhalb des Web-Roots ab, sodass nichts Sensibles über das Web erreichbar ist. Im Control Panel setzen Sie das Document Root Ihrer Domain auf den public-Ordner Ihres Projekts, und Anfragen laufen über index.php — exakt so, wie es das Framework vorsieht. Zusammen mit kostenlosem, automatisch verlängertem SSL antwortet Ihre App über HTTPS mit sauberen, schönen URLs und ohne index.php in der Adresszeile. Die Verzeichnisrechte für storage und bootstrap/cache lassen sich per SSH unkompliziert setzen, sodass Caching, Sessions und Datei-Uploads auf Anhieb funktionieren. Wenn Sie mehrere Apps in einem Konto hosten, erhält jede Domain ihr eigenes Document Root, das auf ihren eigenen public-Ordner zeigt — die Projekte bleiben sauber getrennt und teilen sich darunter denselben schnellen NVMe-Server.

Yes. Our team transfers your codebase, exports and imports your MySQL database, and carries over your storage folder so uploaded files and cached data aren't left behind. We bring everything up on a temporary address first so you can confirm queues, the scheduler and Redis-backed sessions all still work, and only then do we walk through the DNS cutover.

Yes, daily backups cover your database and storage directory, giving you a restore point that sits alongside your own Git-based code rollbacks. If a migration or seed command goes wrong, you can restore the previous day's snapshot rather than trying to reverse the damage by hand.

Yes. Addon domains let you point a staging subdomain and your live domain at the same account, each with its own document root and database. Push and test on staging first, run your Artisan migrations there, and only promote to the production domain once you're confident.

Higher tiers support up to 100 MySQL databases, which in practice means room for several Laravel projects — a mix of client sites, side projects and staging copies — on a single account, each with its own domain, database and .env.

Every plan is covered by a 30-day money-back guarantee, so you can deploy your actual project, run it under real traffic, and check queue throughput and Redis caching behave the way you expect before committing beyond the trial period.

Plans are priced in USD starting at $2.42/mo, and geo-currency detection displays that price converted into your local currency at checkout, so what you see is what gets billed rather than a rate you have to calculate yourself. Billing itself runs through Bohzo Ltd (UK).