Von Cloud 66 kommend
Cloud 66 hat das Control Plane auf eigenen Servern erfunden. Railyard ist die leichtere, günstigere Version desselben Modells. So läuft der Umzug.
Warum Teams Cloud 66 verlassen
Cloud 66 hat das Modell vor Jahren bewiesen: ein Control Plane über Servern, die dir gehören, auf jeder Cloud. Die Reibung heute ist Gewicht und Preis. Das Interface trägt ein Jahrzehnt an Features, die die meisten kleinen Teams nie anfassen, der Preis startet weit über dem Budget eines Solo- oder kleinen Teams, und es ist ein geschlossenes Produkt: du konfigurierst es, du betreibst es nicht selbst.
Railyard ist eine bewusst kleine Version derselben Idee: Server verbinden, Code pushen, die Tag-zwei-Essentials bekommen, zu einem Preis, der nicht mit deiner Teamgröße mitwächst.
Was mitkommt
- Dein Repo, gebaut aus einem Dockerfile, Buildpacks oder einem Procfile.
- Deine Umgebungsvariablen und Secrets.
- Zero-Downtime-Releases im ActiveDeploy-Stil werden zu Railyards Verify-then-Swap-Cutover.
- Verwaltetes Postgres / MySQL / Redis mappt direkt auf Railyard-Addons.
- Deine bestehenden Server: per SSH anbinden, statt die Flotte neu aufzubauen.
Der Umzug
- Einen Server anbinden: einen bestehenden Cloud-66-Server, oder einen neuen, den Railyard in deinem Cloud-Account provisioniert.
- Dein Repo hinzufügen und die Build-Methode wählen, die zu dem passt, wie Cloud 66 es heute baut.
- Deine Config mitbringen und die Datastores anhängen, die deine App erwartet.
- Deployen auf eine temporäre URL. Deinen Release-Task laufen lassen und verifizieren.
- Daten migrieren mit einem Dump und Restore in das verwaltete Addon.
- DNS umziehen. Der Cloud-66-Stack bedient weiter bis zum Cutover; keine Downtime. Dann stilllegen.
Was anders ist
Weniger Oberfläche, weniger Kosten, und ein Workflow, den du im Kopf behalten kannst: ein Dashboard, eine klare Aktion pro Screen, und nichts, wofür du zahlst, ohne es zu nutzen.