Von Hatchbox.io kommend
Hatchbox und Railyard setzen auf dieselbe Wette, deine Server, Push zum Deployen. So sieht der Umzug aus, und wo Railyard mehr von Tag zwei übernimmt.
Warum Teams über Hatchbox hinausschauen
Hatchbox hat die wichtige Sache richtig gemacht: Deploy auf Server, die dir gehören, kein Aufschlag auf Compute. Wenn das für dich funktioniert, gibt es keinen dringenden Grund zu wechseln.
Wo Leute anfangen zu suchen: Hatchbox ist eine dünne Schicht über einem recht manuellen Setup, nah an der Nginx-Config und den Server-Interna, und die verwaltete Oberfläche hört früh auf. Es gibt keinen Verify-then-Swap-Release mit gesundheitsgeprüftem Cutover, keine Preview-Umgebung pro Pull Request, keine Rollen / 2FA / Audit-Trail, und Backups sind deine eigene Sache. Es ist außerdem ein Ein-Maintainer-Produkt mit einer ruhigen Roadmap.
Railyard ist dieselbe “deine Server”-Wette, mit mehr von Tag zwei für dich erledigt.
Was mitkommt
- Dein Repo und dein Dockerfile, oder Railyards Nixpacks-/Buildpacks-Weg, falls du heute ohne eines deployst.
- Deine Procfile-Prozesstypen.
- Deine Umgebungsvariablen.
- Deine Datenbank. Hatchboxes verwaltetes Postgres / MySQL / Redis mappt auf Railyard-Addons mit injizierten Connection-Strings.
- Deine Server, falls du sie behalten willst: eine bestehende Maschine per SSH anbinden, statt eine neue zu provisionieren.
Der Umzug
- Einen Server anbinden. Railyard auf einen deiner aktuellen Hatchbox-Server zeigen, oder einen neuen in deinem Cloud-Account.
- Dein Repo hinzufügen und die Build-Methode bestätigen. Ein Dockerfile deployt unverändert.
- Deine Env mitbringen und die Datastores anhängen, die du brauchst.
- Deployen auf eine temporäre URL und end-to-end prüfen, inklusive Release-Task, falls du Migrationen laufen lässt.
- Deine Daten umziehen mit einem Standard-Dump und Restore in das verwaltete Addon.
- DNS umstellen. Die alte App bedient weiter, bis der Record kippt; nichts geht dunkel. Dann die Hatchbox-App abwickeln.
Was anders ist
Du bekommst bei jedem Deploy einen gesundheitsgeprüften, Zero-Downtime-Cutover, Rollback mit einem Klick inklusive erfasstem Commit und Autor, einen Preview-Deploy für jeden PR, echte Rollen und ein Audit-Log, und Backups, die geprüft auf Restore funktionieren, zusätzlich zum Ownership, das du schon hattest.