Laravel auf deinem eigenen DigitalOcean-Droplet, ohne Forge

Laravel Forge existiert, weil das korrekte Konfigurieren eines DigitalOcean-Droplets – Nginx oder Octane, PHP-FPM, ein Queue-Worker, der Scheduler, TLS, Zero-Downtime-Deploys – echte Arbeit ist, die die meisten Teams lieber bezahlen, um sie zu überspringen. Der Teil, den man getrennt betrachten sollte: Diese Konfigurationsarbeit ist ein einmaliges Problem, kein Grund, dauerhaft eine wiederkehrende Gebühr zusätzlich zum Droplet zu zahlen, den du DigitalOcean ohnehin schon bezahlst.

Was auf dem Droplet tatsächlich passieren muss

Jedes Einzelne davon ist echtes Setup, kein optionaler Feinschliff: composer install, php artisan migrate --force bevor der neue Code Traffic bekommt, ein stabil gehaltener APP_KEY über Deploys hinweg, ein Queue-Worker, der neben dem Web-Prozess läuft, ohne ihm in die Quere zu kommen, php artisan schedule:run, das pünktlich feuert, und ein Zero-Downtime-Swap, damit ein Deploy nicht mitten im Release Requests verliert.

Deinen eigenen Droplet verbinden

Servers → Add a server → Create on your cloud → DigitalOcean

Ein Personal Access Token aus DigitalOceans Control Panel (API → einen Token mit Lese- und Schreibzugriff erzeugen) ist alles, was nötig ist – Railyard provisioniert den Droplet direkt in deinem eigenen DigitalOcean-Account, zum regulären DigitalOcean-Preis, ohne Aufschlag. s-1vcpu-2gb (1 vCPU, 2 GB) ist eine vernünftige Startgröße für eine einzelne Laravel-App; Frankfurt oder Amsterdam, falls die Daten in der EU bleiben müssen.

Hast du schon einen laufenden Droplet? Bring your own server funktioniert genauso, gegen jede Ubuntu-22.04/24.04-Box mit passwortlosem Sudo und offenen Ports 22/80/443 – kein Grund, einen frischen zu provisionieren, nur um ihn zu verbinden.

Was passiert, sobald das Repo verbunden ist

railyard create my-app https://github.com/me/my-app --addons mysql,redis

composer.json und .env.example werden gelesen, um die Datenbank-Engine zu füllen, php artisan migrate --force als Release-Step, und APP_KEY wird einmalig in Laravels eigenem Format generiert. Installiertes laravel/horizon oder laravel/octane wird erkannt und genauso angebunden – die genauen Erkennungsregeln stehen in den vollständigen Laravel-Docs. Jeder Push nach dem ersten baut und deployed neu auf demselben Droplet, mit automatisch gehandhabtem Zero-Downtime-Swap.

Der eigentliche Vergleich

Forges Mehrwert ist real – es löst genau das oben beschriebene Problem. Die eigentliche Frage ist nur, wo dieser Mehrwert liegen soll: als dauerhafter Aufschlag auf jeden Droplet, oder als einmalige Plattformentscheidung auf Infrastruktur, die ohnehin schon deine ist. Beide Wege enden mit einem funktionierenden, korrekt konfigurierten Droplet; nur einer von beiden berechnet weiter, nachdem die Konfiguration erledigt ist.

Vollständige Referenz: Laravel-Docs, Server hinzufügen.