Von Laravel Forge kommend
Laravel Forge verwaltet Server, die du trotzdem separat an einen Cloud-Anbieter bezahlst. Railyard fügt verwaltete Addons, Zero-Downtime-Releases und Team-Rollen auf demselben Server-ist-deiner-Modell hinzu.
Warum Teams Laravel Forge verlassen
Forge ist ein solides Server-Provisioning-Panel: Es richtet Nginx, PHP und dein Deploy-Script auf einem Server ein, den du direkt deinem Cloud-Anbieter bezahlst. Die Reibung zeigt sich bei dem, was es nicht tut: keine verwalteten Datenbank-Backups standardmäßig, keine Verify-then-swap-Zero-Downtime-Releases, und die Team-Zugriffskontrolle ist begrenzt.
Railyard behält dieselbe Idee eines Servers in deinem eigenen Cloud-Account, ergänzt um verwaltete Addons, Zero-Downtime-Releases und echte Team-Rollen.
Was mitkommt
- Dein Laravel-Repo, gebaut aus einem Dockerfile oder Buildpacks.
- Deine Umgebungsvariablen und Secrets.
- Dein bestehender Server: anbinden per SSH, statt ihn neu aufzubauen.
- Verwaltetes Postgres, MySQL und Redis mappen direkt auf Railyard-Addons, mit hinzugefügten geplanten Backups.
Der Umzug
- Deinen Server anbinden: den, den Forge schon verwaltet, oder einen neuen, den Railyard in deinem Cloud-Account provisioniert.
- Dein Repo hinzufügen — Railyard erkennt Laravel automatisch.
- Deine Config mitbringen und die Datastores anhängen, die deine App erwartet.
- Deployen auf eine temporäre URL.
php artisan migrateausführen und prüfen. - Daten umziehen mit einem Dump und Restore ins verwaltete Addon.
- DNS umschalten. Forge bedient weiter bis zum Cutover; es gibt keine Downtime.
Was anders ist
Verify-then-swap-Zero-Downtime-Releases, verwaltete Backups und echte Team-Rollen, auf demselben Server-ist-deiner-Modell, das Forge schon nutzt.