Eine Cloud-66-Alternative, die sich nicht in den Weg stellt

Cloud 66 verdient hier echte Anerkennung: Es hat das Bring-your-own-Server-Kontrollplane-Modell Jahre bewiesen, bevor es ein Trend war – verbinde einen Server, den du besitzt, bekomme einen Heroku-ähnlichen Workflow darauf, halte die Infrastrukturrechnung getrennt von der Plattformrechnung. Die Reibung, die Teams tatsächlich dazu bringt, sich anderswo umzusehen, ist nicht die Idee. Es ist das, was ein Jahrzehnt an hinzugefügten Features aus dieser Idee gemacht hat, und was es jetzt kostet.

Was tatsächlich anders ist

Die Oberfläche trägt Features, die die meisten kleinen Teams nie anfassen, angesammelt über eine lange Produktlebenszeit – was jedem ausgereiften Produkt normalerweise passiert, keine Kritik am Engineering. Die Preise spiegeln dieselbe Reife: Sie starten weit über dem, wofür ein Solo-Entwickler- oder kleines Team-Budget normalerweise Platz hat. Und es ist ein geschlossenes Produkt in genau dem Sinn, der hier zählt – du konfigurierst es, du betreibst es nicht; es gibt keinen Weg, darunterzuschauen, was es tatsächlich tut.

Railyard ist eine bewusst kleinere Wette auf dieselbe Kernidee: einen Server verbinden, Code pushen, die tatsächlichen Day-Two-Essentials bekommen – zero-downtime Deploys, verwaltete Datenbanken mit Failover, Backups, Autoscaling – zu einem Preis, der nicht mit der Teamgröße steigt.

Was übernimmt werden kann

Dein Repo, gebaut mit einem Dockerfile, Buildpacks, oder direkt aus einem Procfile gelesen – was auch immer schon heute funktioniert.
Umgebungsvariablen und Secrets, unverändert.
Cloud 66s ActiveDeploy-artige Zero-Downtime-Releases übertragen sich direkt als Railyards eigener Verify-then-swap-Cutover – dieselbe Garantie, anderer Name.
Verwaltetes Postgres, MySQL und Redis werden auf Railyards verwaltete Addons abgebildet.
Die Server selbst: hänge an, was du schon per SSH betreibst, statt von Grund auf eine neue Flotte zu provisionieren.

Der Umzug, konkret

Einen Server anhängen – einen, den du schon unter Cloud 66 betreibst, oder einen frischen, den Railyard direkt in deinem eigenen Cloud-Account provisioniert.
Das Repo hinzufügen und die Build-Methode wählen, die dazu passt, wie Cloud 66 es schon baut.
Die Konfiguration übertragen und die Datenspeicher anhängen, die die App erwartet.
Auf eine temporäre URL deployen, den Release-Task ausführen, tatsächlich verifizieren.
Die Daten migrieren mit einem Dump und einer Wiederherstellung in das verwaltete Addon.
DNS umziehen. Der Cloud-66-Stack bedient weiter während des gesamten Prozesses – es gibt kein Ausfallfenster zu planen. Außer Betrieb nehmen erst, nachdem der Cutover bestätigt ist.

Was danach tatsächlich anders ist

Weniger Angriffsfläche, weniger Kosten, und ein Workflow, der in deinen Kopf passt: ein Dashboard, eine klare Aktion pro Bildschirm, und nichts auf der Rechnung, das du nicht tatsächlich nutzt. Das ist der ganze Pitch – nicht mehr Features als Cloud 66, weniger von denen, nach denen ein kleines Team nie gefragt hat.

Vollständiger Plattformvergleich: Railyard vs. Cloud 66, und die komplette Migrationsanleitung unter Umzug von Cloud 66.